[amluto]

The author didn’t say that they have a use for those 3200 updates per second other than as a workaround for some other issue. With a competently composited desktop and applications that pace input processing and frame generation well, and ignoring pointer acceleration, 1 correctly timed update per frame is enough. (As far as I know this does not exist from any vendor on a modern system other than for games, although really old Apple II-era software often got it right.). For acceleration, some pointer history is needed. And no one has a mouse that has an API that allows the host to pace the updates.

Presumably the 3200 Hz is needed for a combination of reasons:

- Under ideal conditions, if you want less than 10% variation in the number of samples per frame at 240Hz, you may need ~2400Hz. This effect is visible even by human eyeballs — you can see multiple cursor images across your field of view, and uneven spacing is noticeable.

- The mouse itself may work less well at a lower sampling rate.

- The OS and input stack may be poorly designed and work better at higher rates.

In any case, the application and cursor implementation are unlikely to ask for a mouse location more than once per frame, so the user is not really using 3200 updates per second, but that’s irrelevant.

[ptramo]

First it's settings not real numbers. I'm not claiming that's how the mice actually perform, only how I tell them to perform.

Second 3200 was DPI not Hz. I can trivially tell how much I have to move with 3200 DPI (my sweet spot with 2 4K monitors), 4800 DPI, and 6400.

For Hz, it was the polling rate. With a configured 8000 Hz polling rate which is a lie/peak, I still see stalls in the 4ms range with my hardware.

As to acceleration I disable it. To truly lose it at high DPIs I've had to install RawAccel on Microsoft Windows.