>1000Hz mouse polling rate causes horrible acceleration feeling.

[MichaelDeets]

Steps to reproduce the issue:

1. Set your mouse to something (2000-8000Hz) higher than 1000Hz (eg. Razer Viper 8KHz, confirmed rate by evhz)
2. Run CS:GO on Linux (not through Proton/WINE)
3. Keep m_rawinput set to "1"
4. Join any game and experience horrible unusable/unplayable mouse movement

Additional Information:

• Using anything (2000-8000Hz) higher than 1000Hz mouse polling creates a horrible acceleration type feeling, where slow movements are practically unregistered and only moderate-to-fast (what I assume is fully saturating the 8000Hz polling) movements feel "normal".

• m_rawinput "0" has no problem with >1000Hz, though it randomly moves the crosshair to the right every few minutes, and is about 1.1x slower than m_rawinput "1"

• CS under Proton/WINE has no problem with >1000Hz whatsoever. VAC has to be disabled to start the game, unless I run the entire Steam client through Proton/WINE,

• -vulkan changes nothing.

• flatpak (with or without -vulkan) changes nothing. It doesn't require me to rename tcmalloc_minimal.so.0 to start with -vulkan.

System info:

• https://gist.github.com/MichaelDeets/61b523a85e162081f38ef1c4566dd64e

Mouse information:

• Razer Viper 8KHz, 1600 DPI
• evhz reports a stable 8000Hz

[MichaelDeets]

https://youtu.be/2QxPZsp8Q7Y?t=7

I'm using the Viper at 8KHz in the video, the same applies to lower polling rates but it is slightly less noticeable.

The left and right swipes are going the same distance (45cm), only swipes to the left being of a much slower speed, and swipes to the right being much faster.

It is most obvious when doing anything that requires precision, such as spraying or trying to shoot someone long range.

[romanstingler]

@MichaelDeets but in the DE(desktop environment) the mouse movement is ok?

For me, I use my razer basilisk v3 with 26k DPI, there was no chance to set the correct mouse sensitivity in gnome. I had to add a hwdb entry myself. You could try that too.

1. lsusb and search for the line with your mouse Bus 001 Device 005: ID 1532:0099 Razer USA, Ltd Razer Basilisk V3
2. create a file like in the following example (but with your device id)

cat /etc/udev/hwdb.d/71-mouse.hwdb 
mouse:usb:v1532p0099:*
 MOUSE_DPI=*26000@1000 6400@1000 3200@1000

You need just 1 entry (the one with the * is the default, if you change settings here I would recommend rebooting) just use MOUSE_DPI=*DPI@Polling Rate e.g MOUSE_DPI=*400@8000

3. sudo udevadm hwdb --update
4. sudo udevadm trigger /dev/input/event*
5. just in case reboot :)

please let me updated if this worked out

[MichaelDeets]

Replying to https://github.com/ValveSoftware/csgo-osx-linux/issues/2906#issuecomment-1000862775

The mouse movement is fine outside of CS at 8KHz. 8000Hz also works inside of CS under some circumstances (m_rawinput 0, through Proton/WINE).

I use openrazer and polychromatic to change settings, you can change polling rate and DPI there too.

"MOUSE_DPI" seems to be related to libinput. I'm using pure evdev without libinput, but thanks for the suggestions.

[parov0z]

usbhid driver does not support polling rate higher than 1000Hz https://wiki.archlinux.org/title/mouse_polling_rate#Polling_rate_and_polling_interval

[romanstingler]

@ANDRoid7890 it is not listed in the wiki but apparently the usb drivers support 8kHz https://github.com/openrazer/openrazer/issues/1426 -> here you can see that with evhz 8kHz are recognized.

[MichaelDeets]

usbhid driver does not support polling rate higher than 1000Hz https://wiki.archlinux.org/title/mouse_polling_rate#Polling_rate_and_polling_interval

It definitely does. Also used openrazer and evhz to confirm.

[GD-gh]

Same issue here. Using Razer Viper 8KHz, evhz confirms average 8035 hz polling rate. When polling rate is configured to 1000Hz through openrazer and razer-cli, mouse movement doesn't show any weird acceleration. DE is DWM with no compositor, using libinput. Please fix!

[robertswiecki]

usbhid driver does not support polling rate higher than 1000Hz

TL;DR It's probably more related to xinput/xorg/xwayland than to csgo. Use SDL_VIDEODRIVER=wayland to make it work at >2kHz, and make sure you're using Gnome >= 41, 42 is probably even better. The event-freq tool (link below, compile on your own) will tell you the truth.

USB2 has capability of using 125us frames, so maximum polling is 8000Hz. Linux's hid definitely supports that.

But somewhere above 2kHz (I use ASUS ROG Chakram X) things go south.

It's not only CS:GO, but the whole xinput/libinput/gnome-shell starts choking - it's visible with eg. the evhz (it's probably terminal/Xorg problem, and not evhz itself) or with the event-freq.c tool, where with 4kHz and 8kHz something is dropping events and it even affects the whole UI (slowness of gfx updates)

PS1: Under the VT console evhz works well, so it's more gfx/UI/Xorg/terminal-emulator problem, than evhz problem.

PS2: It only happens under Xorg (Gnome-Flashback/Metacity and Gnome/Mutter/Xorg), under Gnome/Wayland both evhz and event-freq behave normally. Still csgo has problems - maybe it's because of xwayland? Worth checking with SDL_VIDEODRIVER=wayland

PS3: Yup, with SDL_VIDEODRIVER=wayland there's no more choking/acceleration at 8kHz, but for that you need to replace the standard libSDL lib delivered with csgo, to a one which has wayland videodriver compiled in. Also, you need to use Gnome 41 or 42, because before that the mouse events were aggregated at 60 or 120 or 240Hz (i.e. whatever your monitor refresh rate is). Check with event-freq if in doubt (you'll have to compile it on your own). Use evhz to only confirm what your mouse sends to the usb controller, use event-freq to see what the apps will see via APIs like xinput or wayland.

PS4: CSGO devs, please compile in wayland support into libSDL bundled with the game

PS5: Setting m_rawinput 1 doesn't automatically make csgo use libinput directly (I guess, mostly b/c of device permission problems, which gnome-shell or Xorg hides from you, secondly because csgo uses libSDL and doesn't deal with OS itself), so using evhz will not show the whole truth (it'll just use libinput). The csgo (via libSDL) will still use xinput or whatever wayland/gnome-shell protocol offers, it will just try to avoid acceleration settings in those interfaces via some libSDL API.

[MichaelDeets]

Replying to https://github.com/ValveSoftware/csgo-osx-linux/issues/2906#issuecomment-1153172096

Interesting observations! I already force my own "steam-native" (which uses the system libsdl2, as shown in the logs from starting Steam), but unfortunately I've just moved away from Wayland.

I did actually try launching CS:GO with SDL_VIDEODRIVER=wayland (purpose unrelated to >1KHz mouse polling), and found unexpected results (wouldn't launch with certain configurations). I've also switched back to using a 1KHz mouse, and haven't attempted to use 8KHz in a few months (when I did use, I just used m_rawinput 0).

I still have my Viper 8KHz, so at some point I will test your workarounds and edit this comment. Thanks again.

[kodatarule]

Did a few tests as I finally switched to using wayland on my NVIDIA gpu. Indeed running the game with SDL for wayland resolves the mouse issue completely!

LD_PRELOAD="/usr/lib/libSDL2-2.0.so:/usr/lib32/libSDL2-2.0.so" SDL_VIDEODRIVER=wayland %command%

That is the required command to make it run as the SDL that's shipped with CS GO is outdated and won't work. Now this might be more of an NVIDIA issue, but have to run the game under vulkan(with -vulkan) in order for it to run. The game experiences some corruption due to wayland lacking explicit sync at this very moment which NVIDIA uses, but from what I saw it'll be patched in soon. By corruption I mean the mouse movement doesn't feel smooth and has this a bit going forward/backwards stuff which is normal for nvidia under wayland atm.

EDIT: Digging a bit deeper it seems like the real problem with this game is rawinput, it makes the mouse quite jittery even with native wayland, once that option is turned off there's no issue with xorg/xwayland/native wayland(but on native wayland mouse goes unfocused with raw input disabled)

[MichaelDeets]

Needed to reopen to find out if someone else can confirm this issue has been resolved; I have only tested on my setup, and I couldn't find any specific commit which is related between the latest release and now (only glanced over).

Quick steps on resolving the issue:

1: Download/build the latest git version of libSDL2 2: Use the LD_PRELOAD environment variable to override the built-in libraries (whereis "libSDL2-2.0.so.0", or local directory)

I would recommend editing the csgo.sh file and adding envvars there, as these will persist between accounts; you could use Steam's launch options on CS:GO's properties directly, just append %command% after any envvars and before any regular launch options.

[catsgomoo]

I can confirm this issue does still happen with the Viper Mini SE at 8k polling rate. Using the command LD_PRELOAD="/usr/lib/libSDL2-2.0.so:/usr/lib32/libSDL2-2.0.so" fixes the issue. For me the updated SDL was already included in my distro so all I had to do was use the above command to override CSGOs.

[robertswiecki]

It should work well if you use wayland - the xinput (both native Xorg and Xwayland) protocol seems to have serious problems with polling >>1kHz

It seems that the modern libSDL uses SDL_VIDEO_DRIVER instead of SDL_VIDEODRIVER. My cmdline just in case

MESA_VK_WSI_PRESENT_MODE=immediate DISPLAY= SDL_VIDEO_DRIVER=wayland SDL_VIDEO_WAYLAND_ALLOW_LIBDECOR=0 %command% -novid -nojoy -vulkan +exec my

[crwn1337]

Launch options: LD_PRELOAD="/usr/lib/libSDL2.so /usr/lib32/libSDL2.so" SDL_VIDEODRIVER=wayland %command% +exec autoexec -vulkan

Doing this works ~50% of the time, the game will sometimes randomly shut down with: err: D3D9SwapChainEx: Failed to recreate swap chain when I start moving my mouse.

But what's interesting is, if I move my cursor while the game is starting, it will ALWAYS crash with the swap chain error, if i remove the preload and sdl video driver variables, it has never crashed.

You can try settings your polling rate to a really small value (less than 1khz, even) launch the game, load into a map, move and look around for 5~10 seconds and change it back to 8khz, this has never crashed for me, but its annoying having to do this every time you launch the game, so i'll just stick to 1khz.

[robertswiecki]

Please try with

SDL_VIDEODRIVER=wayland SDL_VIDEO_DRIVER=wayland

The newer libSDL version changed the naming of the hint. For a good measure you can even

DISPLAY= SDL_VIDEODRIVER=wayland SDL_VIDEO_DRIVER=wayland

[crwn1337]

SDL_VIDEO_DRIVER does not seem to be a thing on latest sdl2-git

[crwn@arch ~]$ strings /usr/lib/libSDL2.so | grep SDL_VIDEO_DRIVER
<nothing>
[crwn@arch ~]$ strings /usr/lib/libSDL2.so | grep SDL_VIDEODRIVER
SDL_VIDEODRIVER

I still tried it just in case but the output was no different.

[robertswiecki]

Ah.. it seems it will be default name in SDL3, my bad

$ grep -r SDL_VIDEO_DR . | grep '"' | grep hint
./include/SDL3/SDL_hints.h:#define SDL_HINT_VIDEO_DRIVER "SDL_VIDEO_DRIVER"
$ grep -r SDL_VIDEODRIVER .
./docs/README-migration.md:* Renamed environment variables SDL_VIDEODRIVER and SDL_AUDIODRIVER to SDL_VIDEO_DRIVER and SDL_AUDIO_DRIVER

[crwn1337]

I figured out what launch options worked for me (while using wayland, and sdl2-git) LD_PRELOAD="/usr/lib/libSDL2.so" %command% -vulkan You have to enable raw input as well because otherwise the input will still be "jumpy" It looks like trying to use SDL_VIDEODRIVER=wayland was the cause of problems for me.

[zovt]

Just wanted to add a data point. This bug is still present, using Debian 12. Building the latest git version of SDL2 fixes the mouse issue, but breaks audio and also prevents me from running the game at my desired resolution (it seems like the game isn't detecting my singular monitor, but is instead trying to span both of my monitors. This doesn't happen using when using the included SDL2). I'm also using X11 with i3, no compositor.

I also tried setting the polling rate on my mouse to <1khz using openrazer (it's possible that this didn't actually apply on a hardware level, unsure), but didn't notice any difference.

I also tried disabling raw input but occasionally my aim would just stop even though I was moving my mouse.

Not sure if this is possible to fix, but the game is more or less unplayable with this. Happy to provide any additional logs / information if that would be helpful in getting this sorted! Hopefully CS2 doesn't have these issues :)

EDIT: Using the hardware toggle on the mouse to set the polling rate to 1000 fixes the issue! I'm using a Razer DeathAdder V3 for reference

[MichaelDeets]

Replying to https://github.com/ValveSoftware/csgo-osx-linux/issues/2906#issuecomment-1714681720

Thanks for this comment, I have a similar setup to yours and experienced similar problems.

I'm using bspwm with no compistor and I have a DAv3 wired at 8KHz, to mitigate the monitor/res problem, I simply turn off the second monitor using the xrandr command; put inside csgo.sh as the first thing that's run.

After the game has started, I can turn my secondary monitor back on, and the settings will persist and not try to switch back, or force an extremely strange resolution based on both monitors, where in -vulkan you don't have other resolutions presets and can only use the desktop resolution.

Not related, but for reference I place: LD_PRELOAD="/usr/lib64/libSDL2-2.0.so.0" and xrandr --output HDMI-1 --off inside csgo.sh, with another xrandr command at the bottom after the game is closed, which turns the monitor back on.

[kodatarule]

This seems resolved for both xorg and wayland in CS2 now.

[kisak-valve]

Closing per the last comment.