Bug 205539 - Mouse/Cursor faulty behaviour after resume from suspend
Mouse/Cursor faulty behaviour after resume from suspend
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-i810 (Show other bugs)
6
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Airlie
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-06 21:52 EDT by Wade Nelson
Modified: 2007-12-12 12:17 EST (History)
4 users (show)

See Also:
Fixed In Version: f8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-12 12:17:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
uname -a and lspci output (1.66 KB, text/plain)
2006-09-06 21:52 EDT, Wade Nelson
no flags Details
xorg.conf (1.29 KB, text/plain)
2006-09-06 21:53 EDT, Wade Nelson
no flags Details
Xorg log from login (see additional info in bug desc) (44.89 KB, text/plain)
2006-09-06 21:55 EDT, Wade Nelson
no flags Details
Xorg log from resume (see additional info in bug desc) (44.06 KB, text/plain)
2006-09-06 21:56 EDT, Wade Nelson
no flags Details
/var/log/yum.log 2006.09.16 (7.15 KB, text/plain)
2006-09-16 18:27 EDT, Wade Nelson
no flags Details
uname -a and lspci and xorg.conf (3.77 KB, text/plain)
2006-09-30 12:16 EDT, Keith Allcock
no flags Details
xorg.conf (1.31 KB, text/plain)
2006-10-28 12:44 EDT, Wade Nelson
no flags Details
service --status-all (4.35 KB, text/plain)
2006-10-28 12:45 EDT, Wade Nelson
no flags Details
Xorg.0.log during behaviour from Comment 11 & 16 (54.94 KB, text/plain)
2007-05-03 09:11 EDT, Wade Nelson
no flags Details

  None (edit)
Description Wade Nelson 2006-09-06 21:52:19 EDT
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.
Comment 1 Wade Nelson 2006-09-06 21:52:19 EDT
Created attachment 135709 [details]
uname -a and lspci output
Comment 2 Wade Nelson 2006-09-06 21:53:50 EDT
Created attachment 135710 [details]
xorg.conf
Comment 3 Wade Nelson 2006-09-06 21:55:29 EDT
Created attachment 135711 [details]
Xorg log from login (see additional info in bug desc)
Comment 4 Wade Nelson 2006-09-06 21:56:10 EDT
Created attachment 135712 [details]
Xorg log from resume (see additional info in bug desc)
Comment 5 Wade Nelson 2006-09-07 21:17:21 EDT
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'.
Comment 6 Wade Nelson 2006-09-16 18:26:29 EDT
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).
Comment 7 Wade Nelson 2006-09-16 18:27:25 EDT
Created attachment 136456 [details]
/var/log/yum.log 2006.09.16
Comment 8 Keith Allcock 2006-09-30 12:16:19 EDT
Created attachment 137477 [details]
uname -a and lspci and xorg.conf
Comment 9 Keith Allcock 2006-09-30 12:16:50 EDT
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.
Comment 10 Wade Nelson 2006-10-09 15:48:19 EDT
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.
Comment 11 Wade Nelson 2006-10-28 12:43:45 EDT
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.
Comment 12 Wade Nelson 2006-10-28 12:44:49 EDT
Created attachment 139641 [details]
xorg.conf
Comment 13 Wade Nelson 2006-10-28 12:45:32 EDT
Created attachment 139642 [details]
service --status-all
Comment 14 Chris Lester 2006-10-29 22:15:46 EST
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.
Comment 15 Wade Nelson 2006-10-30 11:24:44 EST
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'.
Comment 16 Wade Nelson 2007-05-03 09:08:59 EDT
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 ;)
Comment 17 Wade Nelson 2007-05-03 09:11:36 EDT
Created attachment 154027 [details]
Xorg.0.log during behaviour from Comment 11 & 16

As per Comment 16
Comment 18 Nigel Cunningham 2007-06-18 20:33:57 EDT
Reassigning to xorg-x11-drv-i810 since it's a problem there, rather than in 
the kernel.
Comment 19 Matěj Cepl 2007-10-02 13:59:40 EDT
I think we have all we need in comment 17. Airlied, do you agree?
Comment 20 Matěj Cepl 2007-12-10 04:24:42 EST
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.]
Comment 21 Wade Nelson 2007-12-12 11:03:02 EST
I haven't experienced any problems at all similar to this with Fedora 8.  I 
can't comment on Fedora 7 at the moment.

Note You need to log in before you can comment on or make changes to this bug.