Description of problem:
I am using Fedora 19 beta x86_64, with Cinnamon DE.
After logging in, when my desktop appears, my mouse cursor is invisible. I can use it by guessing its position, but it remains invisible.
My workaround is to do CTRL+ALT+F2, then CTRL+ALT+F1, right after logging in. Then my cursor is visible at last.
How reproducible: Always
Steps to Reproduce:
1. Start the computer
2. Login screen appears. I log in.
3. Cinnamon loads up.
Actual results: My destop is loaded, but the mouse cursor is invisible.
Expected results: The mouse cursor should not disappear.
Some updates seem to have solved the problem. I'll close the bug then.
Ok, I was wrong, it just happened when turning on my computer this morning. I guess I should have written "How reproducible: half the time". I had decided to close the bug after two good startups in a row; I should have tested more...
Is there any way to reopen?
Additional information: the problem just occurred when opening a Gnome 3 session. The problem is not linked to Cinnamon.
Same thing happens to me, F19 stable updated from 18 via fedup. Cursor is invisible after login for about 1 minute then it is visible.
Same problem. Seems to occur if I move the mouse in gdm just before the session is started (after entering password). Log out then log in again and mouse is then visible.
And, more annoying, cursor disappears when watching a video with ffplay
How to reproduce:
Doing CTRL+ALT+F2, then CTRL+ALT+F1, makes the cursor visible again.
(In reply to Edouard Bourguignon from comment #7)
> And, more annoying, cursor disappears when watching a video with ffplay
> How to reproduce:
> ffplay /usr/share/help/te/evince/figures/synctex_screencast.ogv
> Doing CTRL+ALT+F2, then CTRL+ALT+F1, makes the cursor visible again.
It doesn't reproduce here.
but did you see the cursor disappearing when the mouse is not moving? The problem is that on my machine with the intel driver, the mouse is not showing again if you move or the movie end. Maybe it's a different bug. On my other machie with radeon driver, I only have the mouse disappearing at startup, not with ffplay.
I have the same problem on my F19 system. Sometimes the cursor doesn't show up. I switch to a VT then to the X11 again, press some keys like Ctrl, Alt, etc (quite randomly) and it comes up.
Which video driver are you using?
I'm using Nouveau and my display adapter is
VGA compatible controller: NVIDIA Corporation G94GL [Quadro FX 1800] (rev a1)
BTW the cursor appears in GDM and disappears after login. Today the cursor came after a while without switching to VT and coming back.
BTW I'm using gnome 3 and not cinnamon.
(In reply to Ozan Çağlayan from comment #13)
> BTW I'm using gnome 3 and not cinnamon.
Thank you for the additional info, it is probably a graphics driver issue.
Reassigned to mesa.
I am seeing this issue on the Fedora 19 64bit install with intel driver. This is using Gnome 3.
Switching to the intel SNA setting in X makes it happens less but it still happens.
wow can't use openshot, mouse cursor dissappears when idle and never reappears. Have to quit openshot, cltr+alt+f2 then back to f1 and cursor is visible again...
Same issue using Fedora 19 with Cinnamon. I have not experienced the problem with GNOME 3, but my wife uses Cinnamon and often loses the cursor. The workaround of switching to the VT and then back works most of the time, though I occasionally need to switch a couple of times before I see the cursor.
I'm using an Asus EeePC 1001PXD with an Atom processor and an Intel chipset:
I haven't associated the behavior with any specific application; my wife typically uses Firefox on this system, and rarely opens other utilities.
(In reply to John F Sullivan from comment #17)
> Same issue using Fedora 19 with Cinnamon. I have not experienced the
> problem with GNOME 3, but my wife uses Cinnamon and often loses the cursor.
> The workaround of switching to the VT and then back works most of the time,
> though I occasionally need to switch a couple of times before I see the
> I'm using an Asus EeePC 1001PXD with an Atom processor and an Intel chipset:
> I haven't associated the behavior with any specific application; my wife
> typically uses Firefox on this system, and rarely opens other utilities.
I'm not seeing any cursor issues here with my Emachines netbook (atom)
[leigh@localhost ~]$ rpm -qa cinnamon\* kernel *\intel |sort
[leigh@localhost ~]$ uname -r
I'm considering back-porting my git build to F19
I just updated my system to kernel-3.10.10-200.fc19.x86_64. I'll see if this change modifies the behavior.
The original bug report specified x86_64, which is the environment in which I see the issue. You're using the i686 packages. Could the architecture explain the difference in behavior? Is it possible to install the x86_64 build on the Emachines netbook?
I'm seeing this on a completely-updated fresh install of F19, after a couple of reboots. I'm using the 64-bit install with Intel Graphics.
Same here, Fedora 19 x86_64 Gnome 3. The pointer is visible on login screen, but after supplying credentials is disappears. Ctrl+F2 - Ctrl+F1 helps though.
This seems to be happening on any intel based machine I have setup.
I have seen this on at least 3 of my machines. So this bug I would expect would be effecting a lot of people.
Is it possible to get some traction on this? Its annoying and will turn people away from Fedora.
I also have this bug, with xorg-x11-drv-intel-2.21.12-2.fc19.x86_64 and a GNOME 3 session, on a machine freshly upgraded from Fedora 17 via FedUp. It happens at every single login, and it is indeed REALLY annoying. Trying to decide whether to downgrade back to F17.
I'm experiencing this most often after yum update and reboot. Fedora 19 (3.11.3-201.fc19.x86_64), Lenovo W520, three displays, NVIDIA Quadro 2000M, NOUVEAU driver. Ctrl-Alt-F2 + Ctrl-Alt-F1 works to fix it.
May be related to:
In a EEPC 1215N after an upgrade from F17 to F19 I'm exerienced the same, under KDE.
If I start X in a failsafe environment (with only xterm), this is not affected.
The issue is present in F20 beta as well
Fresh install of F19, Intel i3, Asus Mo-Board, Intel graphics.
As for turning people off from Fedora... ya. I bought, for real money, the first Red Hat release. I've been loyal for years. But lately too much key OS related stuff just doesn't work out of the box anymore. I used to put Fedora on everything, I have 7 different machines, two are still Fedora, the reset are now Ubuntu. I don't feel good about this, but that two may soon become 1 or 0.
I've had no problems with F19, but my new installed from scratch on different partition F20 does this when I restore my old home directory and login with all my restored settings and session (a custom session where I run fvwm manually).
If I go back to the new /home and running gnome 3 everything works fine.
I don't know when I'll have time to binary search through all the settings and find out which one makes my pointer come back. I haven't tried the vterm switching gimmick mentioned above to see if it works.
There is a perfectly wonderful mouse pointer on the login screen, it just disappears as soon as I login, which doesn't really sound like a video driver problem (I'm using radeon driver).
Googling around the web, I found another post that said they fixed this problem by running dconf-editor and turning off the "active" flag in:
I have just done that and it certainly seems to have fixed the problem for me. I don't know why this only happens in fedora 20. On fedora 19 this plugin was enabled and I had no problems with invisible cursors.
I've been experiencing this problem since I clean installed f20 (I never had it with f19). I have Intel mobo/graphics with kde-redhat (but gnome is also installed, but I haven't ever logged in yet).
It appears to occur when I resume the computer from suspend. I'm not certain about boot/reboot, as I suspend/resume for about 3-4 days before I power down/up. I might have also experienced it intermittently occurring during a session. I tried switching to another virtual terminal and back, but that didn't solve it. I have never waited a full minute, either. What solves it is to unplug/replug the usb mouse. I have not yet tried the dconf-editor method from Comment 30.
Waiting a minute, okay, about five, doesn't work.
I got the kernel 3.12.7-300 a few days ago. I don't know if it was that, but since around that time the problem has not recurred.
I just finished switching to fedora 20 at home and I'm running kernel
Didn't help for me. Had to disable the "cursor" plugin in settings daemon to get my cursor back.
I have intel graphics at home and radeon graphics at work and had the same disappearing cursor on the switch to f20 in both machines, so I don't think it is a video driver problem.
There was a new kernel this morning, and now, it has happened again. I don't know if there was something good in the last kernel, 3.12.7-300, that has gone sour in 3.12.8-300, or if it was just a fluke that I experienced no invisible mouse pointer during the use of the former.
Heads up! This is still an issue with:
same with me here now just replace my f18 to fedora 20 on my ASUS 1215n netbook and i can't see my mouse cursor after login.
I have this issue too on my Thinkpad x201 with Fedora 20 and kernel 3.14.7-200.fc20.x86_64. As of today, this is the latest kernel. The issue is really annoying. The mouse pointer doesn't appear until after a minute or two after GNOME login.
Nineth: this issue happened to me with F19 after an upgrade from F18, and never got fixed, but it's not there on my new thinkpad with a clean F20 install. Am I right that various keyboard shortcuts (e.g. the screen brightness setting) are also non-responsive during the startup period when the pointer isn't there?
I now tend to think this is actually an issue not with the X server (or only partly) but actually with the startup sequence of the GNOME session -- something gets stuck in a timeout for a couple of minutes, and the mouse pointer + the handling of keyboard shortcuts only become available afterwards.
Back on my old Thinkpad I looked at the X server error log and system log files to try and figure out what was stuck for that period, but couldn't find out any obvious culprit. There were various repeated messages in the syslog about colord failing to start, so that would be one place to look, but I am not convinced that it was the explanation.
Any comments on this from the maintainers? This is quite an annoying issue for a while and pretty much increases the boot time from about 1 minute to 3 minutes.
Got it "every time" (actually tried twice) today booting https://kojipkgs.fedoraproject.org//work/tasks/6483/7116483/Fedora-Live-Xfce-x86_64-rawhide-20140708.iso under qemu 1.4.2 running on a Toshiba Qosmion X770. After clicking in the qemu window, the mouse arrow disappears, but the screen reacts normally when rolling over the icons, or if the mouse buttons are pushed.
Created attachment 916519 [details]
Anything further on this? I still experience this. Even if this issue is not fixed, a manual procedure to fix it permanently will be appreciated. Looks like we have neither even nearly 1.5 years after this bug was filed!
(In reply to Nineth from comment #43)
> Anything further on this? I still experience this. Even if this issue is not
> fixed, a manual procedure to fix it permanently will be appreciated. Looks
> like we have neither even nearly 1.5 years after this bug was filed!
The fix in comment #30 worked for me.
Looks a duplicate of bug 1008965.
Reproduced on Fedora 20 - cursor disappears when logging in first time after boot. Closing the laptop lid and logging in again show the cursor.
I did not test if switching virtual console helps.
(In reply to Nir Soffer from comment #45)
> Looks a duplicate of bug 1008965.
This is not a duplicate of that bug since that bug has "rarely" for "how reproducible". The title itself says that the mouse disappears sometimes while this one is *always* reproducible.
Happens with a Fedora Rawhide fresh netinstall, as of today. I'm using radeonsi driver. Gnome version is 3.14.1
I just had this bug for the first time.
This message is a notice that Fedora 19 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 19. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 19 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening, as this is still an issue on Fedora 20.
Workaround in comment #30 worked for me.
This stopped happening a long time, so I believe it could be marked as closed.
This bug is currently assigned to an unsupported release. If you think this bug is still valid and should remain open, please re-assign it to a supported release (F22, F23) or to rawhide.
Bugs which will be assigned to an unsupported release are going to be closed as EOL (End Of Life) on January 26th, 2016.