Mark Rejhon thx for 5kHz, ask Msoft next for mouse CPI standard

[snoukkis]

Dear Mark Rejhon, I just read your article "Upcoming Windows 11 Supports 5000 Hz Display Refresh Rate".
Good job with pushing the display refresh rate support forward!
Amazing job!

But wait, you noted that:

Low Mouse DPI Also Sabotages High Hz

In addition, the use of low mouse DPI (400dpi-800dpi) can sabotage the benefits of your high refresh rate display, for slow mouselooks.

Moving a mouse at 400dpi at 0.25 inches per second only shows 100 mouselook frames per second, utilizing only one-tenth the refresh rate of a new 1000 Hz monitor! Therefore, this can hurt some competitive advantages in certain games that may utilize frequent slower mouse tracking operations.

Right, bummer...
There's a reason people don't use much more than 800-1600 DPI.
Coz it makes your cursor or camera move dizzy fast.
But wait... isn't the DPI a precision attribute, not speed attribute?
Yup, but not what games see. They just see counts, or just the C in CPI, basically same number that is termed DPI for mice for some reason. Dots per inch are kind of silly with mice. Whatever, I'll say CPI/DPI interchangeably from now on.

Wouldn't it be nice if those mice would report their current CPI setting?
Then Windows could normalize the counts it gets from mice during each poll.
And well even more nice would be if they normalized that and told to games and other software how many mm or inches (the I in CPI) the mouse moved? That would be nice.
Then in game I could set that I want e.g. 3.6 degree/mm camera movement.

And think how nice: this would be same units in EVERY GAME, heck it could be ever written down in Windows mouse settings panel for all games to read that user wants x degrees of mouse movement per every mm, regardless of game, mouse, CPI setting, or anything else. How crazy would that be?
And the beef: you can now safely use the maxed out DPI setting in the games for better precision (less quantization error) at same camera movement speed per mouse movement!

Want to take it further. Okay let's go.
Windows could also configure cursor movement in "screen height / mm".
Why? Because then I can not only max out my mouse settings while moving camera in game,
but also when I move the cursor in the game... or in Windows GUI!
Yeah! That's right, now I can just keep my mouse in max DPI setting ALL THE TIME!
Crazy cool!

And if you think about it, it's so simple thing to want. All that is needed is the current CPI count reported in standard way to windows and windows reporting that to games in consistent way. One damn integer number is what's missing.

And to think that this one thing missing is what would have made the DPI race to silly mouse speeds actually worthwhile. We could have solved the above quoted problem already decades ago with that one missing number instead of that insane mouse speed/sensitivity race the mouse vendors undertook.

Want to take it further? Instead of having the mouse report just the CPI to Windows, why not include the poll rate too? And make both configurable. Just like we do with displays when we set resolution and refresh rate.

With great respect, Mark Rejhon, since you have such great contact with the industry, why don't you ask if they would be willing to fix this?
I asked ChatGPT to draft some letters if you want some idea where to get started:

Letter 1 — Microsoft

Subject: Make Windows mouse input CPI-aware

To the Windows input, gaming, and platform teams,

Higher mouse CPI is widely treated as if it mainly exists to make the pointer or camera move faster. That is the wrong model. The real value of higher CPI is higher spatial precision. A higher-CPI sensor should reduce quantization and jitter by measuring smaller movements more finely. That matters more as display refresh rates and polling/report rates increase, because poor spatial granularity becomes easier to see.

But that extra precision is only useful if the input is normalized. Without normalization, software receives abstract counts whose meaning changes with the current CPI setting. With normalization, software gets a stable, CPI-independent input value and can map it consistently to cursor motion or camera motion.

Polling/report rate matters for the same reason in the temporal domain. CPI determines spatial precision. Polling/report rate determines temporal precision. If Windows is going to turn modern mouse hardware into normalized motion rather than mere speed, both need to be standardized, readable, listable, and writable.

The hardware already exists. The bottleneck is the standards, firmware conventions, and OS stack. Working together with USB-IF and mouse vendors, Windows should support a standard way to read the current CPI and polling/report rate, list the supported CPI and polling/report rate values, and set those values. Mouse vendors need to implement that standard in hardware and firmware. Windows then needs to build settings and APIs on top of it that normalize motion into physical units.

1. Work with USB-IF and mouse vendors on standard CPI and polling/report-rate controls
   • standard USB/HID support for reading current CPI
   • listing supported CPI values or ranges
   • writing CPI settings
   • reading the current polling/report rate
   • listing supported polling/report rate values
   • writing polling/report rate settings
2. Build Windows settings and APIs on top of those standardized capabilities
   • support meaningful user-facing motion controls without tying Windows to vendor-specific utilities
   • give software a stable, standardized foundation instead of forcing every application to guess or work around hardware differences
3. Add a Windows API for normalized mouse motion
   • use CPI to convert raw counts into physical movement
   • expose normalized motion directly to applications in physical units such as millimeters
   • use floating-point values so the added precision is preserved
   • keep this usable for both cursor movement and application input
4. Keep speed scaling separate from sensor precision
   • pointer speed and other scaling choices should remain policy layers above normalized motion
   • CPI should be treated as sensor resolution, not as a speed knob

Windows already has raw input. The missing piece is a CPI-aware normalization layer, backed by standardized hardware reporting, that turns raw counts into physically meaningful motion and exposes that directly to software.

A standardized CPI-aware mouse stack would let Windows turn better mouse hardware into a visible platform advantage instead of leaving that value fragmented behind vendor utilities.

Letter 2 — Mouse Vendors

Subject: Standardize CPI and polling as precision controls, not speed controls

To mouse manufacturers and gaming peripheral vendors,

Higher CPI is widely marketed and understood as a way to make the pointer or camera move faster. That is the wrong model. The real value of higher CPI is higher spatial precision.

A higher-CPI mouse should reduce quantization and jitter by measuring smaller movements more finely. That matters more now because display refresh rates and polling/report rates have increased, so poor spatial granularity is easier to notice.

But that extra precision is only useful if the platform can normalize the input. Without normalization, software sees abstract counts whose meaning changes with the current CPI setting. With normalization, operating systems and games get a stable, CPI-independent input value and can use it consistently.

Polling/report rate matters for the same reason in the temporal domain. CPI determines spatial precision. Polling/report rate determines temporal precision. If the platform is going to use modern mouse hardware properly, both need to be standardized, readable, listable, and writable.

The hardware already exists. The bottleneck is the standards, firmware conventions, and OS stack. Working together with Microsoft, other OS vendors, and the USB-IF/HID standards process, vendors should implement standard hardware support for reading current CPI, listing supported CPI values, and writing CPI settings. The same should apply to reading the current polling/report rate, listing supported polling/report rate values, and writing those settings. Once that exists, operating systems can build normalized motion APIs and user-facing controls on top of it.

1. Implement standard USB/HID CPI and polling/report-rate controls
   • read current CPI
   • list supported CPI values or ranges
   • write CPI settings
   • read the current polling/report rate
   • list supported polling/report rate values
   • write polling/report rate settings
2. Work with Microsoft and other OS vendors on adoption
   • make the standardized controls usable from operating-system settings and developer APIs
   • stop forcing users to depend on vendor-specific utilities for basic motion settings
3. Report accurate CPI values
   • if a device reports a CPI value, it should be accurate enough for operating systems and applications to use as a physical conversion factor
4. Treat CPI as precision in product design and messaging
   • the point of higher CPI is finer motion measurement
   • speed should be handled separately by the operating system or application

If the platform could rely on standardized CPI and polling information, vendors could compete more meaningfully on real sensor quality, precision, stability, latency, and consistency.

In the era of high-refresh displays, this would make better mouse hardware more desirable by allowing its extra sensor precision to produce a clearer and more consistent user benefit.

Letter 3 — USB-IF / HID Standardization Bodies

Subject: Standardize CPI and polling capabilities for USB mice

To the USB-IF HID and related standardization groups,

The USB HID mouse model solved compatibility, but it did not solve interpretation.

Today, a USB mouse works everywhere as a mouse, but the standard path still gives hosts abstract relative counts while the settings that determine what those counts mean—especially CPI and polling/report rate—remain largely vendor-private.

That is why higher CPI is so often treated as if it were mainly about speed. The real value of higher CPI is higher spatial precision: less quantization, less jitter, and finer motion measurement. But that extra precision is only useful if the host can normalize the input. Without normalization, software sees abstract counts whose meaning changes with the current CPI setting. With normalization, software gets a stable, CPI-independent input value it can use consistently.

Polling/report rate matters for the same reason in the temporal domain. CPI determines spatial precision. Polling/report rate determines temporal precision. If the standard is to make modern mouse hardware broadly useful, both need to be standardized, readable, listable, and writable.

The hardware already exists. The bottleneck is the standards, firmware conventions, and OS stack. Working together with mouse vendors and OS vendors such as Microsoft, USB/HID should standardize support for reading the current CPI and polling/report rate, listing supported CPI and polling/report rate values, and setting those values. That would give operating systems a stable foundation for settings and APIs that expose normalized motion directly to software.

This gap matters more now because display refresh rates and mouse polling rates have increased. Temporal sampling has improved, but spatial interpretation is still fragmented.

1. Define standard USB/HID controls for CPI and polling/report rate
   • read current CPI
   • list supported CPI values or ranges
   • write CPI settings
   • read the current polling/report rate
   • list supported polling/report rate values
   • write polling/report rate settings
2. Define accuracy expectations for reported CPI
   • the reported value should be usable as a meaningful physical conversion factor
3. Preserve the legacy mouse path
   • the new capability/configuration layer should be additive and coexist with the standard HID mouse interface
4. Design the extension for OS adoption
   • make it straightforward for Microsoft and other OS vendors to build settings and APIs that convert raw counts into normalized motion using standard CPI and polling information

The next step for the HID mouse standard is not to change what a mouse basically is. It is to make mouse motion physically interpretable in a standard way so higher sensor precision becomes useful across the platform.

Standardizing this capability would keep modern mouse functionality inside the interoperable HID model instead of leaving it fragmented across vendor-private extensions.

[Chief Blur Buster]

Dear Mark Rejhon, I just read your article "Upcoming Windows 11 Supports 5000 Hz Display Refresh Rate".
Good job with pushing the display refresh rate support forward!
Amazing job!

Thank you for the compliment!

But wait, you noted that:

Low Mouse DPI Also Sabotages High Hz

In addition, the use of low mouse DPI (400dpi-800dpi) can sabotage the benefits of your high refresh rate display, for slow mouselooks.

Moving a mouse at 400dpi at 0.25 inches per second only shows 100 mouselook frames per second, utilizing only one-tenth the refresh rate of a new 1000 Hz monitor! Therefore, this can hurt some competitive advantages in certain games that may utilize frequent slower mouse tracking operations.

Right, bummer...
There's a reason people don't use much more than 800-1600 DPI.
Coz it makes your cursor or camera move dizzy fast.
But wait... isn't the DPI a precision attribute, not speed attribute?
Yup, but not what games see. They just see counts, or just the C in CPI, basically same number that is termed DPI for mice for some reason. Dots per inch are kind of silly with mice. Whatever, I'll say CPI/DPI interchangeably from now on.

I also covered this in my post on Blue Sky and X. I'll crosspost X since it is currently getting more engagement.

Other useful read-ups
https://x.com/BlurBusters/status/2021429965103726917
https://x.com/BlurBusters/status/2041609237625774378
https://x.com/BlurBusters/status/2041608660170789214
https://x.com/BlurBusters/status/2021662284255281422

In one of these is an acknowledgement of lower DPI still has some benefits in some contexts (despite DPI sabotaging Hz)

CS2 is often played with fast-flicks only. Fast flicks with muscle memory, like you trained in an aimtrainer. You're often doing memorized flick distances nearly perfectly. This is a more DPI-independent tactic.
This is different from having to use your eyes to focus on visual objects like mowing down an overhead flying airplane (spraying flak continuously by eye), or trying to visually mouse to action in a 3rd-person POV game like Rocket League, or panning a map in RTS, etc.

- Muscle-memory-driven techniques prioritize the handshake-elimination of low DPI. CS2 often prioritize 400-800dpi since gameplay mechanics are more often flick-driven than slow-tracking-driven.

- Visual-driven techniques can re-prioritize more towards jitter-reduction of high DPI. When it outweighs handshake factors, especially when newer & better software/mice/pads/system/etc have less non-handshake-related jitter.

Your DPI is your preference.

The point of my post is I was informing the public that 240-vs-1000 Hz displays amplifies DPI benefits. This makes people re-evaluate the pros:con balance of higher DPI operations, when upgrading to quadruple digit Hz displays that may otherwise be too faint due to weak links like slow GtG or low mouse DPI (etc).

I dearly apologize for being unable to reply in bigger Walls of Texts. For every million of fans, there's not enough hours in a year do an Oprah-style "Everyone, you get a Wall of Text!" to everyone alas. But I'm reading.

My characteristically famous Wall of Texts (100% human, 0% API) influences a lot of other influencers, so I have to address these exceptions like CS2 often feeling better at 800-1600dpi. That being said, we also address that 120vs480 is more visible in a web browser than in CS2 when lots in mainstream falsely thinks high Hz is just only about games...

The "Stutter & Blur Onion" has lots of layers we have to address, like game stutter, game optimization, disk access, network ping jitter, shader compilers, texture streaming, spikes from IPC storm, jitters/stutters from error correction protocols caused by dirty electricity (the genuine scientific parts not the tinfoil hattery parts), thermal throttling stutters, mouse DPI stutters/jitters, framerate-mismatch-Hz jitters, and more. On top of the fuzzing caused by poor GtG.

Even those 300 stutters per second at 1000 Hz = extra motion blur (on top of GtG and MPRT) just like a blurry fast-vibrating music string. So yessiere, the Stutter Onion is also a Blur Onion too -- stutter/jitter can add blur when it's sub-frequencies are above flicker fusion. Stutter=blur, just different frequencies above/below your flicker fusion threshold.

We keep working to peel off the layers of the Stutter Onion. Microsoft 5000 Hz and weaksauce Mouse DPI is but only a scant scratch on the top of the Stutter Onion.

We'll keep doing our best to peel off more layers of the Stutter Onion, with our famous Blur Busters UFO, where UFO is a codeword for our proud OCD. Cheers!

____

Being an "Influencer of the Influencers" the UFO mothership is metaphorically accountable to a lot. While I have no million-view youtubes myself, the Blur Busters inspirations and invented tests are used by million-sub youtubers.

Keep communicating to the vendors, but even vendors are not always aware that it's whac a mole: Basically fixing one part of the chain may not show visible benefits if another bad part of the "Stutter & Blur Onion" is blotting out its humankind benefits.

Sincerely,
Mark Rejhon
Blur Busters / TestUFO