Bug 343 - Spurious button press/release event with imps2 scroll mouse
Summary: Spurious button press/release event with imps2 scroll mouse
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/DDX/Xephyr (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Keith Packard
QA Contact:
Depends on:
Reported: 2004-03-17 17:17 UTC by Greg Brigley
Modified: 2011-10-15 17:20 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Output from "xev -display :0.0 -geometry 640x480+0+0" (3.77 KB, text/plain)
2004-03-17 17:23 UTC, Greg Brigley
no flags Details

Description Greg Brigley 2004-03-17 17:17:28 UTC
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
Comment 1 Greg Brigley 2004-03-17 17:23:41 UTC
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.
Comment 2 Greg Brigley 2004-03-17 17:29:42 UTC
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.
Comment 3 Keith Packard 2004-03-17 18:05:27 UTC
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.
Comment 4 Greg Brigley 2004-03-18 06:49:14 UTC
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?
Comment 5 S Egbert 2004-06-04 02:29:22 UTC
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
mailing list.

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.)
Comment 6 Adam Jackson 2009-04-14 07:17:54 UTC
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'.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.