Changing resolution with "xrandr -s" made the mouse pointer disappear. Same thing happens unloading old drm + nvidia modules and loading new drm + nouveau modules. Soft-rebooting with kexec doesn't get it back. The only way to recover it was to hard reboot the system.
I think this is most likely caused by the hardware issue fixed for nv in bug 7309. I'm not sure where the fix (delay) should go in nouveau however, since simply delaying for a second each time the cursor is turned off is not an option, as the hwcursor gets turned on and off many times during normal operation.
I've found another way to make the pointer dissapear. Simply running "sudo nvclock -s" does it. I don't know wether this is the same thing or not, but visually I get the same result.
The nvclock disappearance also happens on nv40. But it only happens to me when the cursor is over the xterm window when nvclock is invoked. I've noticed that xterm hides the cursor when it is over the window and "enter" is pressed. If the cursor is outside the xterm window when nvclock is invoked then the cursor doesn't disappear. Switching VT's brings the cursor back, so it doesn't seem to be the same thing.. This should definitely be a race between nvclock and nouveau, as the cursor is immediately hidden when you press the "enter" key, and at the same time nvclock is messing with the registers.
Hello everyone, I'm facing the same problem (invisible cursor) in this bugreport with my card [1]. It happens whenever I use xrandr or switch VT's (also s2disk is affected). Unloading and reloading the modules does not 'cure' it. However, it seems that adding HWcursor with parameter 0 to the device section in xorg[2].conf seems to work around this. I have build my own vanilla kernel[3] and pulled the drivers from git[4]. I would like to help to solve this problem (if possible). I fairly know my way around and this system is not important for stuff like e.g. homework... 1: Charlie:~# lspci -v -v -s 00:05.0 00:05.0 VGA compatible controller: nVidia Corporation C51 [Geforce 6150 Go] (rev a2) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Presario V6133CL Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 18 Region 0: Memory at b2000000 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at c0000000 (64-bit, prefetchable) [size=256M] Region 3: Memory at b1000000 (64-bit, non-prefetchable) [size=16M] [virtual] Expansion ROM at 50000000 [disabled] [size=128K] Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 2: X.Org X Server 1.4.2 Release Date: 11 June 2008 Build Operating System: Linux Debian (xorg-server 2:1.4.2-9) 3. Linux Charlie 2.6.28 #1 Sun Dec 28 17:27:07 CET 2008 i686 GNU/Linux 4. drm-58d557c73b9e4ad1964fd083abeec74875c141cb xf86-video-nouveau-5d281a2439de1e8c1848b6b700f30476575966e0
The nvclock mouse disappearance when cursor is over xterm also happens on my powerbook with nv34. Switching to and from vts makes it reappear again. d.
It seems like that latest git fixed my problem. I'm using HWcursor again and it never disappeared since I updated nouveau_drv.so from the latest git :) (cf65b875) I hope that it is the same case for you.....
(In reply to comment #6) > It seems like that latest git fixed my problem. I'm using HWcursor again and it > never disappeared since I updated nouveau_drv.so from the latest git :) > (cf65b875) I hope that it is the same case for you..... Ronald, if you could reproduce it easily on earlier versions (as you say, changing resolution with xrandr and VT switching seems to trigger it), will you git bisect xf86-video-nouveau over the last month to see what change has affected this; there's nothing obvious in the changelog?
Sorry, I haven't been exactly straightforward. It seems that the latest git only fixed the problem that the cursor disappeared after a few resumes from s2disk. Restarting the x-server, logging on and off in an x-session and xrandr still make it disappear (I will also test with vt-switching when I have time). In my case the bug is rather badly reproducible but I will try to help as much as I can.
Created attachment 22251 [details] [review] fix some minor consistency issues Here's a minor patch that could be worth a try
Created attachment 22252 [details] [review] use the PCRTC regs for cursor setting and *on top of the previous patch*, this implements cursor setting more like the way the nvidia blob does, so could also be worth a go
(In reply to comment #10) > Created an attachment (id=22252) [details] > use the PCRTC regs for cursor setting > > and *on top of the previous patch*, this implements cursor setting more like > the way the nvidia blob does, so could also be worth a go > Sorry for the late reply, I had the assumption that I was notified of changes in this bug (I added myself to the CC list right now). OK Versions: nouveau-f1099810bb3cfe451877667a0224eb3d664e442f Question: The patch: Always allocate 2 hw cursors. Is it worth another try since I just downloaded my source minutes or seconds *before* it was applied? Want me to retry with it? drm-97fdadee6a79f9406a55c235ee46104814321152 I used a small script that changed the resolution. Kept it going for a minute changing resolution every 2 seconds. The cursor stayed 'alive'. Logging out and rebooting the X-server caused the cursor to disappear. Trying to kill the X server just after the cursor disappeared made the kernel unhappy and my system somehow crashed. (want more data?) I also noticed something else: Whenever I change the resolution with xrandr. If you move the cursor during the change the screen seems to go 'white'. I noticed this as well sometimes when the X-server crashed because of the blob after a severe error. However, if I stop moving the cursor, the screen restores after a while since another xrandr -s [1-5] command is issued effectively restoring the display. Please let me know if you need more information / want me to do more testing.
FTR: The above data was *with* your patches [1] applied! [1]: fix some minor consistency issues and fix some minor consistency issues
(In reply to comment #12) > FTR: The above data was *with* your patches [1] applied! > > [1]: fix some minor consistency issues and fix some minor consistency issues Hi Ronald, thanks for testing. Relative to how it worked previously, would you then say the patches improved the behaviour - previously xrandr broke the cursor, but now it does not, correct? If they did improve it, and you have time, could you test if the patch from comment 9 alone is enough to give the improvement, or whether both are required? The "allocate 2 hw cursors" patch is not relevant to the problem, so update git ddx or not as you choose. git drm has an addition http://cgit.freedesktop.org/mesa/drm/commit/?id=9c8d634e687a5a5b5d314b3fd5b34cc17a217139 ("nouveau: don't try to traverse non-existent lists"), which may well fix the unhappy kernel/system crash problem; let me know if it does not, and that problem can be investigated.
Here we go again :) Versions: nouveau-98b8cada6c355d437925a92ef0413e96751ed567 drm-9c8d634e687a5a5b5d314b3fd5b34cc17a217139 I did some more extensive testing (kept the script running longer). It seems that the cursor always dssappears no matter if I patched it [1] or not. 1: fix some minor consistency issues *and* use the PCRTC regs for cursor setting or fix some minor consistency or no other patches at all Using both patches, the cursor disappears. Trying to: - Switch VT's (ctrl + alt + f1 etc) does not restore it - Restart X-server does not restore it However, the oops I reported seems fixed with latest git.
Reconfirming with latest git that problem still exists: nouveau-0387ac32bef6c714f54917d5d36071ae1224458c
Ok, I don't have any more ideas at the moment, if those patches do not improve it at all. If I think of something else later I'll put it on this bug.
An unlikely idea, but might be worth a go, is the following: 1) get the nvidia version of radeontool: git clone git://anongit.freedesktop.org/~stuart/radeontool; cd radeontool; make 2) start X using the nvidia proprietary driver 3) read the values of 0x9200, 0x9210, and 0x9220: ./radeontool regmatch 0x9200 (for all three registers) make a note of the values 4) start X using the nouveau driver, set 0x9220, 0x9200, 0x9210 (in that order) to the values read in step 3 ./radeontool regset 0x9220 0xSOME_VALUE (for all three registers/values) 5) attempt to reproduce disappearing cursor using vt switching / resolution changes as described in previous comments (note: don't restart X, that will over-write the changes you made in step 4) 6) report here whether this game made any difference
Hi, Sorry for the late response, but here is some data... > An unlikely idea, but might be worth a go, is the following: Always worth a try :) > 1) get the nvidia version of radeontool: > git clone git://anongit.freedesktop.org/~stuart/radeontool; cd radeontool; make Done. Radeontool-version: 0b5dab7add1a69103a7dfd912f188f46839b4623 > 2) start X using the nvidia proprietary driver Done. X-version: 1.5.1 Nvidia-version: 180.44 > 3) read the values of 0x9200, 0x9210, and 0x9220: > ./radeontool regmatch 0x9200 (for all three registers) > make a note of the values Done. Values: 0x9220 0x00000008 0x9200 0x00000798 0x9210 0x000000fa > 4) start X using the nouveau driver, set 0x9220, 0x9200, 0x9210 (in that order) > to the values read in step 3 > ./radeontool regset 0x9220 0xSOME_VALUE (for all three registers/values) Nouveau-driver version: 11be9a982073d66a68cd3db2bfc611eb58d3ea81 Drm-driver version: 51d6346f9f3c425f49e57d185530c6bcaeb94f5e Done. Original values (just for information): 0x9220 0x00010000 0x9200 0x000014c8 0x9210 0x00000271 After setting the regs to the same values as they are with the nvidia driver I verified they ware saved (it did not move back to the old values). > 5) attempt to reproduce disappearing cursor using vt switching / resolution > changes as described in previous comments (note: don't restart X, that will > over-write the changes you made in step 4) Only changing VT made the cursor already go away... > 6) report here whether this game made any difference Done :) Note: Just to let you know: In xorg.conf I *removed* any options that influence the nouveau driver. (In my case this was only HWcursor). Greets, Ronald
I was wondering if it will be usefull if I tested the above with newer versions of the blob? And how about using the patches from comment 9 and 10? Will that give any usefull information? Ronald
Hi, I would like to confirm this bug still exists almost a year later on: kernel-2.6.31.12-174.2.22.fc12.i686.PAE It only happens on my laptop's external VGA display, never on the LVDS.
(In reply to comment #20) > Hi, > > I would like to confirm this bug still exists almost a year later on: > > kernel-2.6.31.12-174.2.22.fc12.i686.PAE > > It only happens on my laptop's external VGA display, never on the LVDS. > I had the cursor disappearing from the LVDS screen. I think that is a seperate bug? However, after a short 'vacation' to Ubuntu (got fed up with Gentoo, but somehow I went back...) I went back to Gentoo and reïnstalled the most recent nouveau/nouveau-drm/libdrm stuff you can get with gentoo xorg-server-1.6.5 and I never had the problem. However, I'm still not sure....
(In reply to comment #20) > Hi, > > I would like to confirm this bug still exists almost a year later on: > > kernel-2.6.31.12-174.2.22.fc12.i686.PAE > > It only happens on my laptop's external VGA display, never on the LVDS. > We don't know which nouveau code fedora ships, you need to report on their bug tracker. Otherwise, make sure you have an up-to-date ddx : http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/ But you might need a specific git version of libdrm if you want ddx to compile and not having to upgrade nouveau drm (kernel module).
Bump, Bug exists even with gitty ddx, the rest X/mesa packages from ubuntu security team, SWAT, XXX Strike force, Crack pushers... Note: when typing and mouse pointer is visible, didn't happen, however when typing and mouse pointer were invisible(when over terminal), bug can be reproduced by running nvclock with one of the command flags,(i used -T) printk appends lines, like: [ 678.802596] nvclock:18902 freeing invalid memtype fa000000-fa010000 [ 679.004591] nvclock:18902 freeing invalid memtype fa010000-fa030000 Cheers.
Running the gtk version, didn't cause mouse missings.
Hi Jalil I believe opening a bug would be a better idea, than resurrecting this one Nevertheless, please read below Note that nvclock is known to rarely cause issues as it touches the card behind nouveau's back Can you please share a bit light rather than stating "issue still exist" The more info you provide the easier/faster it will be resolved Things you can/should include are mentioned in the bugs[1] section Here is a short list * Dmesg + Xorg.log * Commit on which the components(kernel,ddx....) are based Cheers Emil [1] http://nouveau.freedesktop.org/wiki/Bugs
This bug is still here, I'm currently using: xf86-video-nouveau-0.0.16_pre20120322 libdrm-2.4.33 xorg-server-1.12 kernel 3.5rc1 (vanilla, not nouveau HEAD) The cursor icon (sometimes!) dissappears after: - extensive VT switching - switching resolution with xrandr - plugging VGA-1 - (new) keeping the laptop idle for a while I'm bluntly reopening this bug, please feel free to close it. However, to my opinion this same issue is still here, so reopening another bug seems pointless. Ronald
Sidenote, disabling HWCursor in xorg.conf seems to resolve the issue. However, if I leave my X running and switch to TTY1 everything is fine. However, when I switch back (TTY1 -> TTY7) Xorg dies. The screen shows up very dim for a short while, hangs and then X restarts.
Hello! I experience the mouse cursor disappearance often on my laptop with NVidia GeForce Go 6100 chip after the screen blanking. Although, it has never happened on my desktop PC with NVidia GeForce 7300GT (I use Nouveau driver for it as well). Some time ago somebody suggested me to set the 'HWCursor' option off, and it seemed to prevent the cursor from disappearing, but now I cannot turn this option off again because X-server does not start at all in this case. Regards, Vladimir
With: xf86-video-nouveau-1.0.3 libdrm-2.4.39 I have encountered this bug again. Altough, it seems to occur less often as development on this driver progresses. The difference with this observation was that I had my laptop connected to a TV through VGA and that the cursor on the TV was invisible yet it was still visible on the laptop. Don't know if this information is obvious or unuseful, but reporting won't hurt I guess.
After a recent upgrade to 3.8.0 kernel, I encountered the cursor disappearance again, although I haven't observed it for last few months (with 3.7 branch kernels, for example), but it of course may be just a coincidence. What about other users' observations? Can somebody confirm or contradict this? Vladimir
I happens less frequent for me when using the laptop without a TV or beamer connected. It still happens more often when I switch the TV resolution.
*** Bug 60951 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > I think this is most likely caused by the hardware issue fixed for nv in bug > 7309. I'm not sure where the fix (delay) should go in nouveau however, since > simply delaying for a second each time the cursor is turned off is not an > option, as the hwcursor gets turned on and off many times during normal > operation. I recently tried the nv driver on gentoo and it also suffers from the same problem -- always reproductible: just wait enough with an open X session. The problem might then well be in xorg itself...
That should not be the same bug. One of the other duplicate bugs #7309 mentions this: http://cgit.freedesktop.org/xorg/driver/xf86-video-nv/commit/?id=7f281be7e53ac274016a6af6b2b5dc6f8bddb810 However, comment #1 mentions that this is just a hack which make all other cards suffer a performance penalty. I think you are suffering from another bug with the same symptom??
Created attachment 94589 [details] [review] sleep for a second after hiding cursor This patch is the equivalent of http://cgit.freedesktop.org/xorg/driver/xf86-video-nv/commit/?id=7f281be7e53ac274016a6af6b2b5dc6f8bddb810 (but restricted to nv4e). Hopefully the cursor isn't disabled from inside interrupts, or this will go splat. I'm not suggesting something like this for inclusion into the kernel, but it'd be good to verify that the same workaround works in the kernel.
This has not hapenned for me in ages. Verifying that will be very difficult. It happens highly occassionally.
(In reply to comment #36) > This has not hapenned for me in ages. Verifying that will be very difficult. > > It happens highly occassionally. Ah, I thought there was a consistent repro, e.g. on every modeset. Well, don't worry about it.
If I happen to find a good scenario that reproduces this I will report back and try the patch. It varies from kernel to kernel. It was a little worse for a while (v3.8), but it has not happenned since v3.12.
(In reply to comment #38) > It varies from kernel to kernel. It was a little worse for a while (v3.8), > but it has not happenned since v3.12. I just wanted to report that it has just happened two times in a row on my machine with 3.12.6 kernel.
What hapenned before it occurred? VT switch?
(In reply to comment #40) > What hapenned before it occurred? VT switch? I just turned my latop on, logged-in with SLIM and saw no mouse pointer on the screen. I rebooted the machine and it happened again. However, everything went fine after one more reboot. Usually the pointer disappears after the screen goes blank when I do not touch the laptop for a while. I'm not sure about what 'VT switch' is, by the way.
I suggest you try the patch =D . Who knows it helps. VT switch means switching VT with ctrl+alt+fx .
I can confirm that this bug still exists in Fedora 24 running xf86-video-nouveau 1.0.12 on an MCP61 motherboard. On return from suspend, the cursor is invisible. Ways to recover the cursor are switching to a different VT or opening the Xfce Whisker menu and moving the mouse onto it. Regular use is never affected; only suspend exhibits the bug. I believe this may actually have been caused by a commit early in 2008: https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=0da8c84cceb178b04ab535edb4e3f0ced204d00a This commit disables the hardware cursor on X mode changes. Please email me back if you need more info.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/1.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.