|Summary:||mouse cursor sometimes disappears on login|
|Product:||[Fedora] Fedora||Reporter:||Kamil Páral <kparal>|
|Component:||gnome-desktop||Assignee:||Rui Matos <rmatos>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||20||CC:||ahmadsamir3891, airlied, allison.karlitskaya, atigro, awilliam, bnocera, bugzilla, cfergeau, collura, eblake, fedora, fmuellner, gianluca.cecchi, htaira, i, jones.peter.busi, kvolny, leigh123linux, madko, mclasen, mfabian, michele, mike, mruckman, mswal2846, ofourdan, osbugs, otaylor, pablo.iranzo, peter.hutterer, pe, pnemade, pschindl, rmatos, robatino, rstrode, samkraju, samuel-rhbugs, sergio.pasra, tcallawa, theo148, tiagomatos, walters, xgl-maint, zbyszek|
|Target Milestone:||---||Keywords:||CommonBugs, Reopened|
|Fixed In Version:||gnome-desktop3-3.10.2-2.fc20||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-08-13 10:53:48 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||1033598, 1039132|
Description Kamil Páral 2013-09-17 12:11:03 UTC
Description of problem: During my testing, I several times saw a problem when mouse cursor was present in gdm, but disappeared on login. The cursor was still present (mouse over effects worked and I could click on widgets), but the cursor itself was invisible. Usually, switching to tty2 and back solves the problem. I saw this mainly in virtual machines (virt-manager+spice+qxl), but I saw it on bare metal as well (Intel graphics, although it was F19). Some of my colleagues have seen this problem (in VMs) as well. Version-Release number of selected component (if applicable): gnome-shell-3.9.91-1.fc20.x86_64 gdm-3.9.90-1.fc20.x86_64 xorg-x11-drv-evdev-2.8.1-3.fc20.x86_64 xorg-x11-drv-fbdev-0.4.3-10.fc20.x86_64 xorg-x11-drv-intel-2.21.14-1.fc20.x86_64 xorg-x11-drv-modesetting-0.8.0-2.fc20.x86_64 xorg-x11-drv-qxl-0.1.1-0.14.20130703git8b03ec16.fc20.x86_64 xorg-x11-drv-synaptics-1.7.1-5.fc20.x86_64 xorg-x11-drv-vesa-2.3.2-10.fc20.x86_64 xorg-x11-drv-vmmouse-13.0.0-6.fc20.x86_64 xorg-x11-drv-vmware-13.0.1-2.fc20.x86_64 xorg-x11-drv-wacom-0.22.0-3.fc20.x86_64 xorg-x11-font-utils-7.5-18.fc20.x86_64 xorg-x11-fonts-Type1-7.5-9.fc20.noarch xorg-x11-glamor-0.5.0-6.20130401git81aadb8.fc20.x86_64 xorg-x11-server-Xorg-1.14.2-9.fc20.x86_64 xorg-x11-server-common-1.14.2-9.fc20.x86_64 xorg-x11-server-utils-7.7-2.fc20.x86_64 xorg-x11-utils-7.5-12.fc20.x86_64 xorg-x11-xauth-1.0.7-4.fc20.x86_64 xorg-x11-xinit-1.3.2-9.fc20.x86_64 xorg-x11-xkb-utils-7.7-8.fc20.x86_64 How reproducible: rarely Steps to Reproduce: 1. boot Fedora (in a VM, better chance of seeing this) 2. verify that you see a cursor in gdm 3. log in, see cursor go invisible
Comment 4 Kamil Páral 2013-09-17 12:21:02 UTC
In the logs above, I started the VM, logged in, noticed that my cursor is invisible, and gathered the logs.
Comment 5 Christopher Meng 2013-09-17 12:42:49 UTC
Same like reporter, I'm using GNOME when hitting this problem. If I use KDE, nothing happened. When I met this, I was always switching windows and GNOME is laggy then after a while it sucked, after a while again I could move my cursor but I couldn't see it. Ctrl-Alt-F2 and back solved my problem.
Comment 6 Kamil Páral 2013-09-17 13:21:24 UTC
I have seen it several more times, as same as Petr Schindler. It seems that the problem frequency increased with Alpha RC3.
Comment 7 Adam Williamson 2013-09-19 02:34:57 UTC
I've just seen this in an Alpha RC4 install to a KVM. Happened during g-i-s on first boot of the installed system and persisted after g-i-s was complete and user logged in, and then happened again on second boot of the system after login from GDM. switching to VT2 and back to VT1 caused Shell to crash and the cursor was still not visible, for me... this looks kinda bad :/ but if it's mainly on VMs may be ok for alpha.
Comment 8 Petr Schindler 2013-09-19 09:34:47 UTC
I've just met it on bare metal. So I suppose it is happening on hardware too.
Comment 10 Petr Schindler 2013-09-19 09:35:48 UTC
Created attachment 799804 [details] output from journalctl -a
Comment 12 Adam Williamson 2013-09-19 09:43:03 UTC
kparal already said he's seen it *sometimes* on metal, just not as often.
Comment 13 Karel Volný 2013-09-19 13:55:46 UTC
well, I started hitting this/similar issue too in my case, it is Fedora 19 and KDE it happens if the screen is locked then the cursor is invisible after unlocking (possibly also during the lock but I never bothered to notice as the only action I do on that screen is to type in the password, and the input field has the focus by default ...) switching to text and back fixes this for 100%, sometimes it helps just to move the mouse wildly hardware is Lenovo T530 and B570 the reproducibility is about 1 in 5 to 10 cases (well, as usual, if I try to reproduce, it does not happen in twenty tries, if I need to do something quickly and the hidden cursor really blocks me, it happens five times in a row :-))
Comment 14 Kamil Páral 2013-09-19 16:31:22 UTC
(In reply to Karel Volný from comment #13) In that case I guess this should be assigned to xorg, rather than gnome-shell.
Comment 15 Adam Williamson 2013-09-19 23:06:10 UTC
Er, I wouldn't be convinced that Karel's is the same issue, from the descirption.
Comment 16 Karel Volný 2013-09-20 13:44:49 UTC
(In reply to Adam Williamson from comment #15) > Er, I wouldn't be convinced that Karel's is the same issue, from the > descirption. well, yes, that's why I haven't reassigned this ... but I cannot rule this out too we'll know when this will be fixed and I'll be still seeing the problem :-)
Comment 17 Ahmad Samir 2013-09-25 07:21:44 UTC
I've occasionally seen this bug too; switching VTs seems to cure the issue. Also it seems that killing gnome-settings-daemon makes the cursor appear (without having to switch VTs). This is with: - F19, GDM, GNOME 3, all up to date - The nvidia proprietary driver (though I'd seen the same issue with nouveau) - Automatic login is enabled for my username in GNOME 3
Comment 18 Kamil Páral 2013-09-25 11:55:10 UTC
I can confirm that killing gnome-settings-daemon fixes the problem. That leads me to believe that this is really a GNOME related problem and Karel Volny saw a different issue. Also, I have no problem reproducing it now, it happens very often. I have also received reports from other people experimenting with Alpha.
Comment 19 Kamil Páral 2013-09-25 11:59:39 UTC
There is a patch here: https://bugzilla.gnome.org/show_bug.cgi?id=706229#c12
Comment 20 Mike Ruckman 2013-09-25 17:15:34 UTC
Discussed during 2013-09-25 Blocker Review Meeting . This was voted a RejectedBlocker as well as an AcceptedFreezeException - While unfortunate, this does not violate any F20 beta release criteria and thus is rejected as a blocker for f20 beta. However, a tested fix would be considered past freeze.  http://meetbot.fedoraproject.org/fedora-blocker-review/2013-09-25/
Comment 21 Kamil Páral 2013-09-26 07:34:04 UTC
Reproposing for Final and fixing FE tags.
Comment 22 Mohammed Arafa 2013-09-26 16:30:15 UTC
i see this on kde f19 too and switching vt works
Comment 23 Christian Stadelmann 2013-10-22 18:49:20 UTC
I see this bug on F19 with Gnome too and switching to tty and back works for me, too.
Comment 24 leigh scott 2013-10-25 09:46:57 UTC
(In reply to Christian Stadelmann from comment #23) > I see this bug on F19 with Gnome too and switching to tty and back works for > me, too. It's been around for ages (it was in F19 beta). https://bugzilla.redhat.com/show_bug.cgi?id=969649
Comment 25 osbugs 2013-10-26 23:14:39 UTC
Will this bug be fixed in Fedora 20? The bug is really annoying. Thank you for clarification.
Comment 26 osbugs 2013-10-27 20:16:32 UTC
Could this be a workaround? dconf-editor > org/gnome/settings-daemon/plugins/cursor/active to false Credit: https://bbs.archlinux.org/viewtopic.php?pid=1334401#p1334401 The problem havent occured again on my machine. Can somebody confirm? Thanks.
Comment 27 Peter Hutterer 2013-10-30 06:49:19 UTC
There's a test build on the way here which may or may not fix this issue. http://koji.fedoraproject.org/koji/taskinfo?taskID=6114773
Comment 28 Kamil Páral 2013-10-30 10:31:58 UTC
(In reply to Peter Hutterer from comment #27) > There's a test build on the way here which may or may not fix this issue. > http://koji.fedoraproject.org/koji/taskinfo?taskID=6114773 Doesn't help, problem still present.
Comment 29 Peter Hutterer 2013-10-31 06:17:08 UTC
So, here's what I'm seeing (with the test build from comment #27). Freshly installed F20 in a VM. gdm comes up, no mouse cursor visible. Emulated PS/2 mouse and events through evemu, mouse cursor is not visible. After login, cursor is visible. deactivating the cursor plugin, ran the gsd-test-cursor from gnome-settings-daemon-devel and that works as expected. Added a bunch of printfs to the server code: * an alarm is created for each device for value 1, events disabled * an alarm is created for the IDLETIME counter for value 1, events disabled * another alarm is created for the IDLETIME counter, value 30000, events enabled. (that appears to be the 5 min blank alarm) * alarms for the QEMU tablet, QEMU mouse and my emulated mouse are enabled for events * the server writes the event for the respective device * when swapping devices between the QEMU tablet and the emulated mouse, the right alarms trigger at this point it looks like the server is doing the right things and this is on the client side, notably: * the client never enables events for the IDLETIME alarm on value 1 until after login * all alarms trigger as expected, but events aren't always enabled, so the client may miss out here on what it expects I'm going to attach an Xorg.log with that output, maybe it'll help
Comment 30 Peter Hutterer 2013-10-31 06:28:40 UTC
Created attachment 817725 [details] Xorg.0.log Xorg.log with extra printfs: * NoticeTime resets the idletime * deviceids are 0 for IDLETIME, 2 for the virtual core pointer, 7 for the qemu tablet * ProcFoo functions are the server endpoints of the matching XFoo() calls * IdleTimeWakeupHandler is what trigger * less/greater are the lower/upper boundaries for when to trigger alarms. if the idletime goes below/above that value the alarm triggers * reset 1: means idletime was reset for this device since the last check * timestamp [ 6849.472] is the first input event, output shows event being written. you can see the alarm events being deactivated, which is what the gsd code shows too * timestamp [ 6911.729] is the start of the login and at [ 6925.112] the IDLETIME counter is enabled for alarms too.
Comment 31 Samuel Sieb 2013-11-04 06:50:40 UTC
I haven't seen this on login yet, but it happens occasionally during normal use. Every time it happened when starting a flash application in a web page. However, I just caused it to happen using mplayer, but I can't get it to happen again. My guess is that it's some sort of race condition with whatever process hides the cursor when it's not moving.
Comment 32 Samuel Sieb 2013-11-05 16:04:29 UTC
Is there a command-line utility that can check and/or set the state of the mouse cursor?
Comment 33 RudraB 2013-11-11 18:26:29 UTC
Not sure if this comes as the same bug, but in my laptop, this "invisible mouse cursor" happens only with the real mouse. As soon as I touch the mousepad, the cursor become visible.
Comment 34 Adam Williamson 2013-11-13 20:13:33 UTC
Discussed at 2013-11-13 blocker review meeting - http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-13/f20-final-blocker-review-1.2013-11-13-17.01.log.txt . Accepted as a blocker as it conditionally violates all criteria relating to blocker desktop and app usability, in the case where this bug happens (the desktop and its apps aren't really 'usable' without a pointer).
Comment 35 Bastien Nocera 2013-11-14 09:15:55 UTC
(In reply to RudraB from comment #33) > Not sure if this comes as the same bug, but in my laptop, this "invisible > mouse cursor" happens only with the real mouse. As soon as I touch the > mousepad, the cursor become visible. That's not a bug, that's the expected behaviour. The mouse won't be visible until you move it. Reassigning to xorg-x11-server, as that's where the idle monitors are implemented.
Comment 36 RudraB 2013-11-14 11:29:21 UTC
(In reply to Bastien Nocera from comment #35) > That's not a bug, that's the expected behaviour. The mouse won't be visible > until you move it. Do I sound like I expect the pointer to be visible without moving it? sorry then! I meant, after login, no matter how hard I *move* my physical mouse, it remains invisible. but as soon as I touch the touchpad, it becomes visible, and then I can use my mouse as normal. So, this is an alternative to going to and come back from a vt to get the cursor visible.
Comment 37 Matthias Clasen 2013-11-14 14:04:59 UTC
thats a bug any motion of the pointer, whether mouse or touchpad, should make it appear.
Comment 38 mswal28462 2013-11-14 14:43:07 UTC
I encountered a similiar but slightly different condition last night on this issue. Performed a YUM UPDATE yesterday on my Fedora 19 system on a Lenovo x230 with a trackpoint mouse, several updates applied, so I decided to shut down and Start again (not a restart). Upon boot, no cursor/mouse in GDM, entered my password and no cursor/mouse in GNOME. This has happened previously, roughly every 4 or 5 boot up. A reboot "fixed" the problem. Last night, I shut down and started again 4 times and no cursor/mouse in GDM and no cursor/mouse in GNOME. Upon the 5th restart (shut down and start), the cursor/mouse appeared in GDM and in GNOME. Unlike the original issue in this defect, I've never experienced this with a Suspend.
Comment 39 mswal28462 2013-11-15 18:47:34 UTC
How does one set the Priority/Severity? This problem is pretty urgent to get fixed. Without a mouse/cursor, the system is effectively unusable.
Comment 40 Adam Williamson 2013-11-15 19:00:30 UTC
"How does one set the Priority/Severity?" It doesn't really matter, if it's set as a release blocker. "This problem is pretty urgent to get fixed. Without a mouse/cursor, the system is effectively unusable." The workaround is trivial, though - just switch to VT2 and back. It's not a real showstopper, just annoying.
Comment 41 mswal28462 2013-11-15 20:05:24 UTC
Ahhh, I did neglect to say that I did try the VT trick (Ctrl-Alt-F2, get to VT, then Ctrl-Alt-F1, to get back) and that did NOT work. No cursor/mouse. So more than annoying, I'm afraid. After the 4th try to rebooting, I was about to swamp out my harddrive to Fedora 18 just so I had a PC again.
Comment 42 Adam Williamson 2013-11-15 20:08:34 UTC
You're not necessarily actually seeing the same problem if you see it every boot and switching to a VT and back doesn't 'cure' it.
Comment 43 mswal28462 2013-11-15 20:18:01 UTC
Right, which is why I said "similiar but slightly different." The mouse did come back after the 5th boot (thank goodness!) Should I open a separate bug report?
Comment 44 pe 8-bit 2013-11-18 01:09:02 UTC
3.11.8-200.fc19.x86_64 Got this today and mentioned, that after login procedure the cursor is jumping to bottom-right part of screen, then disappearing. It appears back on desktop by itself (no need in tty switching "trick") within one minute. Got to say that today i managed to disable some of services (cups, rpcbind, avahi, bluetooth, sshd, chrony and possibly some others) also as ipv6. Maybe this was the cause?
Comment 45 Peter Hutterer 2013-11-19 08:50:34 UTC
(In reply to Bastien Nocera from comment #35) > Reassigning to xorg-x11-server, as that's where the idle monitors are > implemented. can you please look at comments 29 and 30, I tried to debug this and reassigned it back to you for a reason.
Comment 46 Adam Williamson 2013-11-20 20:14:36 UTC
Status reviewed at 2013-11-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-20/f20-blocker-review.2013-11-20-17.00.log.txt . We're worried that this is ping-ponging between Peter and Bastien with no-one clearly responsible for fixing it: devs, can you please get together and work out a clear path forward here? Thanks.
Comment 47 Adam Williamson 2013-11-20 22:40:41 UTC
I'm still seeing the bug - as originally described - in Final TC1 testing in a qxl/spice KVM, for the record. The pointer is clearly present and working - I can click on stuff if I can figure out where it is - but not visible. Switching to VT2 and back (sometimes a couple of times) makes it work again.
Comment 48 Fedora Update System 2013-11-21 06:08:25 UTC
xorg-x11-server-1.14.4-5.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/xorg-x11-server-1.14.4-5.fc20
Comment 49 Kamil Páral 2013-11-21 10:35:25 UTC
(In reply to Fedora Update System from comment #48) > xorg-x11-server-1.14.4-5.fc20 has been submitted as an update for Fedora 20. > https://admin.fedoraproject.org/updates/xorg-x11-server-1.14.4-5.fc20 Doesn't help.
Comment 50 Peter Hutterer 2013-11-21 10:42:59 UTC
yeah, I figured as much but the patch won't hurt and may just fix the odd corner-case. Either way, I spent most of the day restarting the server, hoping fo the bug to happen. Any hints on how to get this to happen reliably (or at all!) would be appreciated.
Comment 51 Tom "spot" Callaway 2013-11-21 15:05:34 UTC
I seem to be able to trigger it almost every morning. My laptop is in a dock with a second monitor connected to it (and a USB wireless logitech mouse plugged into the dock). It is so reliable I have gotten used to simply rebooting once to get the cursor to appear.
Comment 52 Adam Williamson 2013-11-21 19:26:32 UTC
If it's any use as a data point, the bug never seems to happen when booting live. I booted the TC1 live image ten times in a row in my test VM yesterday without triggering it once. However, the bug often kicks in when I do an install and then boot the installed system - either with a 'normal' boot to gdm and log in, or on the first boot of an installed system, after I create a user account with g-i-s (the cursor works at that point) and am logged into that user account (the cursor vanishes).
Comment 53 Kamil Páral 2013-11-21 22:40:54 UTC
Yes, I've never seen that on LiveCD - maybe gdm autologin works around this bug. I also don't see it on bare metal, just in VM. In VM, I can reproduce it usually in a few minutes. Either constantly reboot -> see gdm -> login -> reboot, or you can also do login -> logout -> login. In both cases, my cursor goes missing in 5-10 attempts.
Comment 54 Dave Airlie 2013-11-22 00:56:00 UTC
hey Kamil, 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.
Comment 55 Adam Williamson 2013-11-22 00:58:28 UTC
In case it's not entirely clear from Dave's comment - I reproduced the bug and checked, and I do see a 'failed to acquire idle monitor proxy' error at the time of login, with a message from the kernel indicating that a new 'spice vdagent tablet' input device had just appeared right above it. So his diagnosis seems plausible as far as I understand it :)
Comment 56 Adam Williamson 2013-11-22 00:59:58 UTC
'journalctl -b | grep -10 monitor' extract: ноя 21 16:51:34 localhost.localdomain gnome-session: SSH_AUTH_SOCK=/run/user/1000/keyring-q5p5Qw/ssh ноя 21 16:51:34 localhost.localdomain rtkit-daemon: Supervising 7 threads of 3 processes of 2 users. ноя 21 16:51:34 localhost.localdomain gnome-session: GNOME_KEYRING_CONTROL=/run/user/1000/keyring-q5p5Qw ноя 21 16:51:34 localhost.localdomain gnome-session: GPG_AGENT_INFO=/run/user/1000/keyring-q5p5Qw/gpg:0:1 ноя 21 16:51:34 localhost.localdomain gnome-session: SSH_AUTH_SOCK=/run/user/1000/keyring-q5p5Qw/ssh ноя 21 16:51:34 localhost.localdomain gnome-session: GNOME_KEYRING_CONTROL=/run/user/1000/keyring-q5p5Qw ноя 21 16:51:34 localhost.localdomain gnome-session: GPG_AGENT_INFO=/run/user/1000/keyring-q5p5Qw/gpg:0:1 ноя 21 16:51:34 localhost.localdomain gnome-session: SSH_AUTH_SOCK=/run/user/1000/keyring-q5p5Qw/ssh ноя 21 16:51:34 localhost.localdomain pulseaudio: [pulseaudio] pid.c: Daemon already running. ноя 21 16:51:34 localhost.localdomain goa: goa-daemon version 3.10.2 starting [main.c:117, main()] ноя 21 16:51:34 localhost.localdomain goa: GoaKerberosIdentityManager: Using polling for change notification for credential cache type 'KEYRING' [goakerberosidentitymanager.c:1393, monitor_credentials_cache()] ноя 21 16:51:35 localhost.localdomain kernel: input: spice vdagent tablet as /devices/virtual/input/input5 ноя 21 16:51:35 localhost.localdomain spice-vdagentd: opening vdagent virtio channel ноя 21 16:51:35 localhost.localdomain gnome-session: (gnome-settings-daemon:2852): power-plugin-WARNING **: failed to turn the panel on: Display is not DPMS capable ноя 21 16:51:35 localhost.localdomain gnome-session: (gnome-settings-daemon:2852): GnomeDesktop-WARNING **: Failed to acquire idle monitor proxy: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Интерфейс «org.gnome.Mutter.IdleMonitor» для пути /org/gnome/Mutter/IdleMonitor/Device10 объекта не найден ноя 21 16:51:35 localhost.localdomain polkitd: Registered Authentication Agent for unix-session:2 (system bus name :1.107 [/usr/bin/gnome-shell], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale ru_RU.UTF-8) ноя 21 16:51:35 localhost.localdomain gnome-session: Gjs-Message: JS LOG: GNOME Shell started at Thu Nov 21 2013 16:51:35 GMT-0800 (PST) ноя 21 16:51:35 localhost.localdomain gnome-session: vmware-user: could not open /proc/fs/vmblock/dev ноя 21 16:51:35 localhost.localdomain gnome-session: Tracker-Message: Importing config file to GSettings ноя 21 16:51:35 localhost.localdomain gnome-session: Tracker-Message: Importing config file to GSettings ноя 21 16:51:35 localhost.localdomain vmusr: [ warning] [GLib-GObject] Attempt to add property ToolsCoreService::tcs-app-ctx after class was initialised ноя 21 16:51:35 localhost.localdomain gnome-session: Entering running state ноя 21 16:51:35 localhost.localdomain vmusr: [ warning] [GLib-GObject] Attempt to add property ToolsCoreService::tcs-prop-thread-pool after class was initialised ноя 21 16:51:35 localhost.localdomain vmusr: [ warning] [vmtoolsd] The vmusr service needs to run inside a virtual machine. ноя 21 16:51:35 localhost.localdomain gnome-session: Tracker-Message: Importing config file to GSettings
Comment 57 Bastien Nocera 2013-11-22 13:14:30 UTC
Reassigning to gnome-desktop as per https://bugzilla.gnome.org/show_bug.cgi?id=706229#c29
Comment 58 Kamil Páral 2013-11-25 09:23:55 UTC
I can confirm that I see the following error in journal when my cursor is missing after login: Nov 25 10:14:00 localhost.localdomain gnome-session: (gnome-settings-daemon:1506): 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/Device10 The error is not present when the cursor is visible.
Comment 59 Rui Matos 2013-11-26 00:22:01 UTC
I wasn't able to reproduce this but given the analysis here and in the GNOME bug I think this scratch build should fix the issue: http://koji.fedoraproject.org/koji/taskinfo?taskID=6224803 Please let me know whether it does.
Comment 60 Adam Williamson 2013-11-26 00:55:38 UTC
Fix looks good here. Five successful logins in a row on a configuration which reproduces the bug very frequently without the scratch build.
Comment 61 Adam Williamson 2013-11-26 01:01:28 UTC
Note for those reproducing with a KVM: #1020393 appears to actually be related here somehow. If you implement the recently-discovered workaround for that bug - disable Spice streaming in your KVM - it seems to make this bug much less likely to occur. So if you want to ensure you can reproduce this bug to test the fix, turn Spice streaming back on again :)
Comment 62 Fedora Update System 2013-11-26 04:08:15 UTC
xorg-x11-server-1.14.4-5.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Comment 63 Kamil Páral 2013-11-26 08:52:59 UTC
(In reply to Rui Matos from comment #59) > I wasn't able to reproduce this but given the analysis here and in the GNOME > bug I think this scratch build should fix the issue: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=6224803 > > Please let me know whether it does. This fixes the issue for me.
Comment 64 Fedora Update System 2013-11-26 12:44:57 UTC
gnome-desktop3-3.10.2-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/gnome-desktop3-3.10.2-2.fc20
Comment 65 Fedora Update System 2013-11-26 18:00:43 UTC
Package gnome-desktop3-3.10.2-2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gnome-desktop3-3.10.2-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-22165/gnome-desktop3-3.10.2-2.fc20 then log in and leave karma (feedback).
Comment 66 Kamil Páral 2013-11-27 09:51:56 UTC
Verified per Bodhi comments.
Comment 67 Fedora Update System 2013-11-29 13:58:02 UTC
gnome-desktop3-3.10.2-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Comment 68 Gianluca Cecchi 2013-12-12 08:19:39 UTC
Hello, it still happens to me running f20 as a VM inside a fedora 19 host On Fedora 20 system I have: gnome-desktop3-3.10.2-2.fc20.x86_64 I confirm that if I send Ctrl+Alt+F2 to the guest in a spice session and then come back to gnome shell desktop I'm able to see the cursor again, as described https://fedoraproject.org/wiki/Common_F20_bugs#Disappearing_mouse_cursor Any logs I can end to solve definitely? On my fedora 19 host: qemu-kvm-1.4.2-14.fc19.x86_64 libvirt-188.8.131.52-2.fc19.x86_64 virt-viewer-0.5.6-1.fc19.x86_64 I'm going to attach my xml file. BTW: I don't see yet Fedora 20 as a Linux system when I install a VM, so I set as Fedora 19
Comment 69 Gianluca Cecchi 2013-12-12 08:20:59 UTC
Created attachment 835654 [details] xml definition for fedora 20 guest
Comment 70 Rui Matos 2013-12-12 09:09:56 UTC
(In reply to Gianluca Cecchi from comment #68) > it still happens to me running f20 as a VM inside a fedora 19 host Let's narrow it down then. Please run $ gsettings set org.gnome.settings-daemon.plugins.cursor active false inside your VM user session. Then do a few VM reboots and logins and check if it happens.
Comment 71 Alon Levy 2013-12-12 09:13:15 UTC
*** Bug 1008141 has been marked as a duplicate of this bug. ***
Comment 72 Gianluca Cecchi 2013-12-12 09:25:15 UTC
One quick test gave the VM pointer ok both on gdm login and then in session. But this kind of operation caused cursor disappearing again in the same session: - settings - displays - select my monitor - change resolution - apply - cursor disappeared - select "apply changes" (without mouse cursor) - resolution has been correctly changed but cursor disappeared again... the first Ctrl+Alt+F2 Ctrl+ALt+F1 sequence didn't get cursor again; the second sequence gave me it. Repeated change screen and same problem. SO I think we have also to test this against proposed resolution. BTW: when selecting apply, I get this in remote-viewer terminal window of my fedora 19 host: (remote-viewer:4512): GSpice-CRITICAL **: display_handle_monitors_config: assertion `config->count > 0' failed (remote-viewer:4512): GSpice-CRITICAL **: display_handle_monitors_config: assertion `config->count > 0' failed (remote-viewer:4512): GSpice-CRITICAL **: display_handle_monitors_config: assertion `config->count > 0' failed (remote-viewer:4512): GSpice-CRITICAL **: display_handle_monitors_config: assertion `config->count > 0' failed
Comment 73 Marc-Andre Lureau 2013-12-12 09:50:36 UTC
*** Bug 1039132 has been marked as a duplicate of this bug. ***
Comment 74 Adam Williamson 2013-12-12 10:09:57 UTC
that really doesn't sound like the same bug...
Comment 75 Gianluca Cecchi 2013-12-12 10:33:17 UTC
I confirm I had booted/used/powered off a couple of times the VM and never got again the cursor problem after setting as in comment#70 Can this gsettings operation put in place during install time or should it be only a thing the user has to run after? BTW: this is indeed ever the best mouse experience in a VM I got! Almost native! At the same time I can always reproduce the problem of display size change as in my comment#72 Adam with your observation are you referring to my comment for which you would like me to open a new bug or to the comment#73 from Marc-Andre? Gianluca
Comment 76 Rui Matos 2013-12-12 10:49:15 UTC
(In reply to Gianluca Cecchi from comment #75) > I confirm I had booted/used/powered off a couple of times the VM and never > got again the cursor problem after setting as in comment#70 Hmm, not good. Are you 100% sure that you have both gnome-desktop3-3.10.2-2.fc20 glib2-2.38.2-2.fc20 ?
Comment 77 Gianluca Cecchi 2013-12-12 10:54:12 UTC
Why not good? I didn't experience the problem after the gsettings command... What did you expect instead? my system (already uploaded xml definition after configuring it as a Fedora 19 VM with default options proposed): [g.cecchi@localhost ~]$ uname -r 3.11.10-301.fc20.x86_64 [g.cecchi@localhost ~]$ rpm -q gnome-desktop3 gnome-desktop3-3.10.2-2.fc20.x86_64 [g.cecchi@localhost ~]$ rpm -q glib2 glib2-2.38.2-2.fc20.x86_64 It has been installed form beta and I don't see any updates available.
Comment 78 Adam Williamson 2013-12-12 12:42:19 UTC
as this has been re-opened, let's drop AcceptedBlocker. I have never seen this again since the fix went in, and I don't think anyone else has reported seeing it either. So even if gianluca is still somehow hitting a problem, I'm not sure this is still a blocker.
Comment 79 Adam Williamson 2013-12-12 12:42:49 UTC
(that makes it a proposed blocker again, so we'll discuss it at go/no-go)
Comment 80 mswal28462 2013-12-12 12:48:52 UTC
I have experienced this problem off and on under Fedora 19. I've since installed Fedora 20 beta. Right after installing about 2 weeks ago and upon the first boot, I experienced this again. I was able to circumvent it with another boot. Then I did the 'yum install update' to pickup all of the fixes since the Beta was produced and have not experienced it at all over the past 2 weeks ... with heave use. I believe the fix was picked up with the update and did fix the problem.
Comment 81 Gianluca Cecchi 2013-12-12 13:05:00 UTC
Hello, I installed this VM on 7/12 using netinst image: Fedora-20-Beta-x86_64-netinst.iso so it picked up needed packages as available on 7/12 after selecting default desktop system. Now it doesn't offer new updates so I think I'm current... If there is any furthr update let me know how to set up for it and I go to test..
Comment 82 Rui Matos 2013-12-12 14:35:04 UTC
Ok, please try the following: 1. Re-enable the cursor plugin in your session: $ gsettings reset org.gnome.settings-daemon.plugins.cursor active 2. Edit the file /usr/libexec/gnome-settings-daemon-localeexec and append --debug on the last line; 3. Then reboot and when you get a login attempt where the mouse cursor doesn't show up, open a terminal and type: $ journalctl -b | grep cursor > g-s-d.log and finally, attach that g-s-d.log file here as well as that session's /var/log/Xorg.0.log .
Comment 83 Gianluca Cecchi 2013-12-12 15:08:58 UTC
[g.cecchi@localhost ~]$ gsettings reset org.gnome.settings-daemon.plugins.cursor active [g.cecchi@localhost ~]$ gsettings get org.gnome.settings-daemon.plugins.cursor active true modified file reboot no cursor run journalctl command and I'm going to attach requested files. BTW: I just deploy a Fedora 20 VM with the same netinst.iso image on an infra based on oVirt 3.3.2 beta, based on Fedora 19 hosts and got same result. Just after install and reboot in the first welcome screen where you have to confirm language in the white centered square and select the various next buttons, I have no cursor... Or the problem is somehow related with the combination Fedora 19 host and Fedora 20 guest, or is a general possible problem. Gianluca
Comment 84 Gianluca Cecchi 2013-12-12 15:09:55 UTC
Created attachment 835851 [details] output of journalctl command
Comment 85 Gianluca Cecchi 2013-12-12 15:10:44 UTC
Created attachment 835852 [details] Xorg log when problem is present
Comment 86 Gianluca Cecchi 2013-12-12 15:13:36 UTC
The qemu command line generated on oVirt host is this: qemu 20771 1 52 14:56 ? 00:38:45 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name f20 -S -machine pc-1.0,accel=kvm,usb=off -cpu Opteron_G2 -m 2048 -smp 1,sockets=1,cores=1,threads=1 -uuid 3b995efa-d334-4794-8da7-7a30a7a06664 -smbios type=1,manufacturer=oVirt,product=oVirt Node,version=19-5,serial=34353439-3036-435A-4A38-303330393338,uuid=3b995efa-d334-4794-8da7-7a30a7a06664 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/f20.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=2013-12-12T14:56:57,driftfix=slew -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/rhev/data-center/mnt/f18engine.mydomain:_var_lib_exports_iso/cc790a86-72e2-4aa2-a0b6-700756c399c3/images/11111111-1111-1111-1111-111111111111/Fedora-20-Beta-x86_64-netinst.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=2 -drive file=/rhev/data-center/mnt/glusterSD/f18ovn01.mydomain:gvdata/d0b96d4a-62aa-4e9f-b50e-f7a0cb5be291/images/2a2097ba-5c1b-4ddd-8f2f-7415df816153/807708ad-cccf-4409-8162-3dbfafa2bf18,if=none,id=drive-virtio-disk0,format=raw,serial=2a2097ba-5c1b-4ddd-8f2f-7415df816153,cache=none,werror=stop,rerror=stop,aio=threads -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=30 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:01:a4:a8:f4:9d,bus=pci.0,addr=0x3,bootindex=3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/3b995efa-d334-4794-8da7-7a30a7a06664.com.redhat.rhevm.vdsm,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/channels/3b995efa-d334-4794-8da7-7a30a7a06664.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel2,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=com.redhat.spice.0 -spice tls-port=5901,addr=0,x509-dir=/etc/pki/vdsm/libvirt-spice,tls-channel=main,tls-channel=display,tls-channel=inputs,tls-channel=cursor,tls-channel=playback,tls-channel=record,tls-channel=smartcard,tls-channel=usbredir,seamless-migration=on -k en-us -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=33554432 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8
Comment 87 Gianluca Cecchi 2013-12-12 16:31:22 UTC
I also made this test that perhaps could give an input. Tried to install Mate Desktop group package I initially get this inconsistency: Error: Package: imsettings-mate-1.6.6-1.fc20.x86_64 (fedora) Requires: imsettings(x86-64) = 1.6.6-1.fc20 Installed: imsettings-1.6.7-1.fc20.x86_64 (@updates-testing) imsettings(x86-64) = 1.6.7-1.fc20 Available: imsettings-1.6.6-1.fc20.x86_64 (fedora) imsettings(x86-64) = 1.6.6-1.fc20 So it seems in beta netinst image itself or in retrieved packages during install there is a package from updates-testing... During install I selected to keep repo as in source. I install the group enabling updates-testing repo During install I got these packages from updates-testing imsettings-mate x86_64 1.6.7-1.fc20 updates-testing 102 k system-config-language noarch 1.4.0-6.fc20 updates-testing 105 k dnf noarch 0.4.9-1.fc20 updates-testing 423 k hawkey x86_64 0.4.6-1.fc20 updates-testing 64 k libsolv x86_64 0.4.0-2.git4442b7f.fc20 updates-testing 315 k libteam x86_64 1.9-1.fc20 updates-testing 41 k mesa-libGLU x86_64 9.0.0-4.fc20 updates-testing 196 k python-hawkey x86_64 0.4.6-1.fc20 updates-testing 53 k t1lib x86_64 5.1.2-14.fc20 updates-testing 164 k teamd x86_64 1.9-1.fc20 updates-testing 99 k After booting, if I select Mate Desktop my cursor is ok, if I log out and then login in Gnome, sometimes I keep getting the cursor, sometimes not.... If after boot I initially select Gnome I don't get the cursor. With Mate in some preliminary tests done, I always get the cursor. BTW: in Gnome Desktop the logout function is counter intuitive... arrow and then logout in spotted menu... I'm going to attach full yum session log... Gianluca
Comment 88 Gianluca Cecchi 2013-12-12 16:32:19 UTC
Created attachment 835889 [details] yum script session log you can pen yu.log file or replicate the session with scriptreplay -t yum.err -s yum.log
Comment 89 Gianluca Cecchi 2013-12-12 16:33:17 UTC
Created attachment 835890 [details] script session timing file you can open yum.log file or replicate the session with scriptreplay -t yum.err -s yum.log
Comment 90 Gianluca Cecchi 2013-12-12 16:34:26 UTC
Created attachment 835891 [details] list of rpm installed on the system
Comment 91 Kamil Páral 2013-12-12 18:19:56 UTC
Discussed at Go/No-Go meeting on 2013-12-12 . This is a RejectedBlocker. This bug hasn't been seen by a preponderance of users and there are known workarounds from when the bug was first proposed.  http://meetbot.fedoraproject.org/fedora-meeting-2/2013-12-12/
Comment 92 Christian Stadelmann 2013-12-16 11:51:31 UTC
I ran into this bug again today after updating gnome-shell to 184.108.40.206-3.fc20 from updates-testing. This bug was not present for this setpu in all previous versions of gnome-shell in f20/updates/updates-testing repos since alpha.
Comment 93 Kamil Páral 2014-01-06 16:02:27 UTC
This has re-appeared in Rawhide. I've just seen it in my Rawhide VM (F20 host).
Comment 94 Adam Williamson 2014-01-14 02:54:45 UTC
yup, I've just seen it in a Rawhide VM too.
Comment 95 Kamil Páral 2014-01-16 07:43:50 UTC
Created attachment 850892 [details] journal from F21 Now I have seen it even on bare-metal Fedora Rawhide. Restarting gnome-shell fixes the issue. Attaching logs. In the logs, I just booted into the desktop, and then used alt+f2->r to restart gnome-shell.
Comment 96 Kamil Páral 2014-01-16 07:44:36 UTC
Created attachment 850893 [details] xorg log from F21
Comment 98 Zbigniew Jędrzejewski-Szmek 2014-06-26 20:56:06 UTC
I'm seeing that too with a rawhide VM with gdm.
Comment 99 Bastien Nocera 2014-08-13 10:53:48 UTC
There were 2 problems, one on the client side with a gnome-desktop/gnome-settings-daemon interaction bug, which has been fixed, and another bug in the QXL driver (which might have been fixed in F20 updates). FWIW, the cursor *is* supposed to disappear when you log in. It should reappear if you move a mouse or trackball. It will not reappear if you use a touchscreen. Seeing as the latest comments likely have nothing to do with the original bug(s) (which got fixed), I'll close this. File a new bug against your graphics driver if this happens again, before punting this to gnome-settings-daemon. The intel driver in rawhide/F21 is particularly buggy (double-cursors on rotation, glitches, etc.) so it wouldn't surprise if this was related (ditto the lesser maintained drivers, like Kamil's ATI driver).