Bug 52754

Summary: Mouse support lags by one mouse event
Product: [Retired] Red Hat Linux Reporter: kfrechet
Component: XFree86Assignee: Mike A. Harris <mharris>
Status: CLOSED WONTFIX QA Contact: David Lawrence <dkl>
Severity: high Docs Contact:
Priority: high    
Version: 7.3   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-09-01 11:54:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description kfrechet 2001-08-28 18:28:10 UTC 
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 11:54:24 UTC 
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.