Bug 1205725 - no visible mouse cursor on some arm boards
Summary: no visible mouse cursor on some arm boards
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 22
Hardware: arm
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: ARMTracker F22FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2015-03-25 14:28 UTC by Paul Whalen
Modified: 2015-05-08 07:28 UTC (History)
14 users (show)

Fixed In Version: xorg-x11-server-1.17.1-10.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-05-08 07:28:54 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Paul Whalen 2015-03-25 14:28:43 UTC
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.

Comment 1 Peter Robinson 2015-03-25 14:43:46 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

Comment 2 Dennis Gilmore 2015-03-25 14:44:42 UTC
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

Comment 3 Rob Clark 2015-03-26 16:50:16 UTC
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..

Comment 4 Peter Robinson 2015-04-09 14:35:11 UTC
> 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?

Comment 5 Rob Clark 2015-04-09 18:09:37 UTC
(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)

Comment 6 Dennis Gilmore 2015-04-29 12:41:30 UTC
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

Comment 7 Rob Clark 2015-04-30 19:46:43 UTC
(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.

Comment 8 Peter Robinson 2015-04-30 20:59:36 UTC
> 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?

Comment 9 Adam Williamson 2015-05-01 00:08:04 UTC
+1 blocker, for me.

Comment 10 drago01 2015-05-01 10:24:33 UTC
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).

Comment 11 Dennis Gilmore 2015-05-01 15:16:56 UTC
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

Comment 12 drago01 2015-05-01 15:29:06 UTC
(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

Comment 13 Rob Clark 2015-05-01 16:19:53 UTC
(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.

Comment 14 Fedora Update System 2015-05-02 06:48:45 UTC
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

Comment 15 Fedora Update System 2015-05-03 17:24:16 UTC
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).

Comment 16 Paul Whalen 2015-05-04 13:51:56 UTC
Confirmed working on the wandboard with 22_TC1. Many thanks!

Comment 17 Dan Mossor [danofsatx] 2015-05-04 16:57:02 UTC
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

Comment 18 Fedora Update System 2015-05-08 07:28:54 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.