Bug 75728

Summary: ps2 mouse button problem with XTestFakeButtonEvent()
Product: [Retired] Red Hat Linux Reporter: Robert J. Brown <rj>
Component: XFree86Assignee: Mike A. Harris <mharris>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-10-11 19:08:48 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 Robert J. Brown 2002-10-11 16:18:26 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

Description of problem:
XTestFakeButtonEvent() is used in x0rfbserver (and similar vnc servers that 
relay a running X-server to a vncviewer) to insert the remote mouse's button 
events into the running X-server.  This works under RH6.2, but fails under 7.3 
and 8.0.  The problem is only demonstrable with a ps2 mouse; a serial mouse 
works fine.

What is happening is that mouse button down events, especially as in a drag 
operation on a window under twm, seem to get overriden by the resting mouse 
button up status of the console mouse.  This causes the remote mouse to loose 
the grab on the window, and requires that the mouse button on the console mouse 
be pressed to terminate the drag operation.  It renders the remote vnc client 
mostly useless.

I suspect that the problem was introduced in xfree86 4.1.x when the ps2 mouse 
code was modified in an effort to make hot swapping of ps2 mice more robust.  
This is certainly desirable, especially when one is using a video/kb/mouse 
switch.

The 2 work arounds for the problem are to downgrade to rh6.2 which uses xfree86 
3.x.x and does not demonstrate the problem, or the hardware workaround is to 
use a serial port mouse, which can be accomplished by purchasing a $2.98 
adapter for the ps2 mouse to plug into a DB-9-pin serial port connector, and 
adjusting your XF86Config file and gpmouse config accordingly.  Obviously this 
is only an option if you have a free serial port.

This problem will likely also cause grief if one is using a mouse and a 
trackball, or any 2 pointing-device configuration, where one device is on a ps2 
port.  This has not yet been verified.

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


How reproducible:
Always

Steps to Reproduce:
1. start a console X-server as :0 
2. start x0rfbserver to relay :0 using the rfb (vnc) protocol
3. start a vncviewer to connect to your-machine:0
4. on the vncviewer machine, grab a window and drag it into a new position.  
The drag will hang.
5. reset the drag by clicking the console mouse.
6. go fix the problem!  :-)
	

Actual Results:  The remote mouse lost control of the drag operation.

Expected Results:  The drag of the window would perform normally.

Additional info:

I suspect this is an xfree86 problem, but I am using redhat linux, so I report 
it here.

The problem has been verified to only occur with ps2 mice; serial mice do not 
exhibit the problem.

The problem has been demonstrated on rh7.3 and rh8.0.

The problem is not demonstrable on rh6.2; it works correctly.

Comment 1 Arjan van de Ven 2002-10-11 17:18:58 UTC
ehm if you say this is an X bug, why do you file it against the kernel ?

Comment 2 Robert J. Brown 2002-10-11 19:08:34 UTC
I filed against the kernel because I could not find xfree86 as a choice to file 
it against, and bugzilla forced me to choose something.  Also, it seemed to 
some of us that since it looked ps2 specific, that it might be in the kernel 
ps2 driver.  Sorry.  :-(

I just tried rh8.0 with an old logitech serial mouse, and the problem 
manifested itself, to my great suprise, so I guess it is not ps2 specific after 
all.  :-\

It turns out that what we will really be needing is for it to work with a USB 
mouse ultimately.  Now that I see the problem with a serial as well as ps2 
mouse, I suspect that the USB mouse will show it too.  I cannot run a USB mouse 
test until MOnday.  I will keep you informed.

Comment 3 Mike A. Harris 2002-10-14 09:50:20 UTC
Red Hat Linux 7.0, 7.1, 7.2, and 7.3 come with both XFree86 4.x,
and with all of the XFree86 3.3.6 servers, so if you decide to use
an older release, there is no need to go back as far as 6.2, since
3.3.6 is supported in all 7.x releases as well - unless of course
you have a particular fancy to the 6.2 release.

Since this problem is likely to affect an extremely small number
of users, and since it hasn't at all been reported in all the
time XFree86 4.x has been released, it is not an issue which I
can assign any priority to, and is thus unlikely to ever be looked
into by us.

This is ultimately an issue that should be reported directly to
XFree86.org, due to the reasons cited above.  You can report this
problem, by emailing xfree86, and also the xpert
mailing list.  The best way to get resolve from upstream, is to
try and stimulate interest from them in solving the problem.

I'm closing this as WONTFIX for now, however, if you encounter a bug
fix patch in the wild, or from XFree86.org, feel free to attach the
patch to this report and reopen.

Thanks.