Bug 52754 - Mouse support lags by one mouse event
Mouse support lags by one mouse event
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.3
i386 Linux
high Severity high
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-28 14:28 EDT by kfrechet
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-09-01 07:54:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description kfrechet 2001-08-28 14:28:10 EDT
Description of Problem:
When running X apps, the system behaves as if it was buffering/holding the 
last mouse event, and only dispatching it when another mouse event is 
available. For example, if the user clicks on a GUI button, the mouse-down 
event does not occur until the user releases the mouse button. Likewise, 
the mouse-up event (and the result "mouse clicked" event) does not occur 
until the user generates another mouse event, such as moving the mouse or 
clicking it again. Sometimes this problem does not occur until the user 
logs out of the desktop and logs back in.

Version-Release number of selected component (if applicable):
XFree86 4.1.0

How Reproducible:
100%

Steps to Reproduce:
1. Boot Roswell-2 (7.1.94) to run level 5/X login
2. (At this point the mouse might already be exhibiting the problem. If 
not, proceed to step 3.)
3. Log in to either KDE or Gnome.
4. (At this point the mouse might already be exhibiting the problem. If 
not, proceed to step 5.)
5. Log out of the desktop, back to the X login screen.
6. Log in to either KDE or Gnome.
7. At this point the chance of failure is generally 100%.

Actual Results:
The last mouse event is not dispatched until another mouse event is 
waiting.

Expected Results:
Normal mouse behavior.

Additional Information:
So far we've only encountered this problem on the IBM ThinkPad T23. The 
IBM engineering team insists that there were no changes between the T22 
and T23 that should be expected to trigger this problem, nor are there any 
known issues with DOS or Windows drivers (in other words, no mouse driver 
updates were needed to support the T23 on non-Linux operating systems). 
Debugging has shown that mouse handling seems to be correct at the kernel 
level, and the finger of blame currently points to XFree86. It's possibly 
a timing sensitivity with the X mouse support. The selected mouse 
is "Generic 3-button PS/2 mouse".
Comment 1 Mike A. Harris 2001-09-01 07:54:24 EDT
Hmm.  This bug is definitely not a general mouse handling bug IMHO as
it has never been reported before, and doesn't seem to occur on any
test platforms or hardware I have available.  I do not have a TP to
test with.

This bug should be looked into by the XFree86 development team upstream
directly.  Please refile a bug report for this in their bug tracker
located at:  http://www.xfree86.org/cgi-bin/bugform.cgi

The driver maintainer will be much better able to look into this
and find a solution if there is indeed a bug as it sounds there is.

Thanks.

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