Closed 9ary closed 9 years ago
This is by design. Older mice (probably all but the very latest. But who knows?) needed this delay. For some mice it even resulted in a firmware corruption and thus a physically broken mouse, if the delay was omitted. So this will not change. If you want to get rid of it in your private copy, see hw_deathadder*.c and remove the delays. But be aware that this might brick your mouse.
Thanks for the information. I'll see if I dare to change it, but for now I need to work out other issues (games grabbing the mouse at the driver level resulting in my script not triggering).
Two mice have been hurt in the process of debugging that issue, btw. A user's mouse, who reported it. And my mouse, as I tried to fix it :)
I'm pretty sure that most mice don't have that issue. But it's almost impossible to find out which ones are the buggy ones without detailed information about firmware changes. So the driver tries to be on the safe side and does not risk user's hardware.
That's perfectly understandable, similar issue to overclocking, etc.
But if that's the case then Synapse might have the same problem, I hope for Razer that it's not the case. :)
I just made a script bound to the thumb buttons of my da2013, to shift profiles so that I can change the resolution of the mouse while in-game, but both razercfg and qrazercfg have a disturbing window (a few tenths of a second) when changing the profile during which the mouse becomes unusable. Synapse doesn't have this issue.
I'm interested in helping with debugging this problem but I've never played with libusb so I have no idea where I could look.
I just realized that the delay is caused by the mouse resetting (and the input device reconnecting) when changing settings. I hope it's possible to do it another way.