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.
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 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.
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.