Bug 1008965

Created attachment 798791 [details]
gdm :0.log

Created attachment 798793 [details]
journal

Created attachment 798794 [details]
Xorg.0.log

In the logs above, I started the VM, logged in, noticed that my cursor is invisible, and gathered the logs.

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.

I have seen it several more times, as same as Petr Schindler. It seems that the problem frequency increased with Alpha RC3.

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.

I've just met it on bare metal. So I suppose it is happening on hardware too.

Created attachment 799803 [details]
gdm log

Created attachment 799804 [details]
output from journalctl -a

Created attachment 799805 [details]
Xorg.0.log

kparal already said he's seen it *sometimes* on metal, just not as often.

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 :-))

(In reply to Karel Volný from comment #13)
In that case I guess this should be assigned to xorg, rather than gnome-shell.

Er, I wouldn't be convinced that Karel's is the same issue, from the descirption.

(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 :-)

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

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.

There is a patch here:
https://bugzilla.gnome.org/show_bug.cgi?id=706229#c12

Discussed during 2013-09-25 Blocker Review Meeting [1]. 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.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-09-25/

Reproposing for Final and fixing FE tags.

i see this on kde f19 too and switching vt works

I see this bug on F19 with Gnome too and switching to tty and back works for me, too.

(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

Will this bug be fixed in Fedora 20? The bug is really annoying. Thank you for clarification.

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.

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

(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.

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

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.

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.

Is there a command-line utility that can check and/or set the state of the mouse cursor?

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.

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).

(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.

(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.

thats a bug any motion of the pointer, whether mouse or touchpad, should make it appear.

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.

How does one set the Priority/Severity?  This problem is pretty urgent to get fixed.  Without a mouse/cursor, the system is effectively unusable.

"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.

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.

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.

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?

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?

(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.

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.

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.

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

(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.

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.

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.

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).

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.

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.

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 :)

'journalctl -b | grep -10 monitor' extract:

ноя 21 16:51:34 localhost.localdomain gnome-session[2796]: SSH_AUTH_SOCK=/run/user/1000/keyring-q5p5Qw/ssh
ноя 21 16:51:34 localhost.localdomain rtkit-daemon[508]: Supervising 7 threads of 3 processes of 2 users.
ноя 21 16:51:34 localhost.localdomain gnome-session[2796]: GNOME_KEYRING_CONTROL=/run/user/1000/keyring-q5p5Qw
ноя 21 16:51:34 localhost.localdomain gnome-session[2796]: GPG_AGENT_INFO=/run/user/1000/keyring-q5p5Qw/gpg:0:1
ноя 21 16:51:34 localhost.localdomain gnome-session[2796]: SSH_AUTH_SOCK=/run/user/1000/keyring-q5p5Qw/ssh
ноя 21 16:51:34 localhost.localdomain gnome-session[2796]: GNOME_KEYRING_CONTROL=/run/user/1000/keyring-q5p5Qw
ноя 21 16:51:34 localhost.localdomain gnome-session[2796]: GPG_AGENT_INFO=/run/user/1000/keyring-q5p5Qw/gpg:0:1
ноя 21 16:51:34 localhost.localdomain gnome-session[2796]: SSH_AUTH_SOCK=/run/user/1000/keyring-q5p5Qw/ssh
ноя 21 16:51:34 localhost.localdomain pulseaudio[2868]: [pulseaudio] pid.c: Daemon already running.
ноя 21 16:51:34 localhost.localdomain goa[2910]: goa-daemon version 3.10.2 starting [main.c:117, main()]
ноя 21 16:51:34 localhost.localdomain goa[2910]: 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[558]: opening vdagent virtio channel
ноя 21 16:51:35 localhost.localdomain gnome-session[2796]: (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[2796]: (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[576]: 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[2796]: 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[2796]: vmware-user: could not open /proc/fs/vmblock/dev
ноя 21 16:51:35 localhost.localdomain gnome-session[2796]: Tracker-Message: Importing config file to GSettings
ноя 21 16:51:35 localhost.localdomain gnome-session[2796]: Tracker-Message: Importing config file to GSettings
ноя 21 16:51:35 localhost.localdomain vmusr[3039]: [ warning] [GLib-GObject] Attempt to add property ToolsCoreService::tcs-app-ctx after class was initialised
ноя 21 16:51:35 localhost.localdomain gnome-session[2796]: Entering running state
ноя 21 16:51:35 localhost.localdomain vmusr[3039]: [ warning] [GLib-GObject] Attempt to add property ToolsCoreService::tcs-prop-thread-pool after class was initialised
ноя 21 16:51:35 localhost.localdomain vmusr[3039]: [ warning] [vmtoolsd] The vmusr service needs to run inside a virtual machine.
ноя 21 16:51:35 localhost.localdomain gnome-session[2796]: Tracker-Message: Importing config file to GSettings

Reassigning to gnome-desktop as per https://bugzilla.gnome.org/show_bug.cgi?id=706229#c29

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[1447]: (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.

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.

Fix looks good here. Five successful logins in a row on a configuration which reproduces the bug very frequently without the scratch build.

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 :)

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.

(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.

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

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).

Verified per Bodhi comments.

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.

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-1.0.5.7-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

Created attachment 835654 [details]
xml definition for fedora 20 guest

(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.

*** Bug 1008141 has been marked as a duplicate of this bug. ***

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

*** Bug 1039132 has been marked as a duplicate of this bug. ***

that really doesn't sound like the same bug...

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

(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

?

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.

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.

(that makes it a proposed blocker again, so we'll discuss it at go/no-go)

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.

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..

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 .

[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

Created attachment 835851 [details]
output of journalctl command

Created attachment 835852 [details]
Xorg log when problem is present

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

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

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

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

Created attachment 835891 [details]
list of rpm installed on the system

Discussed at Go/No-Go meeting on 2013-12-12 [1]. 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.

[1] http://meetbot.fedoraproject.org/fedora-meeting-2/2013-12-12/

I ran into this bug again today after updating gnome-shell to 3.10.2.1-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.

This has re-appeared in Rawhide. I've just seen it in my Rawhide VM (F20 host).

yup, I've just seen it in a Rawhide VM too.

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.

Created attachment 850893 [details]
xorg log from F21

Created attachment 850894 [details]
rpm -qa from F21

I'm seeing that too with a rawhide VM with gdm.

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).