PS/2 mouse sign and overflow

[Sik]

New thread because I'm fed up with complaints x_x (and it probably derailed enough to be its own discussion)

Hi,

Um, the bit you're talking about is the sign bit... that's essentially the 9th bit of the value (mouse motion is 9-bit, not 8-bit). The range is actually -255 to +255. (EDIT: oh and in case somebody wonders why not -256... mouses that return -0 are a thing sadly and you should be aware of them)

I did a little testing and I did get it a little wrong. Thanks for the correction. Take the sign bit (Xs or Ys) and or it to the 9th bit, bit 8, and sign extend to the width of the integer used.

I'm wondering if you'd mind doing a little more testing for me...

My theory is that it may make more sense to use the overflow bit as the 9th bit, and the sign bit as the 10th, 11th, ... bits. This would give multiple possibilities depending on how the mouse handles overflow conditions (e.g. if the sign flag still works for overflow, if the other 8 movement bits are still valid, if the mouse clamps to the representable range, etc). The ideal case would be that you end up with a range from -512 to +511 with no problems at all (e.g. where "faster than +511" is just reported as +511).

More specifically, I think different mice might handle overflow in different ways, and that by treating it as "signed 11-bit integer" it'd be easier to handle each possibility (if you know the mouse's behaviour) and easier to "auto-guess" the mouse's behaviour when you don't know the mouse's behaviour (e.g. using some sort of "probability based on acceleration" logic).

Note that you might need to move the mouse quite fast to get overflow to occur. This depends on the resolution and sample rate. For example:

• "resolution = 1 count/mm, 10 samples per second" (slowest case): you'd need to move the mouse at over 4.6 Km/h to achieve overflow (and over 9.2 Km/h to test values outside the -512 to +511 range)
• "resolution = 1 count/mm, 200 samples per second": you'd need to move the mouse at over 25.6 Km/h to achieve overflow
• "resolution = 8 count/mm, 200 samples per second" (fastest case): you'd need to move the mouse at over 737 Km/h to achieve overflow

For this reason I'd want to configure the mouse for "resolution = 1 count/mm, 10 samples per second" for testing the true behaviour of overflow.

The other thing I'm wondering is if the overflow flag is sticky. For example, if you move the mouse right for 1234 counts then left for 1233 counts in between samples, does the mouse report "overflowed at some point during this period" or does it report "moved right 1 count".

Sadly; I haven't been able to find any information that adequately describes the behaviour on overflow.


Cheers,

Brendan

Overflow bit is used to indicate when the value doesn't fit within the range, but in practice it usually means there's an error (good moment to know you should probably reinit)... I suppose that if you polled too slow (USB mouses need polling, not interrupts) you could cause the range to overflow, but I wonder if they'd just return multiple packets or simply clamp the result. I'm not even sure if delta values would be meaningful (as opposed to random garbage) if overflow is set.

This probably varies from mouse to mouse, I guess it'd be nice to see how different modern mouses behave. The safest in practice is probably to poll often enough that overflow is not an issue though.

[BenLunt]

Hi,
I'm wondering if you'd mind doing a little more testing for me...

My theory is that it may make more sense to use the overflow bit as the 9th bit, and the sign bit as the 10th, 11th, ... bits. This would give multiple possibilities depending on how the mouse handles overflow conditions (e.g. if the sign flag still works for overflow, if the other 8 movement bits are still valid, if the mouse clamps to the representable range, etc). The ideal case would be that you end up with a range from -512 to +511 with no problems at all (e.g. where "faster than +511" is just reported as +511).

More specifically, I think different mice might handle overflow in different ways, and that by treating it as "signed 11-bit integer" it'd be easier to handle each possibility (if you know the mouse's behaviour) and easier to "auto-guess" the mouse's behaviour when you don't know the mouse's behaviour (e.g. using some sort of "probability based on acceleration" logic).

Note that you might need to move the mouse quite fast to get overflow to occur. This depends on the resolution and sample rate. For example:

• "resolution = 1 count/mm, 10 samples per second" (slowest case): you'd need to move the mouse at over 4.6 Km/h to achieve overflow (and over 9.2 Km/h to test values outside the -512 to +511 range)
• "resolution = 1 count/mm, 200 samples per second": you'd need to move the mouse at over 25.6 Km/h to achieve overflow
• "resolution = 8 count/mm, 200 samples per second" (fastest case): you'd need to move the mouse at over 737 Km/h to achieve overflow

For this reason I'd want to configure the mouse for "resolution = 1 count/mm, 10 samples per second" for testing the true behaviour of overflow.

The other thing I'm wondering is if the overflow flag is sticky. For example, if you move the mouse right for 1234 counts then left for 1233 counts in between samples, does the mouse report "overflowed at some point during this period" or does it report "moved right 1 count".

Sadly; I haven't been able to find any information that adequately describes the behaviour on overflow.

Brendan

I ran a few more tests per your request and I cannot get the overflow bit(s) to ever become high, even using the 1 count/mm, 10hz rate. I even cleared off the desk and had about 24" to move the mouse, as quickly as I could, from one side to the other and still could not get the overflow bits to become high.

I would probably takes Sik's advice and if the overflow bit(s) become high, reset the mouse.

Ben

[Sik]

You know, now I'm left wondering if mouses with very high DPI values would report large enough ranges to trigger overflow. Also I wonder if there's any mouse working around it by reporting multiple motions.

What's the largest delta value you can get during testing?

[BenLunt]

You know, now I'm left wondering if mouses with very high DPI values would report large enough ranges to trigger overflow. Also I wonder if there's any mouse working around it by reporting multiple motions.

What's the largest delta value you can get during testing?

First the optical devices.
- A generic PS/2 3 button mouse w/wheel, min -127, max +127
- A similar optical mouse w/wheel, min -128, max +127
- Another similar optical mouse w/wheel, min -44, max +57 (it only inched its way up to these values when I moved it really fast)

Now the mechanical (ball) mice with some sort of Quadrature Signal[1].
- A generic Microsoft 2 button mouse, min > -127, max < +127 (could never get it above 7 bits)
- A generic Dell 2 button mouse, min > -127, max < +127 (could never get it above 7 bits)

These too would not go below -127 to the -128 count either. I bet the firmware of the mouse had a limit set of 0 to 127 no matter the direction, then when it was time to announce, it negated the left or down direction, hence the limit of -127 and not -128.

I decided to set the scaling to 1:2 instead. The limits remain. Nothing raised the Overflow bit and we still get -127 to +127.

Ben

[1]Hackaday.com

[Brendan]

Hi,

Note that you might need to move the mouse quite fast to get overflow to occur.

I ran a few more tests per your request and I cannot get the overflow bit(s) to ever become high, even using the 1 count/mm, 10hz rate. I even cleared off the desk and had about 24" to move the mouse, as quickly as I could, from one side to the other and still could not get the overflow bits to become high.

Sorry. Sometimes I'm not very smart(!).

The easiest way to test would be to use "Remote Mode" (polling) instead of "Stream Mode". For example, if you only asked the mouse for a packet when the user presses a key, then the user could take as long as they want to move the mouse.

I would probably takes Sik's advice and if the overflow bit(s) become high, reset the mouse.

I'd suspect that it depends on the mouse. E.g. an insanely expensive "gamer mouse" might handle overflow better than a normal mouse (partly because it'd be designed for rapid mouse movements for first-person shooters, etc). Some mouses might clamps values to the -128 to +127 range and never set overflow, and some might follow the specs more closely.


Cheers,

Brendan

[Sik]

Yeah, I'm wondering about gaming mouses which can have pretty high DPI (or at least report that). The firmware on those mouses is normally more complex though (since they usually allow macros and such), and at that resolution you likely don't want to be restricted by the range from the protocol (not sure if it's large enough) so I wouldn't be surprised if they return multiple motions instead. Would need to test a few of those (or at least one or two) to see what they do. Sucks that it requires buying some =P

The range those tested mouses do is kind of suspicious though. I mean, it's possible it's just the microcontrollers trying to use a signed 8-bit integer, but I wonder if there's anything important out there that misbehaves outside this range (if there's anything that ignores the sign bits, it'd misinterprete the motion as soon as it's below -128 or over +127). Though so far it seems nothing is sending invalid packets, so there's that.

[Brendan]

Hi,

Yeah, I'm wondering about gaming mouses which can have pretty high DPI (or at least report that). The firmware on those mouses is normally more complex though (since they usually allow macros and such), and at that resolution you likely don't want to be restricted by the range from the protocol (not sure if it's large enough) so I wouldn't be surprised if they return multiple motions instead. Would need to test a few of those (or at least one or two) to see what they do. Sucks that it requires buying some =P

I'd assume that things like macros (for gaming mouses) are done by the driver and not the mouse itself.

To determine speed of movement (needed for things like first person shooters, where it's camera rotation rather than pointer coordinates) you need to know distance and time, but mouse only sends distance - the time comes from "fixed frequency of samples". If the mouse sent additional packets on overflow then you wouldn't be able to determine movement speed.

The other thing to worry about is available bandwidth. Typically PS/2 is limited to around 1000 bytes per second, and the 200 samples per second with 4 bytes per sample works out to about 80% of available bandwidth on its own.

The range those tested mouses do is kind of suspicious though. I mean, it's possible it's just the microcontrollers trying to use a signed 8-bit integer, but I wonder if there's anything important out there that misbehaves outside this range (if there's anything that ignores the sign bits, it'd misinterprete the motion as soon as it's below -128 or over +127). Though so far it seems nothing is sending invalid packets, so there's that.

Without changing the protocol (or, while retaining compatibility with normal drivers) the best case possible is 10-bit signed, with normal values from -511 to +510, and where -512 and +511 indicate the true (signed) overflow.

If a gaming mouse change the protocol (e.g. adds a special "non-standard enhanced mode" that only its own driver enables) then it'd be able to do whatever it liked, but would be beyond the scope of an OS's generic PS/2 mouse driver.


Cheers,

Brendan

[MDenham]

Yeah, I'm wondering about gaming mouses which can have pretty high DPI (or at least report that). The firmware on those mouses is normally more complex though (since they usually allow macros and such), and at that resolution you likely don't want to be restricted by the range from the protocol (not sure if it's large enough) so I wouldn't be surprised if they return multiple motions instead. Would need to test a few of those (or at least one or two) to see what they do. Sucks that it requires buying some =P

...or asking for testers specifically for this is another, cheaper option. (Unfortunately I don't have a gaming mouse at this point in time, or I'd volunteer.)

[FallenAvatar]

Hi,

...

The other thing to worry about is available bandwidth. Typically PS/2 is limited to around 1000 bytes per second, and the 200 samples per second with 4 bytes per sample works out to about 80% of available bandwidth on its own.

...


Cheers,

Brendan

I haven't (ever?/in a while) seen a PS/2 gaming mouse. Do USB Mice use some form of PS/2 commands over USB or something?

- Monk

[FusT]

From the wiki:

A USB mouse generally emulates a PS2 mouse, except that it generates IRQs from the USB bus, and not IRQ 12.

http://wiki.osdev.org/Mouse_Input#USB_Mouse