by I spent a little while today looking at what the mouse sends when it is
working normally, and when it is screwed up after switching with a KVM
switch. Here's what I saw.
1. When everything is happy, the mouse sends 4 bytes whenever anything
happens. Here's what the bytes look like:
+-------+-------+-------+-------+-------+-------+-------+-------+
| 0 | 0 | Ymore | Xmore | 1 | B3 | B2 | B1 |
+-------+-------+-------+-------+-------+-------+-------+-------+
| X position change |
+-------+-------+-------+-------+-------+-------+-------+-------+
| Y position change |
+-------+-------+-------+-------+-------+-------+-------+-------+
| wheel position change |
+-------+-------+-------+-------+-------+-------+-------+-------+
The position changes are signed numbers, in ordinary two's compliment form.
For X, positive is right. For Y, positive is away from you on the desk.
For the mouse, positive is scrolling down.
The B1, B2, and B3 bits are set when button's 1, 2, and 3, respectively are
down.
The Xmore and Ymore bits are one of the following:
A. A copy of the high order bit of the corresponding position change
byte.
B. The X and Y position changes are really 9 bit two's compliment signed
numbers, and Xmore and Ymore are the high order bit.
I was not able to move the mouse fast enough to make a big enough change to
tell those two possiblilities apart.
2. When the mouse gets borked so that the movement is not erratic, but the
wheel will only scroll down, it is still sending 4 bytes, but wheel position
changes are being truncated to 4 bits, so the last byte looks like this:
+-------+-------+-------+-------+-------+-------+-------+-------+
| 0 | 0 | 0 | 0 | wheel position change |
+-------+-------+-------+-------+-------+-------+-------+-------+
This means that movement up one unit, instead of 0xFF, the computer gets
0x0F. X seems to ignore that, so I'm *guessing* that they sanity check the
wheel input, and 0x0F is seen as too high, and discarded.
3. When the mouse gets into the "movement is totally erratic, and buttons
are being randomly pressed" mode, what has happened is that it has switched
to a non-wheel protocol. That protocol seems to be basically the same as
the wheel protocol, except there is no wheel byte, so every mouse change
results in 3 bytes being sent, not 4.
4. It should not be too hard to detect case #3 in software. The first byte
of the packet is of the form 00xx1xxx. The X and Y movement bytes can only
match that pattern on a positive movement of [8,15], [24,31], [40,47], etc.
5. It should also not be too hard to detect case #2, because even when
trying, it was very hard to spin the wheel fast enough to get 0x0F.
6. I wonder how mice with more than three buttons work? There are two bits
that were always 0 in the first byte...I wonder if those are for buttons 4
and 5? I may have a mouse with more buttons lying around at work...if I can
find it, I'll have to check that out.
--
Evidence Eliminator is worthless: "www.evidence-eliminator-sucks.com"
--Tim Smith