Dealing with mouse drifting while in motion, at wits end.

[sqwash]

Hi there, as the title says I have been trying to figure out why this started happening some time after w7.

 

A short anecdote, I used to play FPS for hours a day on end, I was quite good, and when I first started it didn't take long at all to develop muscle memory with the mouse, maybe a week or 2.

Now, I am unable to gain a feel for mouse movement anymore due to the inconsistency of the movement whilst in motion.

There was an app made for me to see where it was going wrong, if it was at an OS level or deeper, and from what I can see the coordinates being reported from all the mice I've tested, regardless of sensor model,  are accumulating numbers in excess for certain directions depending on the orientation of the movement. (e.g. clockwise repeated circles will accumulate +x, while anti-clockwise accumulate  -x)

 

Have tried multiple different things to diagnose, incl. different hardware, mice, mousepads, configs, grubs.. you name it. Mouse movement just isn't what it used to be.

 

The only thing I can currently think of is that when the standard shifted from USB 2.0 to 3.0, as I remember that when this wasn't happening, the only ports I could use to develop the muscle memory were the top 2.0's, the other ports would feel erratic as they do now.

But this is only desperate speculation..

 

Here is a video of the issue - 

 

here is a video of myself using the previously mentioned app to diagnose - 

 

With the app, it is reading the direct reports from the mouse. The app starts recording on movement and after 1 second of inactivity will then report the accumulated results. 

If the mouse starts dead centre and finished dead centre you should see 0, 0 with (x)amount of reports, no matter how long the cursor was moved for. Which is ideal results for a correctly functioning mouse.

But in my case, due to the cursor not matching the physical movement of the mouse, is showing severely accumulated numbers despite the physical location of the mouse still being in the same starting point as ending point.

Once again these are the raw mouse values before any modification by the OS.

Please. For the love of harambe. Help.

 

Edited September 6, 2023 by sqwash

[Vaccaria]

Have you tried the experiment on linux? For example, in the latest versions of Mint there is an option to disable mouse acceleration in the settings, when I started using Mint there was no such option.

Need to define the scope of your search rather than immediately burying yourself in the depths of windows. 
As one example, I remember Logitech had a lag issue on wireless devices with close proximity to a wifi device, but this problem was not with Razer. The problem itself, the person solved by replacing the mouse, but was initially trying to dig deeper.

Any suggestion can be discussed and a solution can be reached. The USB itself contains a lot of things. It is a physical port (mom, dad) which is soldered to tracks in the layers of the motherboard, these tracks go to the chipset, the chipset itself is blah blah, etc. Which means if dig deep, need to know what to look for.

The data you provided can be interpreted as another type of information, the first type is what we capture with our eyes, the cursor is drifting. You were able to learn from the machine how it reads the signal. But there are many more variables in the depths, and only a limited number of people can know them.

I don't know. I can suggest an idea, test it in Linux.

 

 

[sqwash]

Hi there, thanks for the input. Yes this has been tested on Linux with the same outcome.

 

with regard to the test I recorded, this isn’t happening on everyone’s systems, I asked others to download the test and perform the same pattern of movement , some experienced drifting some not.

 

I can see no common denominator.

 

EDIT: The only other time i have seem my EXACT issue mentioned and addressed, is here. Mouse cursor movement drifts over time · Issue #5648 · symless/synergy-core · GitHub

Edited September 6, 2023 by sqwash

[TheNoobPolice]

This is true of all mouse sensors with current technology, this is not something new that happened. Drift will always occur to varying degrees. Some are worse than others, and some drift in different directions than others. It is also affected by pad surface, sensor type, firmware implementation, DPI resolution etc etc.

It's not really an issue for most users, because people who are interested in aiming accurately normally use sensitivities or aim styles that require lifting and re-centering the mouse, and this technique is not usually problematic for gameplay in 3D shooter games where aiming accurately tends to be of interest.

It is particularly a problem in games like Osu! though,  which rely on 2D linear displacement and whereby a lifting technique is problematic. Hence why the top players use a Stylus usually.

None of this is anything to do with the Windows version or USB spec, and it is not something you can fix or troubleshoot (besides ensuring the sensor is clean and that you don't have an uneven / dirty mouse pad, as these exacerbate the issue)

Edited September 6, 2023 by TheNoobPolice

[sqwash]

Hi mate, thanks for replying.

 

I’m aware that this isn’t due to windows version now, due to the creation of the app. Which measures the raw reports of the mouse before any tinkering of the OS whatsoever. It was noteworthy though that drivers may still have an impact.

 

When I didn’t have this issue (or at least not as prevalent) was when I was playing CoD ghosts. I started fps on that game and quickly was able to develop muscle memory. I then had to take a few years break for health and other various reasons. That was back on a 660 and the mouse being used was the same brand, being razer, only now it’s the viper 8k instead of the deathadder.

 

You mentioned aiming style, which may play an important factor as you mentioned, as I have always been a high sens player. 
I am unable to run my previous settings due to this issue, but regardless am able to recall my settings exactly, having done this for several years for hours upon hours on end due to the aforementioned health issues and free time.

I’ve always been a wrist aimer, windows speed was 3/11, polling was always 250/500 (1000 even back then wasn’t right) dpi was 1850.

The thing I don’t understand is how I was able to develop muscle memory initially within a matter of weeks to an extremely high degree of accuracy, whereas now it has been years. And it has to be due to the inconsistency in The mouse movement. 
my aim style hasn’t changed, nor has my Co-ordination diminished. 
 

another short anecdote, I also used to play DCUO which is an mmo, to quite a high standard. And it got to the point where, as you do, run out of stuff to do until future content release.

so I developed a tick essentially, of doing lap after lap around the watchtower.

 

all that repeated motion with a super speedster and not once did I feel anything comparable to the way mouse feels now.

 

I also used to play dcuo with a laptop trackpads for a while, in the early days of my pc gaming journey. Same thing there too, was able to develop muscle memory using a trackpad. Obviously after applying all the basic changes like max power plan, selective suspend, EPP disable etc.

But now, this drifting issue is ALSO happening on laptop trackpad - 

 

Something is not as it was, and the problem is it’s only based on past feeling. So nothing I can quantitatively document.

 

I can however say that it didn’t feel like this in the 98, xp, me and 7 that I can personally attest to. I skipped 8 and arrived back on 10.

 

The previous post I linked had the user Putzworks (shown in the hidden section in the middle) show what was causing this issue, and although this specific example  is mac and server based, I believe is the issue. He goes on to talk about integer rounding etc.

 

the only reason that post is something I reference, is due to the exact nature of my issue and the fact that it was fully resolved.

 

regards, and thanks again for taking the time to help me. It is taking years off my life, honestly. No worse feeling that being a runner who suddenly has one leg shorter than the other with no explanation for it, just a different gait.

Edited September 6, 2023 by sqwash

[sqwash]

I forgot to mention that after corresponding with the input engineer that developed the raw mouse app for me, informed me that this behaviour can be resolved on a laptops trackpad.

 

This happens due to built-in smoothing of precision touchpads, which, due to how pointless the need of it is, is enabled by default. Much like EPP.

There was a reg tweak which resolved, but I forget as that was a few fresh installs ago. Something like “honormouseaccel” or something.

 

anyway, back to the main point.

 

what would be the reason for previously being able to use for e.g. 3/11 and 1800dpi 500polling comfortably, but nowadays am unable to use the same settings.

 

in fact this may be of use.. I am also unable to use 6/11 400dpi. Having these settings applied results in the cursor being extremely fast and uncontrollable.

when things worked correctly, I was also able to use 8/11 comfortably, now that is entirely out of the question.

regards!

 

Edited September 9, 2023 by sqwash

[TheNoobPolice]

13 hours ago, sqwash said:

what would be the reason for previously being able to use for e.g. 3/11 and 1800dpi 500polling comfortably, but nowadays am unable to use the same settings.

Your feelings cannot be debugged though. At the risk of sounding overly facetious, probably for the same reason I used to be able to party until 4am and still play Sunday league at 9am, and nowadays would need 2 days off work to recover lol. Our minds and bodies change over time.

14 hours ago, sqwash said:

when things worked correctly, I was also able to use 8/11 comfortably, now that is entirely out of the question.

It doesn't usually matter what Windows sensitivity you use for most games that read Raw Input, but you should not Windows slider higher than 6/11 anyway. Any values below are fine but there is some wonky extrapolation / rounding in the code above that . You can see that in this paint test here:



This a scripted perfect circle input with remainders properly carried via integer truncation (the same way a mouse sensor would - you have to do this otherwise you get drift just due to desktop pixel granularity).

You can see the errors in the more jagged output on the left. This has been present since before XP at least and the code has never been changed by Microsoft.

These have been traced over themselves at least a dozen times, so the interesting thing is that the 8/11 errors are also consistent (i.e. always creates the same distortion in the same way for the same inputs). This is perhaps why you were still able to use 8/11 fine and just learned how this error feels.

Here's a Logitech script anyone can use to test it themselves (or to check my math)

EnablePrimaryMouseButtonEvents(true);

counts = 4  -- Distance sent on each angle. 4 for 6/11, 2 for 8/11 etc

scale = 2 * math.pi / 360
carryX = 0
carryY = 0

local int = function(v)
    if v < 0 then
        return math.ceil(v)
    else
        return math.floor(v)
    end
end

-- turn on ScrollLock, then just hold left mouse button in paint
function OnEvent(event, arg)
    if IsKeyLockOn("scrolllock")then
        repeat
            if IsMouseButtonPressed(1) then
                repeat                
                    for i = 1, 360 do
                        local angle = scale * i
                        local x = (- counts * math.cos(angle)) + carryX
                        local y = (- counts * math.sin(angle)) + carryY
                        MoveMouseRelative(int(x), int(y))
                        carryX = x - int(x)
                        carryY = y - int(y)
                        Sleep(1)
                    end
                until not IsMouseButtonPressed(1)
            carryX = 0
            carryY = 0
            end
        until not IsKeyLockOn("scrolllock")
    end
end

[sqwash]

Hey mate thanks for the reply again,

 

Quote

Your feelings cannot be debugged though. At the risk of sounding overly facetious, probably for the same reason I used to be able to party until 4am and still play Sunday league at 9am, and nowadays would need 2 days off work to recover lol. Our minds and bodies change over time.

 

100%, which sucks. Sometime I wish that Karl Pilkington's machine where you could feel other peoples feelings existed, would be amazing in times like these!

To the decline with age, I don't disagree with you at all in that regard, but usually when it comes to age it would be a gradual decline, this was seemingly overnight, the problem is I've been trying to figure it out for 6 years now, so the age thing although applicable entirely to a degree, wasn't the reason this initially started. 

 

Quote

It doesn't usually matter what Windows sensitivity you use for most games that read Raw Input, but you should not Windows slider higher than 6/11 anyway. Any values below are fine but there is some wonky extrapolation / rounding in the code above that . You can see that in this paint test here:

 

I've always read that, with regards to 6/11 being the most 1:1 etc. while any other value "back in the day" above 6/11 (e.g. 7/11, 9, 10, 11) would and does always feel unusable, it was only at 8/11 which was ok, it essentially felt like 6/11 and a half, so a whole number, wereas the others felt like 1.257 or 1.634, pulling those number out my ass to make a point obviously, but that was the feeling I got when trying to find my sens originally, if that makes any sense at all xD. But yeah my main setting was always at 3/11.
It felt like 6/11 would be as far as the piece of string would be stretched, any over (aside from 8/11) felt like the string was stretched beyond it's capabilities, so had to have the gaps filled in or something. Any under 6/11 felt better than 6/11, almost like the string was being compressed and in turn more accurate. Which is why I was most comfortable on 3/11 1800dpi. I tried going lower to 2/11 and a higher dpi, but I remember that didn't feel right at all.

 

But... all of the usable settings I tried, were consistent. Although I settled on the higher sens due to being a wrist aimer instead of an arm aimer, even those lower sens settings we're consistent.  Nowadays, feels like a form of acceleration or Built-in mouse smoothing. And given that even after ALL THIS TIME they still insist on shipping windows with mouse acceleration enabled by default just goes to show how possible a settings that affects the consistency of the mouse existing is. 

 

I wonder.. with the images you included of the circles, would it be possible to apply my mentioned settings in a similar test to see how the jagged edges look. If they stay the same as 6/11 or if in fact my feelings re correct, and 3/11 with a high dpi like 1800 makes the jagged lines smoother.

I would love to do it myself, but I am not the most technically advanced user. I'm just an aiming juggernaut/ meat-head.

 

 

Anyway I went on a ramble there. My point was when mentioning the 8/11 speed, is that before I could set a dpi of about 800 and it would be controllable to a degree, speed-wise. Not accuracy-wise. Even before at 6/11, 400dpi would be controllable.

Right now, none of the above is true. Including my original settings of 3/11 1800. Wildly faster than it used to be..

 

Scaling is something I've been thinking about too.

 

I remember previously, I was also able to use all scaling %'s (100 being default), and changing those would always impact the mouse in-game as I just mentioned. When making the scaling % higher, I was waaay more accurate in general. I think I used to prefer 125%, but I can't remember. It was either 125 or 150 though. 100 didn't feel accurate enough for FPS to me.

 

But now, 125% feels like it adds more acceleration/ inconsistency compared to 100 (which also feels this way, but 125 setting exaggerates it seemingly), which I believe is due to base scaling already feeling bad with regard to input accuracy.

150 also feels like this, but not as much as 125 for some reason.  

 

So I think this has always been the case, where changing scaling would affect mouse movement. But the problem now is the mouse doesn't feel good at it's base scaling, so when "stretched" for lack of a technical term, only serves to visually exacerbate the issue.

 

 

I really do know how it must look from your perspective.. having to deal with thousands of people, a majority of which (myself included) that have little to no idea on a technical level.

 

What i do, and always will know however, is my co-ordination is and always has been exceptional. 

From grade 8 piano, to bar flair, to tennis (when my body didn't used to hate me so much). All to a high level. I used to train the jr's at the all England lawn tennis club alongside Wardy and a mate of mine for a few years to give you an idea of my standard of co-ordination. 

And trust me when I say, when my mouse worked before, I could feel the shots, not see them.

 

That's only due to repetition and the development of muscle memory.

 

My K/D on ghosts was around the 4.5 mark. That, and titanfall were the last times I was able to feel my shots. Now it's all micro-corrections and whiffing.

 

EDIT: Also I apologise for the text with the eyebelch background, for the life of my I can't see how to have it not do that..

 

Last edit, i swear..: Also i have the source code for the app I previously mentioned I had developed if you'd like it? I was given permission to share from the Microsoft engineer. Cheers

oh and if I wanted to run that circle thing myself as you may not have time, could you eli5 how I can run that script. Sorry. Am doofus.

Edited September 10, 2023 by sqwash

[DPI Wizard]

2 hours ago, sqwash said:

EDIT: Also I apologise for the text with the eyebelch background, for the life of my I can't see how to have it not do that..

When you copy and paste text, either paste with CTRL-SHIFT-V or click  

[KODa]

Mind sharing the app you use to test this?

[sqwash]

I’d gladly, as long as it’s not violating any community rules?

[sqwash]

I suppose if it isn’t allowed it won’t be approved, if it is it will.

 

here’s the link to myself performing the test as well as a download link which I personally converted to a mega link for sharing.

 

 

[sqwash]

20 hours ago, KODa said:

Mind sharing the app you use to test this?

Out of curiosity, how did your results look?

[sqwash]

I just captured a new video highlighting the issue further.

 

 

[TheNoobPolice]

On 10/09/2023 at 19:39, sqwash said:

here’s the link to myself performing the test as well as a download link which I personally converted to a mega link for sharing.

I don't think anyone should run an .exe from a mega link. If it's not open source and linked on Github or similar, and there is nothing particularly interesting about the value of how much the cursor drifted IMO. You can see on the screen how much it drifts after all, you don't need to accumulate the mouse counts via Raw Input to do that, since 1 count = 1 pixel * WPS multiplier you could just check the cursor position before and after. For what it's worth my Razer Orochi v2 mouse on my current mouse pad, drifts up much faster than yours does.

I'd just suggest you stop worrying about this very normal issue with every mouse ever made.

 

[sqwash]

I wish that was an option, sincerely.

 

Thank you for all your help

[sqwash]

One final thing while I've got you. That issue I shared previously with the github link that I referenced.

Is there any way to tell what the fix was for their separate issue, I can see in the hidden items in the middle of the post, shows that putzworks suggested some sort of fix. I am just curious what it was exactly that they had to change in order to get the affect to cease.

 

Thank you once again!

[TheNoobPolice]

1 hour ago, sqwash said:

Is there any way to tell what the fix was for their separate issue, I can see in the hidden items in the middle of the post, shows that putzworks suggested some sort of fix. I am just curious what it was exactly that they had to change in order to get the affect to cease.

Ok, well, skimming the code, the "fix" implemented is a filter that ignores relative deltas of a seemingly arbitrary large value. Effectively a smoothing algorithm.

This has some merit if you don't mind smoothing. It could potentially minimise some kinds of drift because you reduce counts distance outliers and average out the motion (i.e a low-pass filter) but this always adds motion delay (which is not "latency" in terms of an input arriving later to the PC, rather the output is effectively applied a reduced sensitivity as your hand speeds up and increased sensitivity as your hand slows down; like negative accel on speeding up, positive accel on slowing down).

That said the approach is rather cumbersome IMO, a more elegant function for mouse input would be to use something like an exponential moving average (I like Brown's algorithm personally) since it is very simple (read computationally efficient) compared to something like a Kalman filter, and compared to a simple 3 or 4 sample moving average is weighted towards the more recent data which is preferable for real-time input systems (read responsiveness).

This function I just wrote in c++, for example, feels rather nice

typedef struct vec2d {
    double
        x, y;
} in, out;

inline void emaSmooth(vec2d &in, double coeff, double magnitude)  {
    static double EMA = 1;

    EMA = coeff * (magnitude - EMA) + EMA;
    double ratio = EMA / magnitude;
    in = { in.x * ratio, in.y * ratio };
}

vec2d in;
	in = { raw.x, raw.y }; // where the raw [x,y] is a rawinput struct defined elsewhere

vec2d out;
	out = { 0, 0 };

double coefficient = 0.5;  // "1" is no smoothing, increasing towards 0
double distance = sqrt(in.x * in.x + in.y * in.y);
emaSmooth(in, coefficient, distance);

out = { in.x, in.y };

You can see how this tightens up the inputs of my Razer Orochi v2 using MouseTester. This is the raw x-axis input moving the mouse in circles around 5-10 counts/ms. You can see some outlier inputs hitting 15 counts distance or more, and it's rather noisy...



and this is with the above smoothing algorithm with a coefficient of 0.5, which is a lot "nicer" plot...




So it's possible to alleviate some causes of drift by smoothing the input in a manner that makes sense for the kind of input it is, but you will always sacrifice technical accuracy of the true sensor output, and it's unlikely to fix drifts caused by surface variation or other anomalies that tend in a persistent direction. I'm of the opinion that a little mouse smoothing isn't such a bad idea, but you're not going to hear that from the mouse input purists.

[sqwash]

This is extremely interesting! Thank you for taking the time to look in to that.

 

I would very much like to test to see how the function you wrote feels if that’s ok? How would I go about applying this, the realm of coding and scripts are very estranged to me, apologies.

[TheNoobPolice]

11 hours ago, sqwash said:

I would very much like to test to see how the function you wrote feels if that’s ok? How would I go about applying this, the realm of coding and scripts are very estranged to me, apologies.

Not easily. I just quickly added the code in a test build of a driver I contribute to, which requires a development environment (and it isn’t open source anyway).

I’m not aware of any method using windows hooks to block the native mouse input after reading raw input to then send out modified output to the cursor, because the same hook would block the modified output also, so to do this with the cursor would require a kernel driver (to my knowledge) that doesn’t see it’s own output.

I could just build that function into an .exe with a free-to-use signed kernel driver library like Interception, but then my .exe wouldn’t be signed and any anti-virus would probably immediately panic and mistrust it these days.

I’d rather just share the code and anyone who wanted to try it build it themselves locally, which given you don’t code is a bit of a stumbling block.

But it wouldn’t solve your kind of drift fully anyway, and neither does an exact replication of the code you linked before - it just helps mouse they have very noisy distance input feel a little more stable. I’d run MouseTester on your own mouse first to see if it would be any benefit.

[sqwash]

Ah understood no problem at all, and I will hop on mouse tester and share the results. Cheers mate!

[KODa]

On 9/11/2023 at 5:46 PM, sqwash said:

Out of curiosity, how did your results look?

Windows 10, Logitech G Pro Superlight in wireless mode, 1000hz, 800dpi.

 

BTW the cursor drifting upwards or downwards when making side to side motions is how you grip your mouse, if you keep doing perfectly horizontal lines, it wont drift up or down, but we humans tend to make small circular motions and this causes the drift, at least when talking purely left-right motions.

Edited September 13, 2023 by KODa

[TheNoobPolice]

27 minutes ago, KODa said:

BTW the cursor drifting upwards or downwards when making side to side motions is how you grip your mouse, if you keep doing perfectly horizontal lines, it wont drift up or down, but we humans tend to make small circular motions and this causes the drift, at least when talking purely left-right motions.

I’ve seen this said before, but just to note it isn’t true that this is the cause of this. Your wrist does indeed move left to right and back in an arc, but the sensor is fixed in its position in the body of the mouse, so rotates to exactly the same angle made by the arc at all times, so from the sensor’s perspective that can only read delta x and delta y relative to it’s own orientation, it is simply moving horizontally. 

As long as the sensor stays in contact with the surface and isn’t lifted, you could move it around in any mixture of circles or curves and lines and put it back to where it started in the same orientation, and mathematically the cursor would always be back in the same position. The reason it doesn’t work like that is just because the sensor / firmware combination is fundamentally not an accurate technology

 

This test shows a lot of optical sensor drift  even when moved by a machine that keeps the mouse fixed in the same orientation - even the G900 drifts a little and there hasn’t been any major technological reinvention of optical sensor tech since then.

[KODa]

17 minutes ago, TheNoobPolice said:

I’ve seen this said before, but just to note it isn’t true that this is the cause of this. Your wrist does indeed move left to right and back in an arc, but the sensor is fixed in its position in the body of the mouse, so rotates to exactly the same angle made by the arc at all times, so from the sensor’s perspective that can only read delta x and delta y relative to it’s own orientation, it is simply moving horizontally. 

-Snip-

You're correct. It's just that some people miss the human factor in it and others deny modern sensors having any drift, so I guess I was just covering the possibility.

[sqwash]

Noob. You’re the first person I’ve seen say that aside from me. Not because I know any better, because I certainly don't, but because I have felt better.

I got a Reddit bullocking after saying that while mouse sensors are a factor, this shouldn’t be a consistent variable.
while I don’t deny that mice sensors can attribute to drift (from the exact same video you shared and my own experience), I am now currently on my umpteenth mouse, every single one of which has the same “pattern” and direction of drift.

from razer deathadder, naga, viper mini, viper 8k, zowie 4k, steelseries sensei ten, glorious model - o, and multiple more im forgetting I’m sure including just generic Ines, to eliminate the factor of the in-board memory causing a conflict or something.. idk might be dumb but made sense for me to test.

also alongside multiple mousepads. From soft to hard, cloth to plastic and glass. All yielded the same results for me. Currently I’m on the sphex as that was the exact one I used before and I enjoy the glide on it as opposed to cloth which has substantially less glide feel and at times felt restrictive due to pressure applied down on the mouse. More pressure = more drag, obviously.

i also member that I was able to use multiple mice and laptop touchpad as previously mentioned, one of the other mice I used was something that looked like a bot from robot wars. The mad katz c.a.t, when it first came out. Same deal, was able to take it out the box, plug and play with 0 issue and the immediate development of muscle memory.

 

since then I’ve been trying to retrace my footsteps so to speak and attempting to remember/ implement things that may have been a factor.

e.g. Recently I ordered a usb 2.0 header connection to see the effect that has. The reasons are because even when my mouse worked, all of the usb ports barring 2, the top ones (2.0) wouldn’t feel right. They would feel, kind of like how they do now. And I remember in the old rig, there was a usb 2.0 driver, whereas now it’s all handled by xhci 3.1 and root hub 3.0.

also I wanted to see if a different part of the mobo handling usb would solve, which is why I also bought a pcie usb extension to no avail.

Even though my board has 2.0 ports built in, they are not connected via pins like they were in my previous build. Which now they are due to the additional usb slots. While the mouse feels fine and crisp plugged into the new usb header, the issue persists. But then again, are still being handled by the 3.1 so didn’t manage to fully test what I wanted, but seems redundant at this point to continue down that avenue, due to some people having the issue and not. One of the people I’ve liaised with doesn’t have the drift, has correct RawMouseInputAccumulator tester readings but is also using the same driver set I.e. 3.0/3.1 to handle their usb devices, so seems unlikely that is a culprit.

 

There could be other variables, like back in the day I remember lots of people had issues, myself included, with Realtek audio driver affecting mouse movement and response. That one took a while to diagnose, but once the driver was replaced fixed the issue completely.

 

 

 

Edited September 13, 2023 by sqwash