GNOME Bugzilla – Bug 706229
mouse cursor occasionally invisible after logging in
Last modified: 2014-03-04 18:57:34 UTC
I'm on Fedora 19 with the latest updates. Occasionally, I'd say one out of ten times I log in, my mouse cursor is invisible. It still works, so I can navigate to the user menu to restart my system in order to get a visible cursor again. I can't reproduce this reliably. I assume the developers need more information, but I'm not sure which info is useful to provide; I'll be prepared to give any further info which is needed.
We only hide the cursor when the screenshield shows up. Does this happen when the screenshield kicks in in the login screen?
From what I understand, with the screen shield you mean the lock screen, the one displaying the time in a very large font, right? Yes, the cursor is hidden then, until I start moving it. But my issue does not seem to have any relation with the screen shield: I start up my PC, log in immediately in GDM, then an empty desktop gets loaded with occasionally an invisible cursor.
I'm currently having the problem with F20 and gnome-shell 3.91.1. I've only rebooted twice, but both times I've been unable to locate the cursor after logging in. I haven't noticed if the cursor was working when I was at the login screen (will note this next time), but I do see the cursor seeming to move and trigger hover sort of stuff as it moves. I get the cursor back by unplugging the mouse and re-attaching it.
I see this too. The pointer always shows up eventually (within a minute). Not sure if there's something I'm doing that makes it show up or if it's just happening on its own.
would be good to figure this out for 3.10
gnome-settings-daemon (its cursor plugin to be exact) seems to be causing this not gnome-shell. (In reply to comment #5) > would be good to figure this out for 3.10 We could simply disable the "hide cursor during login" feature for 3.10 ...
(In reply to comment #4) > I see this too. The pointer always shows up eventually (within a minute). Not > sure if there's something I'm doing that makes it show up or if it's just > happening on its own. That smells of a hang within gnome-settings-daemon. Any chance you can get a backtrace when the cursor fails to show up? Do any of you use automatic login?
(In reply to comment #7) > Do any of you use automatic login? No but I have two monitors not sure whether this matters.
(In reply to comment #8) > (In reply to comment #7) > > Do any of you use automatic login? > > No but I have two monitors not sure whether this matters. Do you see the cursor appearing after a minute if you don't touch anything like Dan? Can you get a backtrace of g-s-d if that happens?
ok, moved off the 3.10 blocker list since it seems to be reported against 3.8
I can witness the same, no automatic login here on Fedora 19 with GNOME 3.8. I am not sure how to get a backtrace from the process, if you have something that explain it I can try net time it happens.
Created attachment 255509 [details] [review] cursor: Fix race with hidden cursor on startup When using a touchpad during startup (if you're, say, the twitchy kind), we might receive a callback from the monitor before the end of add_all_devices() as we're not using signals that go through the mainloop. Ensure that we set the cursor to be off before going through all the devices so as to avoid that race. It will however blink the cursor when X doesn't support per-device idle. You should upgrade your X anyway.
Testing would be helpful on this patch, I don't know whether it fixes the problem or not...
Bastien, can you make it land on F19 updates-testing? Given it is not 100% reproducible it will be not an easy call, but if I do not see it in few suspend/resume cycles it would be a very good sign...
(In reply to comment #12) > Created an attachment (id=255509) [details] [review] > cursor: Fix race with hidden cursor on startup > > When using a touchpad during startup (if you're, say, the twitchy kind), > we might receive a callback from the monitor before the end of > add_all_devices() as we're not using signals that go through the > mainloop. Mh? In the 3.8 code, signals are emitted because of X events (so they're emitted at the next mainloop iteration when gdk pulls from Xlib), in the 3.10 code they are emitted from GDBus (so always in an idle callback), so I don't get this part.
Test build for F20 with the patch from comment #12: http://koji.fedoraproject.org/koji/taskinfo?taskID=5981871
*** Bug 708653 has been marked as a duplicate of this bug. ***
i was able to get my pointer back. here is what i've done: installed and running fedora 20 alpha in a virtual machine (vm) using virt-manager, i resized my display to 1280x720 and lost my pointer. any further resizing did not restore pointer. tried restarting gnome session and rebooting. still no pointer. upgraded dconf and dconf-editor to 0.18.0-1.fc20, navigated to org.gnome.settings-plugins.mouse and set the active flag to false (unchecked box). restart gnome session. seemed to crash gnome login screen. restarted vm. still no pointer. finally just deactivated the setting from cli: $ gsettings set org.gnome.settings-daemon.plugins.mouse active false alt+f2 and r to restart gnome session. bingo! i have a pointer again.
(In reply to comment #15) > (In reply to comment #12) > > Created an attachment (id=255509) [details] [review] [details] [review] > > cursor: Fix race with hidden cursor on startup > > > > When using a touchpad during startup (if you're, say, the twitchy kind), > > we might receive a callback from the monitor before the end of > > add_all_devices() as we're not using signals that go through the > > mainloop. > > Mh? In the 3.8 code, signals are emitted because of X events (so they're > emitted at the next mainloop iteration when gdk pulls from Xlib), in the 3.10 > code they are emitted from GDBus (so always in an idle callback), so I don't > get this part. I might certainly be looking in the wrong place. It seems that either X11 signals aren't getting through correctly, or they're getting eaten by gnome-desktop. Either way, this was a problem in 3.8 as well, with symptoms like a black screen with the cursor visible (gnome-shell didn't receive the "active" event but gnome-settings-daemon did), screen not going black at the lock screen (gnome-settings-daemon not receiving the 15 seconds idle signal). (In reply to comment #18) > i was able to get my pointer back. here is what i've done: > > installed and running fedora 20 alpha in a virtual machine (vm) using > virt-manager, i resized my display to 1280x720 and lost my pointer. any further > resizing did not restore pointer. tried restarting gnome session and rebooting. > still no pointer. > > upgraded dconf and dconf-editor to 0.18.0-1.fc20, navigated to > org.gnome.settings-plugins.mouse and set the active flag to false (unchecked > box). restart gnome session. seemed to crash gnome login screen. restarted vm. > still no pointer. > > finally just deactivated the setting from cli: > > $ gsettings set org.gnome.settings-daemon.plugins.mouse active false > > alt+f2 and r to restart gnome session. bingo! i have a pointer again. That's very unlikely to have any consequence on showing the cursor or not, the call should be: gsettings set org.gnome.settings-daemon.plugins.cursor active false
(In reply to comment #16) > Test build for F20 with the patch from comment #12: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=5981871 Unfortunately I reproduced the issue even with this build.
I'm fairly confident this is a problem with X's IDLETIME extension: https://bugs.freedesktop.org/show_bug.cgi?id=59644 I can reproduce the problem now, by touching the touchscreen and then the mouse in very quick succession. After a short period of time, we'll stop receiving "became-active" alarms for either of them. I could not find any work-arounds short of fixing X.
i have this bug my cursor disappears after login, i didn't have this until i encrypted my system. being my system is only an atom 1.6, i can see it kind of out of resources for gnome and 1.5 gigs of memory. every time i type my screen disappears even. there is a box around the cursor, while in firefox screen moves back to the empty fedora desktop. at login i have to hit the tab button to my login name. i go to displays in settings, i hit detect display but nothing happens, it shows red boxes and 4:3 settings. maybe i will hit xfce as i set my system up as gnome during install .this is an old acer aspire one netbeook. is there anything like msconfig on my start up to free up resources?
For people on F20, please test: http://koji.fedoraproject.org/koji/taskinfo?taskID=6071106
(In reply to comment #23) > For people on F20, please test: > http://koji.fedoraproject.org/koji/taskinfo?taskID=6071106 Doesn't help, cursor still disappears in a VM.
(In reply to comment #24) > (In reply to comment #23) > > For people on F20, please test: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=6071106 > > Doesn't help, cursor still disappears in a VM. It's supposed to disappear. The question is whether it reappears when moving the mouse.
Sadly, no. I had to kill gnome-setttings-daemon. I tried again and I was able to reproduce the issue on my third VM restart.
There's a downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1008965 And one in the correct bugzilla for the upstream component affected: https://bugs.freedesktop.org/show_bug.cgi?id=59644 I'll close this one.
It looks like this is gnome, can you look in journalctl -b when you see this to see if, GnomeDesktop-WARNING **: Failed to acquire idle monitor proxy: type thing appears when it happens and doesn't appear when it doesn't? There appears to be from my debugging a 3 way race condition here, spice-vdagent attachs its input device to the X server causing gnome-settings-daemon to get an event and try to create an idle timer for the new device, however mutter isn't quite started yet so it just fails to add the idle timer. Hopefully I've now given the gnome guys enough info to fix this, and it appears Adam has gotten the same debugging. reassigning to gnome-settings-daemon in the hope that someone there can fix it.
Note, this is for the problem on Fedora 20/GNOME 3.10. I haven't had reports about missing cursors on older versions for a while, and it's possible that Peter Hutterer's XSync patches have fixed the problem there. An example error from the journalctl -b output: Nov 18 13:44:24 nuvo gnome-session[788]: (gnome-settings-daemon:837): GnomeDesktop-WARNING **: Failed to acquire idle monitor proxy: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface 'org.gnome.Mutter.IdleMonitor' on object at path /org/gnome/Mutter/IdleMonitor/Device14 points to a race: - gnome-settings-daemon sees the new device appear, tries to add an idle timer - gnome-desktop requests the idle monitor from mutter - mutter replies that the interface doesn't exist, likely meaning that the device hasn't been processed and registered in gnome-shell yet. The error message is somewhat confusing (see bug 715007) and seems to point to the object being missing rather than just the idle monitor interface not being registered on it yet. I think that the fix would live in gnome-desktop waiting for object-added/interface-added signals from the ObjectManager, instead of creating device paths by hand: https://git.gnome.org/browse/gnome-desktop/tree/libgnome-desktop/gnome-idle-monitor.c#n261
Created attachment 262801 [details] [review] idle-monitor: Check if a monitor exists before creating a proxy for it The fact that we know about a given device doesn't mean that mutter also knows about it nor that it has created an idle monitor object on the bus for it. To fix this race, instead of immediately trying to create a proxy for the bus object, we instantiate an object manager and ask it whether the object we want already exists and if it doesn't we wait (indefinitely) until it shows up.
Review of attachment 262801 [details] [review]: Rest looks good. ::: libgnome-desktop/gnome-idle-monitor.c @@ +202,3 @@ case PROP_DEVICE: monitor->priv->device = g_value_dup_object (value); + if (!monitor->priv->device) This should probably be moved to a _set_device() function. @@ +403,3 @@ monitor->priv->cancellable = g_cancellable_new (); + + monitor->priv->path = g_strdup ("/org/gnome/Mutter/IdleMonitor/Core"); As "device" is a construct property, you can do that in the "if (device == NULL)" branch of the set_device() function.
Created attachment 262820 [details] [review] idle-monitor: Check if a monitor exists before creating a proxy for it -- (In reply to comment #31) > ::: libgnome-desktop/gnome-idle-monitor.c > @@ +202,3 @@ > case PROP_DEVICE: > monitor->priv->device = g_value_dup_object (value); > + if (!monitor->priv->device) > > This should probably be moved to a _set_device() function. Seems strange having a _set_device() function that's not useful in the public API since this is a construct property. And we don't have many properties making set_property() too long either. > @@ +403,3 @@ > monitor->priv->cancellable = g_cancellable_new (); > + > + monitor->priv->path = g_strdup ("/org/gnome/Mutter/IdleMonitor/Core"); > > As "device" is a construct property, you can do that in the "if (device == > NULL)" branch of the set_device() function. Done. Thanks for the review.
Review of attachment 262820 [details] [review]: Looks good.
Pushed to both master and gnome-3-10 17d3094..f4402b6 gnome-3-10 -> gnome-3-10 a595e5a..fff5475 master -> master