New thread because I'm fed up with complaints x_x (and it probably derailed enough to be its own discussion)
Hi,
BenLunt wrote:
Sik wrote:
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.
![Sad :(](./images/smilies/icon_sad.gif)
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.