Red Hat Bugzilla – Bug 75728
ps2 mouse button problem with XTestFakeButtonEvent()
Last modified: 2007-04-18 12:47:28 EDT
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
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
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
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):
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.
I suspect this is an xfree86 problem, but I am using redhat linux, so I report
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.
ehm if you say this is an X bug, why do you file it against the kernel ?
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
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.
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 firstname.lastname@example.org, and also the email@example.com
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.