Halflife: CS 1.6 Linux: mwheelup and mwheeldown trigger mouse4 and mouse5

[longboardtard]

In my Counter Strike 1.6 client configuration file I have the following binds:

bind MWHEELDOWN +jump
bind MWHEELUP +duck
bind MOUSE4 +use
bind MOUSE5 stopsound

Whenever I bunny jump using MWHEELDOWN, my sound stops briefly each time I scroll (MOUSE5 is being triggered). Similarly, whenever I use MWHEELUP to hop faster into ledges (I practice KZ), I hear the sound that +use produces (triggers MOUSE4). In both cases I am absolutely not pressing MOUSE4 or MOUSE5, but their respective codes are being sent along each time I scroll.

I asked in #xorg@freenode and I got this tip:

when mouse wheels first started appearing, mice never had more than three buttons, so mousewheel up/down defaulted to emitting Button4 and Button5 so apps would have something to listen for
so what you want is to configure your mouse so those buttons are button6 / button7

So this appears to be 100% Xorg's fault instead of an engine issue. But bear in mind that given the fact that the engine IS being affected by Xorg "somehow", implementing some sort of fix engine side should be mandatory.

The suggestion from the guy at IRC can be achieved using the xmodmap tool. However I think it is needless to say that this shouldn't be the way to fix this. This is buggy behavior that could probably be very easy to fix in the engine itself. But also, it turns out that using xmodmap doesn't work in this case. It seems Counter-Strike gets its input at a lower level than what xmodmap is capable of affecting, because I tried all sorts of xmodmap -e pointer remappings for the mousewheel and they didn't work. Scrolling still sent these other codes somehow.

Anyway related to this, Xorg has support for up to 14 mouse buttons. I own a Zowie EC1 eVo mouse, and this is the equivalence table between Xorg and Half-Life engines' naming of mouse buttons for my mouse (Bear in mind, I'm using the mouse driver instead of evdev). I got these button names using xev.

Button1 = MOUSE1
Button2 = MOUSE3
Button3 = MOUSE2
Button4 = MWHEELUP
Button5 = MWHEELDOWN
Button8 = MOUSE4
Button9 = MOUSE5

I'm about to try the evdev driver... maybe it solves the issue entirely.

EDIT: It didn't. Same befavior with evdev. I attached my custom xorg config in case somebody wants to take a look and suggest changes to it. I run everything on a secondary X session that I initialize via xinit /usr/bin/jwm -f ~/.jwmrc -- :1 -xf86config ~/xorg.gaming.conf

xorg.gaming.txt

[YaLTeR]

It's a bug in SDL that was fixed in I believe SDL 2.0.4. You can use that instead of the one that comes with Half-Life.

[longboardtard]

No. I use archlinux, and the SDL package I currently have is at version 1.2.15-7, so you are probably talking about the SDL2 package. That one is at 2.0.4-2, and I've also tested a backport to version 2.0.3-3, and I still have the exact same problem with both. So unless you want to be more specific, or provide more information on how you know that this is in fact a bug in SDL... this is still a pending problem.

[YaLTeR]

I know that it's a bug because I submitted it to the SDL2 bug tracker and then tested the fix myself afterwards: https://bugzilla.libsdl.org/show_bug.cgi?id=2987. The SDL2 that you have installed doesn't matter because HL uses its own version from its installation directory (you can try loading the one you have installed by overriding the library path if I'm not mistaken).

[longboardtard]

I always run steam with STEAM_RUNTIME=0. I don't know if that will be enough for steam to use the system's SDL2 library. If it is, then the bug is still present. If it isn't, then steam is still using its embedded SDL2 library regardless of STEAM_RUNTIME=0.

[YaLTeR]

Looking at how SDL2 is in the Half-Life folder rather than the Steam folder I'd say it's unaffected by STEAM_RUNTIME, although I'm not sure. Just get the lib32 version of the new SDL2 and launch HL with a custom LD_LIBRARY_PATH to load that instead.

[longboardtard]

It works, but the newer sdl2 library produces a slower sensitiity than the original sdl2 library shipped with steam. It is not placebo, it is very noticeable. In a sense it produces a very similar sensitivity to the one in Windows. I was already used to the higher sens from the original lib so I measured that sensitivity with a ruler and anchor points in my mousepad. I then launched cs with the newer library and increased the sensitivity all the way up to the point that my crosshair could travel the same distance (always same mousepad distance) as it does using the buggy library that steam ships. Results:

Buggy steam sdl2 library: sensitivity 2
Fixed sdl2 system library: sensitivity 4

So it halved my sensitivity. Will one day things be consistent? I don't know.

Anyway I launch the game using the following command, it may be useful to some other people too.
Advice: forget about the cpu hog that pulseaudio is... it's great for apps but terrible for games.

pasuspender -- schedtool -v -I -e env LD_PRELOAD=/usr/lib32/libSDL2.so SDL_AUDIODRIVER=alsa ./hl.sh -steam -game cstrike -nomsaa -32bpp -full +cl_mousegrab 2 +exec mysettings.cfg +connect 127.0.0.1:27016

Just make sure you setup your preferred card as default in ~/.asoundrc

To YaLTeR: Thanks for your help man, I really appreciate it.

[YaLTeR]

Pretty sure the double sensitivity was a bug in SDL as well, it was receiving all mouse events twice or something. Great that you got it working.

[todorvelichkov]

@YaLTeR I have the same issue on Ubuntu 18.04 running steam normally (STEAM_RUNTIME=1). Any idea how to apply this fix? Is it possible with a custom launch option for counter strike only?

[YaLTeR]

You can LD_PRELOAD a newer SDL2, or maybe just symlink it instead of the one in the Half-Life folder.

[todorvelichkov]

The thing is that I'm not sure how to LD_PRELOAD a newer SDL2.
So I went with the symlink approach since it look easier to me. However I got it fixed in a strange way.

I had two files in the Half-Life folder

~/.steam/steam/steamapps/common/Half-Life/libSDL2-2.0.so.0
~/.steam/steam/steamapps/common/Half-Life/libSDL2.so -> libSDL2-2.0.so.0

so I just renamed the libSDL2-2.0.so.0 to libSDL2-2.0.so.0.old. I run the game to see if its gonna crash, but for my surprise, the problem was fixed.

[YaLTeR]

I guess it just didn't find the game SDL and used the system one.