I have a GPro and recently bought a Viper 8k. PS2 plays well with the GPro, but for the Viper 8k, there is a peculiar lag only in PS2. When moving the 8k slowly in PS2, it tracks perfectly, but if it is moved too fast the in-game response slows down significantly until you finish moving, at which point it quickly jumps to the rotation you'd expect based on how far you moved the mouse. I have confirmed it is not a mousepad tracking issue because the same does not happen in windows or in other games. I believe the issue is that the Viper 8k is capable of overloading PS2's windows event catching/processing loop with too many mouse updates, and then those updates are buffered, and when the mouse stops moving the buffered events are quickly processed. I am reporting this issue because it is likely that other mice manufacturers will release higher polling rate mice in the future, and if my guess for what is going on is true, this bug will effect all of those high performance mice also. For reference, almost all mice poll at 1000 hz currently, but the Viper 8k has a 8000 hz polling rate, or 8x as many windows events. My hardware: Razer Viper 8Khz Ryzen 3600 Vega 56 24 GB RAM 1 TB SSD
Same issue as this Reddit thread: High polling rate mouse issue Happens on my G203 Progidy and Razer Viper 8K. I have to lower my polling rate to <1kHz to fix it. Maybe this is relevant too: Got a problem with mouse polling rate on ps2
This is not a planetside issue, it'a a Razer issue. They are dumbasses. They put hardware together that will do a 8Khz polling rate. There is a hardware interrupt 8000 times a second. So call to the interrupt dispatch table at a high IRQL 8000 times a second. The driver is going to have to APC or possibly DPC to handle this. If they want to keep the true 8k throughout the pipe it can't batch these together. So yeah. 8000 interrupts and THEN we have to get it handled in passive mode at IRQL 0. And each and every one has to go through a windows driver as well as any that razer did, and god help you if there is something else in the IRP stack that wants a shot at the data before it finishes. It's a recipe for a !#$ disaster and they should have never sold a product this way. That Windows, let alone some game, actually handles this properly at 8khz is a lie. And if by some miracle it did work, it would just make performance ******. Remember, NOTHING gets done on a core if a thread is running at DPC IRQL or above. No multitasking, no preempting, the scheduler itself doesn't even run. Set it at 1Khz and be done with it. EDIT: PS I have the same mouse. It's literally putting inputs into a queue at 8khz then pulling them out of the queue at the rate that Windows finishes the processing which is well below. The input rate to this queue has no impact on the output rate. Lots of input and actions won't happen faster, they'll just queue up.
I'm having the same issue, with a Logitech G502 Lightspeed. Interestingly, this mouse "only" goes up to 1000Hz, and for the most part it's fine, but for some unknown reason, when I was given an account to play on Jaeger a few times over late 2022, I had the issue you describe, when I had my mouse set to 1000Hz in the Logitech software. I never figured out why (CPU usage is fine, tried with the mouse wired or wireless, different USB ports, made sure USB settings were fine in my computer's BIOS…), and just dealt with it, until I found out it was related to the polling rate, at that point I lowered it to 500Hz on Jaeger. But for some reason, since pretty much today, I've started to have that issue regardless of the server or account I play on (I find it weird that it would be related to an account or server in the first place, but whatever). The fix of setting my mouse to 500Hz is easy, but I'd rather have the full extent of what it can do, especially since 1000Hz isn't exactly uncommon on gaming mice today, this mouse itself is 4 years old now (and in fact barely holding on lol)
