Bug 529717 - [RHEL5] HP DC5850: mice get stuck on left edge (X11 acceleration overflow?)
Summary: [RHEL5] HP DC5850: mice get stuck on left edge (X11 acceleration overflow?)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xorg-x11-server
Version: 5.4
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Peter Hutterer
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 590060 695252
TreeView+ depends on / blocked
 
Reported: 2009-10-19 16:28 UTC by Alan Matsuoka
Modified: 2018-11-14 20:27 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-21 03:10:14 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
xorg-x11-server.1.1.1-mouseaccel-overflow2.patch (1.24 KB, patch)
2009-10-19 16:29 UTC, Alan Matsuoka
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 559964 0 high CLOSED Pointer confined to one monitor with r500 in zaphod mode 2021-02-22 00:41:40 UTC
Red Hat Knowledge Base (Legacy) 21198 0 None None None Never
Red Hat Product Errata RHSA-2012:0303 0 normal SHIPPED_LIVE Low: xorg-x11-server security and bug fix update 2012-02-21 07:24:37 UTC

Internal Links: 559964

Description Alan Matsuoka 2009-10-19 16:28:51 UTC
1. Time and date of problem:

N/A

2. System architecture(s):

i386

3. Provide a clear and concise problem description as it is understood at the time of escalation. Please be as specific as possible in your description. Do not use the generic term "hang", as that can mean many things.

See IT#237319 for details:

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.

A patch exist for RHEL4 (BZ#492129).

According to IT#237319 Event posted 2009-10-19 15:09 CEST by alanm:

"""
This patch isn't in RHEL5 either. If you want to get this into RHEL5 please open a new IT and I'll create a BZ for it.
"""

4. Specific action requested of SEG:

Please track this bug for RHEL5 too.

Comment 1 Alan Matsuoka 2009-10-19 16:29:26 UTC
Created attachment 365247 [details]
xorg-x11-server.1.1.1-mouseaccel-overflow2.patch

Comment 4 Issue Tracker 2009-10-30 16:45:01 UTC
Event posted on 2009-10-30 17:45 CET by rdassen

In the RHEL4 instance of this issue, bug #492129, there is a reference to
an upstream defect (http://bugs.freedesktop.org/show_bug.cgi?id=3113)
which has been fixed in http://www.x.org/wiki/Server14Branch through
http://cgit.freedesktop.org/xorg/xserver/commit/?id=12d27cf33c6d963eae77795c0d247175907162a5
plus
http://cgit.freedesktop.org/xorg/xserver/commit/?id=a66c0f1dca2958835ff65a5b50579e3304ed316a

Can you please check whether those patches are relevant to us and whether
they may constitute a proper fix?



This event sent from IssueTracker by rdassen 
 issue 355615

Comment 5 Peter Hutterer 2009-11-02 02:18:31 UTC
The issue fixed in 12d27cf addresses a possible integer overflow, leading to the first parameter to pow becoming negative for a sufficiently large dx/dy. In my testing locally, two points were noted:
1. if the first parameter is negative, the return value is NaN and the result is invalid (provided that the second parameter is not an integer).
2. To trigger this overflow, dx/dy needs to be extremely high (greater or equal to 32768). I have never seen deltas go beyond 100, it is unclear if this patch addresses a real-world issue or is merely a cosmetic/safety fix.

A comment in Bug 3113 indicates that even with these patches applied, the issue is still present.

To get mouse cursor stuck on the left edge dx must be consistently negative. This can only occur if it is indeed negative when passed in from the mouse driver. In that case however, "xset m 5 100" (the workaround from Bug 492129) would not help.
It's likely that the reason why the workaround works is because with such a high threshold, the accel code simply isn't triggered anymore.

Hence the need for a reproducer, without looking at the values and ensuring what goes on when this bug is triggered, it's hard to even tell if the issue is in the mouse driver or in the server.

Comment 10 Peter Hutterer 2009-11-12 00:03:54 UTC
Jan, can you give me an update on this please? Have you managed to get the needed output from the debug packages yet?

Comment 29 Dave Airlie 2011-03-09 04:28:18 UTC
MODIFIED

xorg-x11-server-1.1.1-48.79.el5 is built in brew, please test.

Comment 35 Dave Airlie 2011-04-07 23:00:48 UTC
MODIFIED

building xorg-x11-server-1.1.1-48.81.el5 in brew.

Comment 38 Vasiliy Sharapov 2011-04-14 00:51:14 UTC
Confirmed here in QA, I'll verify the fix and check for regressions tomorrow.

Comment 44 errata-xmlrpc 2012-02-21 03:10:14 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2012-0303.html


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