Bug 15758 - Invisible mouse pointer on NV4E (C51)
Summary: Invisible mouse pointer on NV4E (C51)
Status: REOPENED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
: 60951 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-04-29 11:36 UTC by Raúl Soriano
Modified: 2016-09-19 15:22 UTC (History)
8 users (show)

See Also:
i915 platform:
i915 features:


Attachments
fix some minor consistency issues (1.16 KB, patch)
2009-01-26 11:33 UTC, Stuart Bennett
no flags Details | Splinter Review
use the PCRTC regs for cursor setting (3.68 KB, patch)
2009-01-26 11:35 UTC, Stuart Bennett
no flags Details | Splinter Review
sleep for a second after hiding cursor (480 bytes, patch)
2014-02-22 22:29 UTC, Ilia Mirkin
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Raúl Soriano 2008-04-29 11:36:07 UTC
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.
Comment 1 Stuart Bennett 2008-04-29 12:18:18 UTC
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.
Comment 2 Raúl Soriano 2008-06-15 10:31:32 UTC
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.
Comment 3 Renato Caldas 2008-06-16 06:11:04 UTC
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.
Comment 4 Ronald 2008-12-31 11:57:37 UTC
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
Comment 5 Danny 2009-01-02 19:51:57 UTC
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.
Comment 6 Ronald 2009-01-22 04:25:43 UTC
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.....
Comment 7 Stuart Bennett 2009-01-22 15:57:51 UTC
(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?
Comment 8 Ronald 2009-01-23 13:09:25 UTC
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.
Comment 9 Stuart Bennett 2009-01-26 11:33:28 UTC
Created attachment 22251 [details] [review]
fix some minor consistency issues

Here's a minor patch that could be worth a try
Comment 10 Stuart Bennett 2009-01-26 11:35:11 UTC
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
Comment 11 Ronald 2009-02-07 12:30:22 UTC
(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.
Comment 12 Ronald 2009-02-07 12:32:43 UTC
FTR: The above data was *with* your patches [1] applied!

[1]: fix some minor consistency issues and fix some minor consistency issues
Comment 13 Stuart Bennett 2009-02-07 15:36:28 UTC
(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.
Comment 14 Ronald 2009-02-08 01:18:37 UTC
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.
Comment 15 Ronald 2009-02-08 04:23:18 UTC
Reconfirming with latest git that problem still exists:

nouveau-0387ac32bef6c714f54917d5d36071ae1224458c
Comment 16 Stuart Bennett 2009-02-08 06:04:57 UTC
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.
Comment 17 Stuart Bennett 2009-04-04 15:48:27 UTC
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
Comment 18 Ronald 2009-04-05 02:18:09 UTC
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
Comment 19 Ronald 2009-04-07 03:12:47 UTC
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
Comment 20 Steven Bularca 2010-02-23 21:12:29 UTC
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.
Comment 21 Ronald 2010-02-23 22:50:36 UTC
(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....
Comment 22 Xavier 2010-02-24 03:38:05 UTC
(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).
Comment 23 Jalil U. Karimov 2011-06-23 06:22:51 UTC
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.
Comment 24 Jalil U. Karimov 2011-06-23 07:26:44 UTC
Running the gtk version, didn't cause mouse missings.
Comment 25 Emil Velikov 2011-06-23 07:53:22 UTC
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
Comment 26 Ronald 2012-06-08 04:45:57 UTC
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
Comment 27 Ronald 2012-06-08 04:56:16 UTC
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.
Comment 28 v_2e 2012-06-19 09:05:16 UTC
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
Comment 29 Ronald 2012-11-19 08:02:40 UTC
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.
Comment 30 v_2e 2013-02-25 16:47:01 UTC
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
Comment 31 Ronald 2013-02-25 19:35:31 UTC
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.
Comment 32 Ilia Mirkin 2013-08-20 01:16:17 UTC
*** Bug 60951 has been marked as a duplicate of this bug. ***
Comment 33 ^m'e 2013-10-04 11:05:31 UTC
(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...
Comment 34 Ronald 2013-10-05 06:26:49 UTC
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??
Comment 35 Ilia Mirkin 2014-02-22 22:29:07 UTC
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.
Comment 36 Ronald 2014-02-23 07:59:12 UTC
This has not hapenned for me in ages. Verifying that will be very difficult.

It happens highly occassionally.
Comment 37 Ilia Mirkin 2014-02-24 00:53:48 UTC
(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.
Comment 38 Ronald 2014-02-24 06:56:25 UTC
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.
Comment 39 v_2e 2014-02-24 14:32:40 UTC
(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.
Comment 40 Ronald 2014-02-24 16:33:50 UTC
What hapenned before it occurred? VT switch?
Comment 41 v_2e 2014-02-25 17:34:05 UTC
(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.
Comment 42 Ronald 2014-02-25 17:50:55 UTC
I suggest you try the patch =D . Who knows it helps.

VT switch means switching VT with ctrl+alt+fx .
Comment 43 oldtechaa 2016-09-19 15:22:46 UTC
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.


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.