Created attachment 14833 [details] Xorg log file With Randr1.2 enabled, I get two mouse cursors after a few mode changes. One that moves (sw emulated cursor) and one that doesn't (presumably the hw cursor sitting there). 01:00.0 0300: 10de:002d (rev 15) 01:00.0 VGA compatible controller: nVidia Corporation NV5M64 [RIVA TNT2 Model 64/Model 64 Pro] (rev 15)
Same on this card: 00:08.0 0300: 10de:002c (rev 15) 00:08.0 VGA compatible controller: nVidia Corporation NV6 [Vanta/Vanta LT] (rev 15) The 2nd cursor seems to appear after the first mode change, i.e. after xrandr -s 1 for example. The hw cursor is the default X cursor (X shaped) and the sw cursor is my normal gnome cursor and works fine.
Created attachment 14834 [details] Log file on the 2nd card
I also get this on an nv10. On that card, the hardware cursor is wrong, but that's for another bug. 01:00.0 0300: 10de:0101 (rev 10) 01:00.0 VGA compatible controller: nVidia Corporation NV10DDR [GeForce 256 DDR] (rev 10)
Created attachment 14838 [details] Log file with the nv10
Do you also get this when forcing a SWCursor on a NV11+ card?
(In reply to comment #5) > Do you also get this when forcing a SWCursor on a NV11+ card? > No I don't.
Created attachment 14896 [details] [review] 1st option First of two possible fixes. This one definitely does the right thing, but is probably overkill.
Created attachment 14897 [details] [review] 2nd option A less heavyweight solution, but I don't know for sure that GetSpriteCursor is always going to do the right thing. This stuff really wants fixing in the xserver.
Original nouveau bug repurposed for xserver issue. After an xrandr mode change, drivers tend to call xf86_reload_cursors in the commit function. This in turn will show a hw cursor, if configured. This is not the correct behaviour for hardware that cannot do alpha cursors natively, if the cursor is an alpha cursor at the time; two cursors (one hardware (2 colour), one software (alpha)) show up, when the hardware cursor should be hidden. In the nouveau case, the 1st option in comment 7 has been applied to the driver as a work-around which takes a trip through xf86CursorSetCursor which sorts things out.
Created attachment 15344 [details] [review] Proposed fix. This should fix it.
Doesn't work (when applied to xserver 1.3.0, anyway). IIRC this approach won't work, as the cursor_shown variable will still get set when xf86CursorSetCursor calls xf86SetCursor on the hw cursor path.
Created attachment 15617 [details] [review] A better fix. It may not be perfect yet, so comment is appreciated.
Created attachment 18201 [details] [review] Tested and working patch This seems to work for all the cases I could think to test
Created attachment 18202 [details] [review] Oops Okay, it *was* tested and working, before I moved some comments and whitespace around, and deleted a semicolon.
Using the git xserver not older than a week, I seem to get bitten by this bug. I like to play Diablo II using Wine, but in the game I see the game mouse cursor which is alive, and another cursor stuck where-ever the cursor was when the game switched display modes. The stuck cursor is whatever the cursor was when starting the game, and on desktop I'm using the standard hw cursors.
Patch applied in 0b8f8b24f718820a72ebdc52423c2e6a44e848c5
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.