Page 2 of 4
Re: The mouse drifting issue potential breakthrough
Posted: 24 Nov 2025, 00:53
by Vocaleyes
Hyote wrote: ↑23 Nov 2025, 17:59
But regardless if Windows 7 and Linux X11 without composition count, then they still suffer from the same issues.
Would you mind expanding on what you mean by this please?
Also when you say you are using RDTSC, this unfortunately still wouldn't bypass the DWM math.
RDTSC measures when something happens, not how the coordinates are mathematically processed. The floating point math in DWM still applies to the actual coordinate values regardless of when they're read. Even if you read input with perfect precision, Windows 11's floating point system still accumulates fractional values differently than windows 7's integer remainder model.
RDTSC
can help reduce latency variance by allowing synchronous input sampling, but it cannot change the mathematical model of how deltas are accumulated.
You mentioned Linux, have you observed the same effect there too? As that is also explained with applied math, albeit slightly differently than Windows.
Re: The mouse drifting issue potential breakthrough
Posted: 24 Nov 2025, 06:05
by Hyote
Kipperii wrote: ↑23 Nov 2025, 22:25
Hyote wrote: ↑23 Nov 2025, 18:21
viewtopic.php?t=8885
Like it's mentioned in the post, I use RDTSC now but instead of injecting it, I use it as a separate program which doesn't trip anticheats at least it hasn't been a problem for a month now.
how to use it as a separate program?
I'm working on that rn, but you can join the Felipetweaks Discord server and the fwf section has everything needed. The author is the same person behind the RDTSC post here.
Re: The mouse drifting issue potential breakthrough
Posted: 24 Nov 2025, 06:09
by Hyote
Vocaleyes wrote: ↑24 Nov 2025, 00:53
Hyote wrote: ↑23 Nov 2025, 17:59
But regardless if Windows 7 and Linux X11 without composition count, then they still suffer from the same issues.
Would you mind expanding on what you mean by this please?
Also when you say you are using RDTSC, this unfortunately still wouldn't bypass the DWM math.
RDTSC measures when something happens, not how the coordinates are mathematically processed. The floating point math in DWM still applies to the actual coordinate values regardless of when they're read. Even if you read input with perfect precision, Windows 11's floating point system still accumulates fractional values differently than windows 7's integer remainder model.
RDTSC
can help reduce latency variance by allowing synchronous input sampling, but it cannot change the mathematical model of how deltas are accumulated.
You mentioned Linux, have you observed the same effect there too? As that is also explained with applied math, albeit slightly differently than Windows.
Yes, in fact I still find Windows 11 with DWM to be the most consistent without the VSync effect applied. Unfortunately I'm using a few programs that were made by others so I can't explain the functions but it's essentially a DWM-less DWM.
Re: The mouse drifting issue potential breakthrough
Posted: 24 Nov 2025, 11:50
by Vocaleyes
For anyone interested, heres how linux is also involved.
So while Linux doesn't use DWM, linux libinput uses li_fixed_t data type for coordinate storage and processing, not standard floating-point. The libinput source code shows pointer delta values are stored in li_fixed_t x and li_fixed_t y format.
li_fixed_t is a fixed-point representation, which is a hybrid between integer and floating-point precision. However, the key finding is wayland’s touch calibration protocol explicitly uses 32-bit floating point format for calibration matrix values, and Wayland compositors apply floating-point based transformation matrices when processing coordinates.
Linux's X11 and Wayland input transformation pipeline uses affine transformation matrices (3x3 matrices) with floating-point values to transform coordinates. These matrices are applied to accumulate coordinate transformations across multiple processing stages.
Wayland's floating-point transformation matrices would affect mouse input in the exact same way DWM and PS4 do.
Re: The mouse drifting issue potential breakthrough
Posted: 24 Nov 2025, 13:02
by Hyote
Vocaleyes wrote: ↑24 Nov 2025, 11:50
For anyone interested, heres how linux is also involved.
So while Linux doesn't use DWM, linux libinput uses li_fixed_t data type for coordinate storage and processing, not standard floating-point. The libinput source code shows pointer delta values are stored in li_fixed_t x and li_fixed_t y format.
li_fixed_t is a fixed-point representation, which is a hybrid between integer and floating-point precision. However, the key finding is wayland’s touch calibration protocol explicitly uses 32-bit floating point format for calibration matrix values, and Wayland compositors apply floating-point based transformation matrices when processing coordinates. Microsoft Learn
Linux's X11 and Wayland input transformation pipeline uses affine transformation matrices (3x3 matrices) with floating-point values to transform coordinates. These matrices are applied to accumulate coordinate transformations across multiple processing stages.
Wayland's floating-point transformation matrices would affect mouse input in the exact same way DWM and PS4 do.
For all the previous reasons, I explicitly tried evdev and the issues remained. Although I didn't do any kind of a deep dive into these topics like you did now.
Re: The mouse drifting issue potential breakthrough
Posted: 25 Nov 2025, 00:57
by Vocaleyes
Hyote wrote: ↑24 Nov 2025, 13:02
Vocaleyes wrote: ↑24 Nov 2025, 11:50
For anyone interested, heres how linux is also involved.
So while Linux doesn't use DWM, linux libinput uses li_fixed_t data type for coordinate storage and processing, not standard floating-point. The libinput source code shows pointer delta values are stored in li_fixed_t x and li_fixed_t y format.
li_fixed_t is a fixed-point representation, which is a hybrid between integer and floating-point precision. However, the key finding is wayland’s touch calibration protocol explicitly uses 32-bit floating point format for calibration matrix values, and Wayland compositors apply floating-point based transformation matrices when processing coordinates. Microsoft Learn
Linux's X11 and Wayland input transformation pipeline uses affine transformation matrices (3x3 matrices) with floating-point values to transform coordinates. These matrices are applied to accumulate coordinate transformations across multiple processing stages.
Wayland's floating-point transformation matrices would affect mouse input in the exact same way DWM and PS4 do.
For all the previous reasons, I explicitly tried evdev and the issues remained. Although I didn't do any kind of a deep dive into these topics like you did now.
evdev passes raw integer deltas from the kernel (REL_X, REL_Y as pure integers). However, evdev is just the transport layer, it's not the end of the input pipeline.
Everything built on top of evdev (libinput, Wayland compositor, X11 server) performs floating-point normalization and transformation on those integer values.
in normal Linux usage, you cannot bypass libinput and the compositor, they are mandatory processing layers.
So in practical terms, yes, evdev-based systems exhibit the issue because the problem is not evdev itself, but the floating-point normalization and transformation layers that process evdev's integer output.
Re: The mouse drifting issue potential breakthrough
Posted: 25 Nov 2025, 21:37
by Vocaleyes
Furthermore since this issue still appears within games that use raw input would also lead me to believe that mouse manufacturers have aligned their math with windows native implementation.
This would be for the purpose of mathematical compatibility between the driver's output and the OS's input pipeline. This could reduce latency or improve coordinate precision by avoiding redundant conversions.
However, this alignment would also mean the driver inherits DWM's floating point accumulation problems.
This would also explain why in the desktop environment the drift is more severe than in-game.
Re: The mouse drifting issue potential breakthrough
Posted: 25 Nov 2025, 22:17
by Vocaleyes
In summary for now;
Mouse Driver Implementation:
Mouse driver manufacturers standardized on floating-point delta normalization around 2015 to maintain compatibility with modern OS floating-point input pipelines (DWM on Windows, Wayland on Linux, console stacks). This driver-level implementation accumulates fractional remainders across frames, which compounds into exacerbated circle drift on relative input devices.
Why Absolute Positioning Devices Don't Exhibit It:
Absolute devices report fixed coordinates each frame, not accumulated deltas. Without delta accumulation, there's no frame-to-frame remainder carry-over. Each coordinate is independent and fresh, eliminating the floating-point rounding error compounding mechanism entirely. Even though they pass through floating-point pipelines, the lack of delta accumulation prevents the exacerbation.
Re: The mouse drifting issue potential breakthrough
Posted: 27 Nov 2025, 10:07
by Sandy
The earliest mention of input lag dates back to the Windows 98 era, and I can confirm that XP and Win7 systems also have input lag, even with DWM completely disabled.
Re: The mouse drifting issue potential breakthrough
Posted: 27 Nov 2025, 19:16
by Slender
Sandy wrote: ↑27 Nov 2025, 10:07
The earliest mention of input lag dates back to the Windows 98 era, and I can confirm that XP and Win7 systems also have input lag, even with DWM completely disabled.
in any case, xp and w7 will be faster than any other version of windows. I remember installing win7 in 2020, when faceit support still existed. In cs go, where on windows 10 I had unstable 200-250 fps, on windows 7 I got a completely stable 299 frames, the sensations were 1:1.