Description of problem: Originally wrongly entered as Bug #204175. After switching to and back from a text-based console (with Ctrl-Alt-F1) mouse cursor disappeared (from gdm or fluxbox). It happens with the touchpad, and also with an external usb mouse. Computer is a Dell Latitude D505. System is rawhide up-to-date. kernel 2.6.17-1.2586.fc6. xorg-x11-drv-i810-1.6.5-5.fc6 xorg-x11-drv-mouse-1.1.1-1.1 xorg-x11-server-Xorg-1.1.1-31.fc6 # lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) It also happens when suspending on disk, but I guess this is because it switch to text-mode before suspend. Even if the cursor has disappeared, the mouse is still functionning normally, moving and clicking do the right things, although it is not very easy to use since the cursor isn't visible... Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 135194 [details] Xorg.log before switching to console
Created attachment 135195 [details] Xorg.log after coming back from the console
Created attachment 135196 [details] difference between the Xorg.log before going to console and after coming back
Similar problem here -- cursor doesn't disapper, but it gets locked in the left top corner of the display and cannot be moved. This is my graphic card (PCI ID 8086:2592): 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
Created attachment 139712 [details] xorg.conf
Created attachment 139713 [details] Difference between /var/log/Xorg.0.log before and after switching to console and back
Created attachment 139719 [details] Xorg.0.log without any switching to console
*** Bug 213176 has been marked as a duplicate of this bug. ***
May have DUPS bug 206832 and probably blocks RHELRalpha1 URGENT bug 213050
Similar symptoms also reported as bug 183096.
I cannot reproduce it when System/Configuration/Desktop Effects is off. Patrice, do you have it on? And if yes, could try to reproduce it with compiz switched off, please? Thanks.
I don't know exactly what compiz is, I use fluxbox and xfce and it also happens for gdm or wdm.
I have googled a bit about compiz, and certainly don't use it. I don't have the package installed, and anyway fluxbox wouldn't use it.
Yes, of course, if you have fluxbox, then you don't care about such silliness as compiz. Just thought worthy to ask, some other user (and me) have been able to reproduce this only with compiz switched on.
*** Bug 214481 has been marked as a duplicate of this bug. ***
*** Bug 206832 has been marked as a duplicate of this bug. ***
Any action on this bug? I can't use suspend/resume on my laptop because after coming out of suspend, the mouse is broken. I just tried and can reproduce it with just metacity. FC6 with all updates, Intel video. I can provide any other details you need. For reference, my original bug was 213176 which got marked as a dup to this bug (Sorry, I didn't see the request for more info after the bug was marked a dup and closed).
This appears to be fixed in FC7. I am running up to date fc7t2+rawhide on my laptop and the cursor doesn't seem to have any problems reappearing when switching to a VT and back. I just tried it several times.
Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer test releases. We're cleaning up the bug database and making sure important bug reports filed against these test releases don't get lost. It would be helpful if you could test this issue with a released version of Fedora or with the latest development / test release. Thanks for your help and for your patience. [This is a bulk message for all open FC5/FC6 test release bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
This bug is still present for me in xorg-x11-drv-i810-1.6.5-17.fc7
okay, thanks.
Patrice, does the intel driver work for you?
Yes, the intel driver doesn't have this bug.
*** Bug 238674 has been marked as a duplicate of this bug. ***
Just added my own bug as a duplicate of this one. Relevant information from my duplicate, that doesn't seem to be mentioned in this one: "You can work around this bug, by setting the Option SWCursor, however this disable direct rendering." This will probably explain why some users have only noticed it in compiz: They didn't have direct rendering on before setting up their X for compiz. Note that while the intel driver does not seem to have the problem, the intel driver does not work with my Dell Latitude D505 with a 1400x1050 LCD display.
Sounds like this one can be closed as 'wontfix' since the i810 driver is no longer maintained. Is there another bug open either here or at freedesktop.org on your Dell Latitude problem?
I still use the i810 driver to connect to an external screen, it doesn't seems to work with the intel driver (I haven't reported, I don't know if I am doing things rightly to switch to the external screen). But I can live with this bug since my use of i810 is very occasional. As a side note I tried rawhide X a bit but then reverted to F-8 X because rawhide X was very broken (and I don't think my testing would have made sense it was too obvious that it was broken to be useful to report), so maybe my informations are obsolete.
If you get a chance, it would be good to try the intel driver again, using the instructions at http://www.intellinuxgraphics.org/dualhead.html to setup your dual head configuration. If that doesn't work I'd like to hear about it.
In fact it seems to me that the 'Clone mode' doesn't work. When I hit Fn-F8 (CRT/LCD) nothing happens. I don't have an external screen right now, I only tested it with video projectors.
Yeah, Fn-F8 probably won't work with the new driver yet (and if it does you may be in danger of crashing). Until we get the hotkeys wired up with the new driver, you'll need to use the 'xrandr' command or xorg.conf options to setup clone mode.
I see this still on F8 with integrated nvidia chipsets, using either the nv or binary nvidia driver. Should I open a new bug or generalize this one?
(In reply to comment #31) > Yeah, Fn-F8 probably won't work with the new driver yet (and if it does you > may be in danger of crashing). Until we get the hotkeys wired up with the new > driver, you'll need to use the 'xrandr' command or xorg.conf options to setup > clone mode. Clone mode works with xrandr --output LVDS --auto --output VGA --auto --same-as LVDS
(In reply to comment #32) > I see this still on F8 with integrated nvidia chipsets, using either the nv or > binary nvidia driver. Should I open a new bug or generalize this one? Since it is not the same driver, I think it makes more sense to add a new bug. Closing.