Blur Busters Forums

• 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

• 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.

• 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.

• 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.

Vocaleyes wrote: ↑

15 Jun 2025, 18:45

Here is an app which uses floating point math with fractional retention in an effort to diagnose bias accumulated mouse drift.
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

What may still be causing drift:

• 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

Next I'll make a drift isolation tool to rule out display/OS-level drift and verify it's input-path-only. I will share test results of that in this thread. Enjoy!
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.

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.

internetexplorer4 wrote: ↑

15 Jun 2025, 20:34

Vocaleyes wrote: ↑

15 Jun 2025, 18:45

Here is an app which uses floating point math with fractional retention in an effort to diagnose bias accumulated mouse drift.
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

What may still be causing drift:

• 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

Next I'll make a drift isolation tool to rule out display/OS-level drift and verify it's input-path-only. I will share test results of that in this thread. Enjoy!
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.

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.

hey, I'm sorry, I'm not trying to go against you and not trying to convince you since I already said this to you before, this is for other people who read the post

I think that if other people read this and also start to think that their problem comes from mouse drift, this might be an useful information for them, which is:

I have the same exact problem of "floaty mouse", the feeling of moving the mouse on ice, feeling that mouse is not 1:1, feeling that the dpi is higher than it should, with a drawing tablet (feeling of input lag was also the same).

drawing tablets have a specific thing called absolute positioning, so it doesnt have drift at all. most osu players play with a drawing tablet as aiming device instead of mouse, I'm an osu player so I tried playing with tablet for many months and the exact same problem of the mouse is also there in the tablet, even worse tbh

Vocaleyes wrote: ↑

15 Jun 2025, 20:57

internetexplorer4 wrote: ↑

15 Jun 2025, 20:34

Vocaleyes wrote: ↑

15 Jun 2025, 18:45

Here is an app which uses floating point math with fractional retention in an effort to diagnose bias accumulated mouse drift.
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

What may still be causing drift:

• 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

Next I'll make a drift isolation tool to rule out display/OS-level drift and verify it's input-path-only. I will share test results of that in this thread. Enjoy!
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.

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.

hey, I'm sorry, I'm not trying to go against you and not trying to convince you since I already said this to you before, this is for other people who read the post

I think that if other people read this and also start to think that their problem comes from mouse drift, this might be an useful information for them, which is:

I have the same exact problem of "floaty mouse", the feeling of moving the mouse on ice, feeling that mouse is not 1:1, feeling that the dpi is higher than it should, with a drawing tablet (feeling of input lag was also the same).

drawing tablets have a specific thing called absolute positioning, so it doesnt have drift at all. most osu players play with a drawing tablet as aiming device instead of mouse, I'm an osu player so I tried playing with tablet for many months and the exact same problem of the mouse is also there in the tablet, even worse tbh

That's very useful information, and also the first i've heard of an absolute positioning device exhibiting inaccuracies. Is there any chance you can capture and share that please? It doesn't have to be flawless hd, crude video works fine. if your screen has a "cursor" that should show the issue quite nicely, as the stylus would be in a fixed point while the cursor should deviate. Cheers for the feedback regardless!

If however you manage to test and the cursor doesn't drift out of position from where the stylus is, and is just the floaty feeling then we can assume it isn't a shared issue, however an element might be, which is compositing using vsync which is also present on PCs, laptops and console (although console i'm pretty sure is just general vsync that you cant disable, maybe not compositing) but we all know how vsync makes a mouse feel .

Vocaleyes wrote: ↑

15 Jun 2025, 18:45

Here is an app which uses floating point math with fractional retention in an effort to diagnose bias accumulated mouse drift.
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

What may still be causing drift:

• 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

Next I'll make a drift isolation tool to rule out display/OS-level drift and verify it's input-path-only. I will share test results of that in this thread. Enjoy!
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 Host Controller or Bus Issues;

• 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.

System Clock or Timing Synchronization Issues;

• 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.

Shared Software or Middleware;

• 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.

These are all viable options, even between pcs, laptops and consoles.


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.

Since they all follow the USB HID standard, any misinterpretation or timing quirks in USB polling or HID report processing could theoretically manifest similarly across devices

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.

Even though I tested using fixed-point math instead of floating point, If there’s bias or jitter introduced before the app receives the data — inside the driver or API layers — fixed-point math won’t change or fix that. Fixed-point math can only ensure that processing doesn’t add new rounding errors on top of what is already received.



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.