sqwash

So suddenly a group of separate individuals begin experiencing an issue which is entirely identical to mine and others currently, which is then confirmed by devs and most importantly, fixed. And your conclusion is they all don’t know how mice work? multiple merged GitHub reports describing not a similar issue to mine, but an identical one as seen; https://github.com/symless/synergy-core/issues/5291 https://github.com/symless/synergy-core/issues/5648 https://github.com/symless/synergy-core/issues/5607 im sorry, I don’t doubt your experience, but given the facts that prognosis is extremely far fetched and dismissive. how things currently work and how things SHOULD and USED TO work are 2 entirely different things I’m afraid, and given the evidence and repeated testimonies from multiple individuals, clearly show that something isn’t working as it used to or should. regardless I will continue searching for the solution to this glaring bug, thanks for your opinions.

Ok, pardon the poor wording on my part. my point being, all those people noticed a change from the norm, which was acknowledged and addressed.

Hi again, it’s been a while but I just wanted to follow up with an obvious question I didn’t ask regarding the GitHub post from putz and the mouse behaviour. if this behaviour is actually working as intended, then why was that post firstly accepted as an issue, and secondly subsequently resolved? A fix shouldn’t have to be rolled out for something which isn’t broken, right? if that drift in motion was actually intended behaviour, surely all the people that confirmed that is was a new issue for them following an update would have been simply told that that is how mice actually function as opposed to being accepted as an issue? Doesnt that highlight the fact that it is indeed an issue and not working as intended by that threads progression alone? also happy holidays!

Yikes, seems like a pretty big oversight that should have been caught in the QA phase. Thanks for the info!

Understood. Just to clarify, you recommend using a mouse software’s surface tuning as opposed to the OOBE/ no configuration in general? nice one!

"If the cursor moves the same distance on the screen as it does on the pad day to day then the variable is you, not the mouse." How about if it doesn't, what would be the/some of the reasons as to why physical mouse distance isn't being mirrored on the display just out of curiosity? Has there been any well knows reasons or causal factors, or is this no-mans land?

That sens perception thing you said you get, 100% agree with and get that too. I got into the habit of forcing myself to not change sens after a nights sleep and a fresh days boot. There’s a “warm-up” period which even with highly developed.. ‘Voldemort’ feels unnatural. Also, friends never let friends drink and DPI. Never change sens after a laphroaig or 2, the next day is usually a “wtf was I doing” fest. Anywho with regard to the sens changing, the order I like to do it is by firstly finding what feels nice on the desktop as I believe there’s the whole bleed over thing with windows sens and scaling etc. but once locked in on the desktop with windows sens, dpi, polling etc. I then would head into a game and use its test area to get in game sens right. Which for me would be only a baseline setting, as aim in training grounds and an actual game tend to always differ. The comment you made with the off screen 180s, do you mean when on desktop screen or in-game? Because if in game, I used to be able to pull of those 180 snaps by feeling, but now it varies to such an incredible degree, it just isn’t consistent in the slightest. It’s feels like something is fighting against the movement. If I had to describe it better, it would be like the movement you would get on a mouse that was using an emulator for a console, like the xim. Not like “true” mouse response. Just like there’s some sort of acceleration/ negative acceleration, v-synchy drag. Or do you mean the physical mouse itself feeling consistent when you move your hand? in which case, yeah totally got you there! That sens scaling slider depending on day sounds interesting, will that be a direct modification on the windows end or a middle man type of deal which works in conjunction with windows sens, if I’m even understanding correctly. Regardless, will be keen to test that out if and when becomes available to do so! Also, I know we’re back to me using the feelings word again and I’m sorry, but this one is more of a sidebar. When scaling modes are changed within say, nvcp, between aspect, full and none, why do they feel so different from eachother, despite nothing visually changing on screen? Even when mouse was fine this would happen, I’m just curious as to why?

If I were to backshelf the drifting for now due to your advice, I’d still like to tackle why the mouse feels so different now than it did before. So another feeling I get when using the mouse, is that it isn’t as responsive as it way. Like it is ever so slightly de-synced. on most of the videos I’ve made for the (backshelved) drift, you can kind of see that the cursor and the mouse aren’t moving together, as in you can see the mouses position slightly ahead of the on-screen cursor, and that’s how it feels too. It used to feel more responsive and general and snappy. also with regard to the mouse tester app, what are its limitations if any? Because I feel a MAJOR difference between usb 2 and 3 ports, always have. But when measuring the plots of both ports they show equal path consistencies, despite feeling so drastically different. thanks again in advance mate.

Hey mate, thanks for explaining that to me. I’ve experienced the 8k polling woes first hand. When liasing with the input dude, was also informed that the undesired effect from 8k was due to a spam of raw input requests from certain processes/ apps? (Paraphrasing off the top of my head there) I observed that behaviour when certain apps were opened in conjunction with other certain apps. here’s an example of that with overwatch and discord. When discord opened, 8k became unusable.

I’ll also be creating another quick video, alternating between 250 and 1000 polling to show the clear visible difference between the two plots in mousetester. just wondering what the scientific explanation for that difference is?

Howdy, sorry went away to the coast for a couple of days to enjoy the last of the sun. Thank you once again for all that info. Could I ask, is it well documented that USB 3 is worse for mouse than USB 2? And is it possible in even the slightest, that using a 3.0 driver to handle 2.0 ports is causing some issues? Also, what is the reason for 1k polling being worse than 250?

So this could be interesting, from what I can tell when using the Mousetester app my feelings regarding 1000hz polling might be right? Remember I said that even when my mouse functioned correctly 1k polling didn't feel right (almost like there was added drag on the Y axis only) and that I always preferred high sens with 250/500 polling. Well, I swapped mice out recently from the 8k viper, for 2 reasons. 1, I keep hitting the ambidextrous thumb mouse buttons by accident and also because the polling range is limited from 125, 500 and 1k+ etc.. 500 felt the best, while (when it didn't cause camera panning stutters) 8k looked the best. In the regard that it translated well into my 240hz monitor and appeared to make panning and frames present like butter. Probably technically unsound terms for what I'm trying to convey, but I'll stand by my mess and own it, when 8k works it's looks visually amazing. Still doesn't feel as good as 250/500 to me though. Anyway, I swapped out the viper for a mouse with the option of 250hz poll, as that and 500 always felt better. worth nothing that 125 always felt bad, in the sense that panning and frames would seemingly stutter as they still do. The mouse is steel series prime, while I don't enjoy the way this mouse feels in my hand, I prefer the option of the 250 poll. Here's a video I made opening the app, testing it out quickly and then towards the end changing between 250hz and 1000hz polling to test. It looks like on 1k there are dots outside the range of the curve, whereas my 250 poll shows none. Don't put it past me that I've done everything right here, there may very well be user error as I'm not really familiar with the app not am that smart in general. If there are any other settings I need to apply, change or anything with the test itself I need to do different or have done wrong entirely please let me know so I can amend!

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.

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

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.