Description of problem: After kernel 2.6.17-1.2608 and up to kernel 2.6.17-1.2617: Suspend (to RAM) works fine, except on resume the mouse pointer is stuck in the top ~60 pixels of the screen. The mouse behaviour acts as if the pointer works correctly, but the actual cursor gets stuck within an area about 60 pixels tall and the width of the screen at top. This behaviour happens immediately after resume, when prompted to enter password to revive desktop. If the cursor is left at the top of the screen, this behaviour will continue once the Gnome desktop has loaded. If the mouse is moved to the middle or bottom of the screen (the visual cursor is still stuck at top) the problem corrects itself as the Gnome desktop loads. I started noticing this behaviour immediately after upgrading from kernel 2.6.17-1.2608, and the problem persists through 2.6.17-1.2617.2.1. This happened before the big Gnome upgrade, and at the time that it stopped working the only other updated packages should be unrelated (geronimo-specs for example). Leads me to believe it to be a kernel problem. How reproducible: FC6test2, updated to current devel 'intel' or 'i810' X.org video driver Synaptics touchpad. Steps to Reproduce: 1. Boot 2. Login 3. Suspend 4. Resume Actual results: Visual cursor is stuck in area at top of screen, actual mouse behaviour is normal, but hard to navigate without a visual cue of cursor location. Expected results: mouse/touchpad works fine (naturally) Additional info: I'm pretty sure the attached Xorg logs are as described below, I tried to initiate the behaviour as soon as i was logged in, and the log timestamps are 1 minute apart: Attached are Xorg.0.log.login (from GDM -> login -> desktop) also Xorg.0.log.resume (from desktop -> suspend -> resume) xorg.conf lspci & uname output.
Created attachment 135709 [details] uname -a and lspci output
Created attachment 135710 [details] xorg.conf
Created attachment 135711 [details] Xorg log from login (see additional info in bug desc)
Created attachment 135712 [details] Xorg log from resume (see additional info in bug desc)
After some experimentation, using X.org 'i810' driver instead of 'intel' I can circumvent this problem, but this problem didn't exist using 'intel' driver and kernel 2.6.17-1.2608 However, using 'i810' requires me to use 915resolution to achieve 1280x800 on my laptop LCD. Get a little better performance out of 'intel' driver as well. ( reference bug 205071 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205071 ) I suspect there's something falling apart between newer kernel builds and X.org 'intel' driver that doesn't affect 'i810'.
Problem partially resolved with updates performed today (attached yum.log). Using 'intel' driver glitchy cursor behaviour not noticed after resume unless I move mouse cursor too soon upon resume. If I wait about 5 seconds after resuming before entering any input there is no mouse glitchiness (for lack of a better word).
Created attachment 136456 [details] /var/log/yum.log 2006.09.16
Created attachment 137477 [details] uname -a and lspci and xorg.conf
After resume from suspend on a Dell 510m I get no mouse cursor at all. I haven't been using an updated kernel (due to other packaged kernel modules I want to use), so I am still using 2.6.17-1.2174_FC5. Otherwise everything is up to date fc6t3. I am also using the i810 driver for video and a synaptics mousepad. Find attached output from uname -a and lspci, plus my xorg.conf.
Has been working fine for me using 'i810' driver... however 'intel' driver is still buggy, as of latest FC6-pre updates 2006.10.09.... In response to Comment #9 : I've a dell laptop as well, Inspiron B-130. I've added an option to xorg.conf which seems to help stability-wise with suspend/resume: Section "Device" Identifier "i810_driver" Driver "i810" Option "VBERestore" "true" EndSection VBERestore ... 'man i810' will give you more info.
Just a follow-up, not sure if its enough to mark the bug as 'fixed'... but here's a workaround that has been working *so far* Using the 'intel' driver, after disabling GPM service, mouse behaviour is erratic for a few moments after resume from suspend. It does however, "come around" and is usable as it should be. So despite a bit of initial erratic behaviour it seems to be working fine. Attached xorg.conf and 'service --status-all' output. Running a fresh install of Fedora Core 6.
Created attachment 139641 [details] xorg.conf
Created attachment 139642 [details] service --status-all
I am pleased that Wade Nelson has a workaround that works for him in comment #11. But I would not recommend that the bug be declared closed. I for one am still suffering from this problem with the stock 2.6.18-1.2798.fc6 i686 kernel which I installed today. Like Wade, I was pleased to be able to try the Xorg "intel" version of the "i810" driver in order to be able to use the full resolution that my graphics card supports without having to resort to vbetool and 915resolution as I had to under FC5. Indeed, the "intel" driver did indeed allow me to use the full resolution, but I have exactly the problems Wade reported in his comment #1 regarding the pointer after suspend/resume. That is to say that (in my case) after a resume using the "intel" driver, the visual representation of the mouse pointer is trapped in a small margin against one of the screen boundaries, even though the mouse itself continues to function properly if you are able to use it via "dead reckoning". [When you click, or click and drag, you CAN see a one-pixel point or a drag-box appear in the right places, respectively, which helps with the dead reckoning] Sometimes my the visual pointer seems trapped at the top of the screen, sometimes at the bottom, sometimes both, once it was trapped in the top left and corner in a 25x25 pixel box. It seems to me that there is not much predictability in this, and that somewhere some memory is not being reiinitialised correctly after resume. I've tried Wade's suggestion of stopping GPM. It helped a bit (I was able to resume a couple of times) but it is unfortunately not able to help me much of the time.
I thought I'd add another issue I noticed with cursor under 'intel' driver shortly after Comment 11, since this is probably related. Sometimes when running an OpenGL app/game in a window (not fullscreen), the cursor is only visible within that window, and when the app is closed the cursor is not visible at all until X.org restart. This is 100% reproduceable in my case with The Mana World using OpenGL settings. This is NOT the case with the 'i810' driver. As of right now its looking like the 'intel' either has one major or multiple minor cursor bugs, so I'm still sticking with 'i810'.
Just commenting again, still experiencing same as Comment 11, with full updated FC6 as of this post. Attacheing Xorg.0.log from a session where the cursor got "stuck" using the 'intel' driver. At the end of the file there is an EE and WW or two that may or may not be related. In the meantime I'll wait until Fedora 7 is released to test out the 'intel' driver again. So while we're using i810 please keep 915resolution in the repos ;)
Created attachment 154027 [details] Xorg.0.log during behaviour from Comment 11 & 16 As per Comment 16
Reassigning to xorg-x11-drv-i810 since it's a problem there, rather than in the kernel.
I think we have all we need in comment 17. Airlied, do you agree?
Fedora Core 6 is no longer supported, could you please reproduce this with the updated version of the currently supported distribution (Fedora 7, 8, or Rawhide)? If this issue turns out to still be reproducible, please let us know in this bug report. If after a month's time we have not heard back from you, we will have to close this bug as CANTFIX. Setting status to NEEDINFO, and awaiting information from the reporter. [This is mass-filed message to all open Fedora Core 6 bugs related to Xorg or Gecko. If you see any other reason, why this bug shouldn't be closed, please, comment on it here.]
I haven't experienced any problems at all similar to this with Fedora 8. I can't comment on Fedora 7 at the moment.