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.