In my case the drift is still present when running, although interestingly the visible gaps in mouse cursor trail have almost entirely been eliminated.
So, if we're still seeing directional drift, despite using floating-point accumulation, here's what that tells us.
What this app rules out:
- Rounding loss from integer deltas → Mitigated by float accumulation
- Mouse input scaling errors → Not present here; raw values passed through as-is
- OS cursor filtering → Not affecting us directly; we override movement
- Display-side desync / rendering aliasing (e.g., DWM compositor jitter, vsync delay)
- Mouse hardware motion resolution bias (e.g., sensor gives "cleaner" X than Y) although unlikely given how many different mice have been tested
- Timer or event loop timing issues (e.g., uneven update rate → directional offset)
- Hidden smoothing/filtering at the GPU or OS level (even Raw Input doesn’t bypass all subsystems)
- Mouse input vector aliasing (e.g., diagonals rounding unevenly depending on quadrant)
- Polling-rate-induced imbalance — not all hardware sends deltas evenly
UPDATE: I made the tool and drift still occurs. This tells us the drift is happening before or during raw input generation, not from rounding or OS cursor handling.
So at the current stage of testing, it could be:
Common Input Processing Layers;
- Many devices process input data through similar USB controllers or chipset architectures, especially PCs and laptops.
- Consoles may also use similar USB input standards or HID layers.
- Any common firmware or driver component in the USB stack or OS input subsystem could introduce subtle bias or latency.
- USB polling intervals, jitter, or timing inconsistencies in the USB host controller hardware or firmware could cause subtle skew in input timing.
- This can manifest as tiny accumulated positional errors across all input devices on that bus.
- Input devices rely on timing between sensor reports and system clocks.
- If clocks are not perfectly synchronized or have jitter, movement deltas might be integrated incorrectly, causing drift.
- Some third-party software or background processes running across devices (e.g., input enhancers, anti-cheat, overlays) could hook raw input and unintentionally introduce bias.
- However, on consoles this is less likely unless special middleware is installed.
Additional information regarding commonalities & differences:
- Common USB HID specification:
All devices implement USB HID class standard to handle mice, keyboards, etc.
This means the protocol and data format are consistent across all devices.
- Driver/firmware differences:
The USB host controller firmware and OS drivers are different implementations on each platform.
There is no single universal driver or firmware component common to all three platforms beyond the USB HID standard itself.
- Possible shared vulnerabilities or behaviours:
Since all rely on USB HID specs and USB polling, timing issues or interpretation quirks in how the spec is implemented could cause similar effects.
Shared between devices, it could also be Input API / Driver Design Constraints:
- All devices use event-driven input models where raw hardware signals get translated into input events and then delivered to applications.
- The buffering and event queuing logic aims to batch, smooth, or optimize input for performance or latency reasons.
- This can introduce subtle timing jitter, aggregation errors, or filtering artifacts that might create small, systematic drift if deltas are imperfectly processed.
- Because USB HID reports are inherently relative movement deltas, even tiny cumulative errors or rounding in the input stack can accumulate over time.
https://drive.google.com/file/d/1Iaa0VP ... sp=sharing
EDIT: this has been flagged a suspicious by google drive, I have requested a review and hopefully it's cleared.
Unfortunately the file is too large to post directly.