After starting kdrive (vesa or fbdev) with a ps/2 scroll mouse, I get a button
press and button release event for button 3 the first time I move the mouse.
Based on the mice I have on hand, it doesn't happen with usb mice, or any non
scroll mouse. It does happen with a Logitech ps/2 scroll mouse, a Microsoft
optical wheel mouse, and a no-name ps/2 scroll mouse. Also, the same
Microsoft optical wheel mouse does not show this behaviour when used via USB
instead of ps/2.
I had found the same bug in kdrive servers built from xfree86 4.3 and 4.4
sources and logged it in their Bugzilla before realizing that kdrive had moved
Created attachment 151 [details]
Output from "xev -display :0.0 -geometry 640x480+0+0"
Note the ButtonPress and ButtonRelease events, when no button was actually
pressed or released.
Just wanted to clarify that I did confirm presence of this bug in the
freedesktop.org xserver sources, which I checked out and built today.
The mouse protocol autodetection code is tricky to get right; there's a
compromise between accepting a protocol too early only to discover you've
guessed wrong and waiting too long before accepting a protocol and annoying the
The whole scheme needs to be looked a bit more closely with an eye to having it
make better choices about protocols by running several in parallel instead of
doing them one at a time.
In my case, the server does choose the right protocol. It outputs 'switching to
mouse protocol "imps/2"'. I had assumed that the extra button press was a
problem in the implementation of the protocol itself. Are you saying it's
actually a side-effect of taking too long to pick a protocol?
Recreated this using latest X.org CVS.
Many KVMs would benefit from a cleaner mouse protocol recovery mechanism.
Found this might be related to the Xfree86 bug # 34 "Intellimouse can no longer
be disconnected and reconnectec with kvm switch" over at one of the NetBSD
The pmsi driver cannot cope with a KVM switch which may occasionally forget
about scroll wheels. Furthermore, it is an offense against elegant design for
the pmsi driver to be nearly identical to the standard pms driver, except that
it does some weird magic, and it doesn't know about 5-button mice.
Proposed, that psm.c should be revised to process multiple types of mice, and
handle the protocol transparently.
Secondly, once you've done this, the annoying tendency of a certain KVM switch,
made by a vendor who shall rename nameless, but whose name would rhyme with
"pelkin" if that were a word, to reset the mouse silently into plain-old psm
mode creates problems.
The solution is to check each non-initial byte of a packet for delay. The normal
delay between PS/2 packet bytes seems to be around 1700us, plus or minus thirty.
An occasional byte may take up to 5000us to arrive. A delay of, say, 30000us
reliably indicates that the new byte is part of a different packet. Thus, if
the driver isn't expecting a new packet, and sees a long delay, it now resets
the mouse, throwing the packet out in the process.
Buy a KVM switch.
(This also implies throwing out psm_intelli.c, which we don't need.)
The old kdrive tree is dead. As far as we can tell, this bug no longer applies to the current Xorg server tree. If it does, please reopen this bug and change the product to 'xorg' and the component to 'server/general'.