MOUSE SENSITIVITY CONVERTER / COUNTS AND TIME
Mouse polling rate is not a sensitivity conversion factor
Do not multiply a converted sensitivity by the ratio of two polling rates. In a constant linear count model, rotation depends on accumulated movement counts, while polling rate describes reporting frequency. Repackaging the same counts into more reports leaves the total turn unchanged. This model does not guarantee that every real device or game preserves those counts.
Published November 2, 2026 · AimConvert · an independent developer
Open the sensitivity converter ↗Keep the units attached to the numbers
Counts per inch describes a spatial scale. Reports per second describes a temporal rate. Degrees per count describes a chosen rotation response. They answer different questions. Microsoft's relative RAWMOUSE documentation exposes signed horizontal and vertical motion information; an input record is not defined as one unit of movement. A program must interpret the supplied motion, not assume each event means a fixed distance.
Real software behavior matters. Godot's official engineering report describes handling problems and changes for high polling rate input on Windows. That is evidence that input processing needs attention, not a reason to assert that every game works correctly or to prescribe a universal sensitivity multiplier. The calculations below isolate a lossless constant-response model rather than benchmark an engine.
Construct one motion, then package it three ways
Select a forty-millisecond horizontal motion containing 320 positive counts in total. Divide it into forty one-millisecond pieces, each containing eight counts. These are invented integer samples, not a recorded mouse trace. Select a constant rotation response of 0.05 degrees per count, so the accumulated rotation is 320 × 0.05 = sixteen degrees.
Package the selected samples into ideal reports every eight milliseconds: five reports each contain sixty-four counts. At two milliseconds per report, twenty reports each contain sixteen. At one millisecond per report, forty reports each contain eight. The corresponding selected rates are 125, 500 and 1000 reports per second. All three sums are 320 counts, and all three rotations are sixteen degrees.
The arithmetic is a partition: regrouping the same list into different consecutive buckets changes the bucket sizes, not its sum. Timing information differs between the packaged sequences, but final accumulated rotation does not. This establishes only a conditional result for the selected model. It does not establish actual USB delivery timing, display behavior or end-to-end input latency.
Calculate full-turn distance without a time-rate term
Keep the selected response at 0.05 degrees per count. A full turn requires 360/0.05 = 7200 counts. Select a spatial scale of 800 counts per inch. The corresponding distance is 7200/800 = nine inches, or 22.86 centimeters using 2.54 centimeters per inch. Changing the report partition above does not change either of these selected coefficients.
For comparison, multiplying the forty-report sequence's sensitivity by eight because 1000/125 = eight changes the selected response to 0.4 degrees per count. A full turn would then require nine hundred counts, giving 2.8575 centimeters at the same spatial scale. That is an eightfold response change, not preservation of the original 22.86-centimeter turn distance. A frequency ratio cannot be inserted into this conversion without changing the problem.
Why counting events or averaging deltas fails this test
Imagine a fictional routine that gives one degree for every received report regardless of its motion value. The same constructed motion becomes five, twenty or forty degrees depending on the packaging. That routine has substituted event count for motion count. It violates the lossless accumulation model by design; it is not a claim about an existing product.
A different fictional mistake averages report deltas and multiplies that average by 0.05 once. The eight-millisecond sequence has a mean of sixty-four counts, yielding 3.2 degrees. The one-millisecond sequence has a mean of eight, yielding 0.4 degrees. Neither is the correct sixteen-degree sum. The report average has different meaning from the total over the selected interval. A useful audit compares both accumulated counts and resulting rotation, not just the number of callbacks.
When a real comparison needs more evidence
If changing a polling setting appears to change a real full-turn distance, preserve the same DPI profile, sensitivity, aim mode and measurement procedure while documenting each condition. Check actual retained settings and software input handling before applying a rate multiplier. The synthetic partition argument cannot identify a changed profile, dropped motion, nonlinear processing or a measurement error from a subjective feeling alone.
For a practical record, use the measurement guide. For spatial and angular quantities, see counts per turn versus turn distance. This page adds time and report packaging; it does not recommend a mouse setting or claim a particular latency improvement.
Direct answers
Does a report always contain one movement count?
No. In the constructed example a report contains eight, sixteen or sixty-four counts, depending on its interval.
Should I scale sensitivity when moving from 125 to 1000 reports per second?
Not from that rate ratio alone. It is absent from the stated lossless linear conversion.
Can two polling settings feel different despite equal turn distance?
The model permits different report timing with the same accumulated rotation. It does not measure or explain a particular user's experience.
Sources and method
Microsoft RAWMOUSE provides motion-record context. Godot's input-handling report provides a concrete software context. All sample counts, response coefficients, partitions and incorrect-routine outputs were independently selected and calculated; no hardware trace, latency test or current-game certification is reported.