The mouse drifting issue potential breakthrough

[Vocaleyes]

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.

[Hyote]

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.

[Hyote]

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.

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

[Hyote]

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.

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

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

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

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

[Slender]

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.