Bug 1205725
Summary: | no visible mouse cursor on some arm boards | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Paul Whalen <pwhalen> |
Component: | xorg-x11-server | Assignee: | X/OpenGL Maintenance List <xgl-maint> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 22 | CC: | awilliam, danofsatx, dennis, drago01, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mchehab, pbrobinson, rclark, robatino, xgl-maint |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | arm | ||
OS: | Linux | ||
Whiteboard: | AcceptedBlocker | ||
Fixed In Version: | xorg-x11-server-1.17.1-10.fc22 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-05-08 07:28:54 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 245418, 1043130 |
Description
Paul Whalen
2015-03-25 14:28:43 UTC
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. |