VOGONS

PS/2 mouse polling rate explanation?

Topic actions

First post, by superfury

Posted on 
User metadata
Rank l33t++
Rank
l33t++

So I know that the polling rate (in Hz) affects the amount of movements (from A to B on each axis) being reported each second.

Now, how does this affect the movement itself? Does it simply means how many time per second it accumulates movement since last report and report that (what UniPCemu's mouse emulation does (with serial mice as well))? Or does it affect other things as well?

So the mouse simply keeps accumulating any movement it sees into an internal relative x/y register, then once the interrupt fires(the packet is to be sent using the PS/2 cable) it sends the accumulated data over? What if it's out-of-range
(overflow)? Although UniPCemu can't really overflow it's massive relative movement stored (32-bit integer storing mm(PS/2) or mickeys(serial)). Right now it just accumulates the total movement and on each packet tick sends a packet with up to max movement and substracts it from it's accumulated movement for next packets, stopping to send packets once both x/y movement reaches 0 and buttons don't change. Any movement or button activity will start packets at the next timer tick again.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 1 of 1, by mkarcher

Posted on 
User metadata
Rank l33t
Rank
l33t

I don't think there is a general answer to that question. Indeed, the reporting rate of a PS/2 mouse tells the mouse the minimum time to elapse between two PS/2 packets to be sent. A mouse will not send a packet if it was not moved nor a button pressed or released since the last packet. Having a fixed timer in the mouse processor scheduling packet sends which is only suppressed if the packet would be meaningless is one straightforward way to implement it.

There is no specification indicating how many bits the internal movement counter of the mouse should have. You expect it to have at least as many bits as there are in the PS/2 protocol, but it might not have any more, so the accumulator might already be saturating before sending the packet to the host. In that case, the accumulator can be reset to zero after each packet. I don't think it makes sense to have the mouse in a state in which it will send PS/2 packets for more than a fraction of a second to clear out backlog after an enormous movement, so clamping the accumulator to 8 times what can be reported in a packet seems to be a sensible thing.

If I remember correctly, there are observations of cheap PS/2 mice that do not accumulate movement while sending data to the host, so they tend to get sluggy and imprecise if you increase the sampling rate to high values (100 or 200 reports/second).

Go to top of page Go to top of page
Back to PC Emulation
Close window
Close window