Description of problem: When using desktop enabled images on a number of ARM development boards, there is no visible cursor on screen. The cursor is there, and it is possible to interact with menu's and the desktop, but requires extreme patience. Affected boards: wandboard, trimslice, pandaboard Not affected : jetson tk1, banana pi, cubietruck Version-Release number of selected component (if applicable): F22 pre-release images.
What desktops? Is it using libinput? Can you test and see if it's an issue if you roll back and use the old input drivers? https://fedoraproject.org/wiki/Changes/LibinputForXorg
re-assigning to X as I get a visable cursor if I force X to use fbturbo or fbdev instead of the default selected modesetting driver, there was a report of it working fine with opentegra on a tegra based machine also. it seems to be limited to the modesetting driver. I have seen it using both when running an anaconda based install and using XFCE
sounds to me like -modesetting is expecting the driver to have hw cursor, while not all of the arm display controller blocks do.. Probably not a libinput issue.. maybe we should see if -modesetting can fall back to sw cursor if hw cursor fails..
> Probably not a libinput issue.. maybe we should see if -modesetting can fall > back to sw cursor if hw cursor fails.. Is that a setting in a config file or is it a code change?
(In reply to Peter Robinson from comment #4) > > Probably not a libinput issue.. maybe we should see if -modesetting can fall > > back to sw cursor if hw cursor fails.. > > Is that a setting in a config file or is it a code change? from quick look at the code, seems like there is a "SWcursor" option.. (however looks like the man page is out of date and does not mention it)
Ideally we keep things working without having to have a config. I hit this yesterday on my cubox-i it is extremely difficult to install without a visible mouse cursor. so I am proposing it as a Blocker for Final
(In reply to Dennis Gilmore from comment #6) > Ideally we keep things working without having to have a config. I hit this > yesterday on my cubox-i it is extremely difficult to install without a > visible mouse cursor. so I am proposing it as a Blocker for Final So, a real easy way to "fix" this without having to think about it would be an arm specific patch to make SWCursor default to false. SWcursor is a bit annoying when you have real accel, but I think the intersection between platforms using -modesetting and having accel at this point is the empty set.
> So, a real easy way to "fix" this without having to think about it would be > an arm specific patch to make SWCursor default to false. SWcursor is a bit > annoying when you have real accel, but I think the intersection between > platforms using -modesetting and having accel at this point is the empty set. Could we include a config excerpt in a /etc/X11/xorg.conf.d file and include it as ARM specific somewhere for certain drivers?
+1 blocker, for me.
Well the modesetting driver is already supposed to fall back to software cursor when hardware cursors do not work: http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/drivers/modesetting/drmmode_display.c#n439 But if drmModeSetCursor2 returns anything other than EINVAL it silently fails. So can someone with the affected hw try something like: diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c b/hw/xfree86/drivers/modesetting/drmmode_display.c index 824500b..d81ad98 100644 --- a/hw/xfree86/drivers/modesetting/drmmode_display.c +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c @@ -396,7 +396,7 @@ drmmode_set_cursor(xf86CrtcPtr crtc) drmModeSetCursor2(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, handle, ms->cursor_width, ms->cursor_height, cursor->bits->xhot, cursor->bits->yhot); - if (ret == -EINVAL) + if (ret) use_set_cursor2 = FALSE; else return; (we probably only want the return in case ret is actually 0 and jump straight to the fallback section ... but this patch should at least verify whether this is the issue or not).
I did a scratch build of X with the patch in comment 10, on the cubox-i which is an effected system, I got a cursor there was nothing logged in /var/log/Xorg.0.log to indicate what happened. it just worked. so I am not sure what return value we are getting but it is not -EINVAL
(In reply to Dennis Gilmore from comment #11) > I did a scratch build of X with the patch in comment 10, on the cubox-i > which is an effected system, I got a cursor there was nothing logged in > /var/log/Xorg.0.log to indicate what happened. it just worked. so I am not > sure what return value we are getting but it is not -EINVAL OK I have sent a slightly different patch upstream: http://lists.x.org/archives/xorg-devel/2015-May/046263.html
(In reply to drago01 from comment #12) > (In reply to Dennis Gilmore from comment #11) > > I did a scratch build of X with the patch in comment 10, on the cubox-i > > which is an effected system, I got a cursor there was nothing logged in > > /var/log/Xorg.0.log to indicate what happened. it just worked. so I am not > > sure what return value we are getting but it is not -EINVAL > > OK I have sent a slightly different patch upstream: > http://lists.x.org/archives/xorg-devel/2015-May/046263.html oh, good call, if driver doesn't implement cursor it would return -ENXIO.
xorg-x11-server-1.17.1-10.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/xorg-x11-server-1.17.1-10.fc22
Package xorg-x11-server-1.17.1-10.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xorg-x11-server-1.17.1-10.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-7481/xorg-x11-server-1.17.1-10.fc22 then log in and leave karma (feedback).
Confirmed working on the wandboard with 22_TC1. Many thanks!
Discussed at the 2015-05-04 blocker review meeting.[0] Voted as AcceptedBlocker. AcceptedBlocker - this makes X effectively unusable on most ARM platforms, effectively violates all the graphical desktop criteria as it's difficult to do any of them if you can't see the cursor. [0] http://meetbot.fedoraproject.org/meetbot/fedora-blocker-review/2015-05-04/f22-blocker-review.2015-05-04-16.00.log.txt
xorg-x11-server-1.17.1-10.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.