Red Hat Bugzilla – Bug 205539
Mouse/Cursor faulty behaviour after resume from suspend
Last modified: 2007-12-12 12:17:26 EST
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.
FC6test2, updated to current devel
'intel' or 'i810' X.org video driver
Steps to Reproduce:
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.
mouse/touchpad works fine (naturally)
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
Attached are Xorg.0.log.login (from GDM -> login -> desktop)
also Xorg.0.log.resume (from desktop -> suspend -> resume)
lspci & uname output.
Created attachment 135709 [details]
uname -a and lspci output
Created attachment 135710 [details]
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
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
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
Created attachment 136456 [details]
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:
Option "VBERestore" "true"
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]
Created attachment 139642 [details]
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
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
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
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.