Bug 492129 - HP DC5850: mice get stuck on left edge (X11 acceleration overflow?)
HP DC5850: mice get stuck on left edge (X11 acceleration overflow?)
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: xorg-x11-drv-mouse (Show other bugs)
All Linux
high Severity high
: rc
: ---
Assigned To: Peter Hutterer
: Triaged
Depends On:
Blocks: 485811
  Show dependency treegraph
Reported: 2009-03-25 10:23 EDT by Alan Matsuoka
Modified: 2012-04-20 12:57 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-04-20 12:57:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
sosreport-jivenasisw8rhel.237319-138378-334cee.tar.bz2 (506.35 KB, application/x-bzip2)
2009-03-25 10:23 EDT, Alan Matsuoka
no flags Details
xorg-x11-server.1.1.1-mouseaccel-overflow2.patch (1.24 KB, patch)
2009-03-25 10:24 EDT, Alan Matsuoka
no flags Details | Diff
xf86Xinput.c.patch-accel (5.29 KB, text/plain)
2009-03-25 10:25 EDT, Alan Matsuoka
no flags Details

  None (edit)
Description Alan Matsuoka 2009-03-25 10:23:41 EDT
Created attachment 336650 [details]

Description of problem:

Several users complain that their desktop HP DC5850 with RHEL4/SLC4 in 32bit, smp kernel regularly leaves the X11 mouse cursor stuck near the left edge of the X11 screen - it will move briefly right, then jump back to the edge. So far this has only been reported for horizontal movements.

(see 216697 for details on the hardware)

We have found that "xset m 5 100" inside the X11 session is a workaround, both preventive and applied after the mouse becomes stuck. So this appears as if the X coordinate delta overflows with acceleration, once some other (unknown) condition has been met.

How reproducible:

Difficult: mouse is fine after boot, issue takes several minutes to appear (or hours). Possibly linked to ongoing network activity..
Our "reproducer" involves twiddling the mouse horizontally while running "wget" in a loop. [I don't think this will be reproducible at Red Hat.]. Once the error condition has been met, it will stay (no further network traffic required).

Additional info:

The hardware had issues with the system clock running at double speed (workaround), this could be another timer issue (i.e. sample two mouse events too "closely" together in time, calculate delta that overflows, X11 goes bad whenever acceleration is used afterwards?), or could be linked to interrupt handling (c.f. "network" relationship, perhaps missing some interrupts leads to the mouse reporting enormous values?).

We have run a simple gettimeofday() loop to see whether time would run backwards - apparently not the case.

* workaround: We would like help with making the above "xset" setting permanent for all users on a machine (didn't find anything on how to configure this in xorg.conf), relying on individual users' .xinitrc/GNOME/KDE does not scale and is difficult to apply for users moving between machines.

* We would also like some help in getting more data once the error condition has been triggered - what could/should we watch, are there X11 debugging tools that would allow to pinpoint where the error condition comes from (X11/kernel psmouse driver/IRQ handling)?

Issue has been seen with PS2 and USB mice (different brands) - most likely not related to the exact model used.

SEG Notes:
As I understand it, this has been a long standing known problem in the X mouse code and it's been open for years. The cause for this has been because of floating point overflows.

The patch I've found may or may not fix the problem.

There's been some work done on this problem upstream over the last year because of an increasing number of complaints and it's required a revamping of the code.

patch for this 

The report came in from the xorg mailing list. xf86Xinput.c.patch-accel has the reference:

"I received an off-list email pointing me to NetBSD PR 30418  (fixed by
NetBSD's pkgsrc/xorg-libs/patches/patch-bl). This NetBSD PR led me to
xorg bug #3113 which says "the mouse pointer will reset itself to the left
side of the screen. Unless I move the pointer very slowly, it will keep
going back to the left edge of the screen." "
Comment 1 Alan Matsuoka 2009-03-25 10:24:52 EDT
Created attachment 336651 [details]
Comment 2 Alan Matsuoka 2009-03-25 10:25:31 EDT
Created attachment 336652 [details]
Comment 3 RHEL Product and Program Management 2009-03-25 10:26:51 EDT
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 10 RHEL Product and Program Management 2010-10-22 14:57:46 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

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