[Linux] Keyboard controls mostly non-functional if the game was started in a non-US layout

rkfg · September 2018

This is not a critical but still annoying bug I hit from time to time. The new windows in my setup inherit the active window keyboard layout. I use the US and Russian layouts. Sometimes I write something in Russian in Steam, like a comment or a review, then start NS2 while the active layout is RU. It's quite hard to notice that all alphabet keys don't work until I get in the game and all I can do is look around and jump with Space, maybe change weapons with numbers. WASD and other keys around don't work at all, no matter if I switch layout back to US or not. I can type in the in-game console just fine but controlling the player is impossible. The only way to fix this is to exit the game, switch the layout to US and then launch it again. Probably something to do with the game receiving wrong key codes but I wonder why changing the layout doesn't affect that.

I have the system locale set to en_GB.UTF-8 (not en_US because I prefer 24h clock, not AM/PM, otherwise these locales don't differ much) as quite enough games have various issues when run in other than US/GB locale.

mock · September 2018

Have you tried to changing startup properties of NS2 in steam?

LC_ALL=en-GB.UTF-8 %command%

should change the locale the game runs in.

rkfg · September 2018

I explicitly stated that my system locale is en_GB.UTF-8, it's like that for all processes because indeed non-ASCII locales are often troublesome in many Linux games. But my problem is not locale but keyboard layout which is switched independently.

rkfg · November 2018

So I made a workaround script that at least prevents running the game in the non-english layout.

#!/bin/sh

setxkbmap us
while xset -q | grep -q "Group 2:\s*on"
do
  sleep 0.1
done
setxkbmap us,ru
CMD="$1"
shift
"$CMD" "$@"

It sets a US layout and then constantly checks if it has been switched. It looks like setxkbmap works asynchronously so the actual layout change happens a bit after the command exits. Then it sets the original layouts (in my case it's US and Russian), grabs the command from the arguments and starts the game. To use it I set this to the NS2 launch options:

/path/to/script %command%

Now, there's a catch, at least on my system. The layout doesn't change if there were no buttons pressed at that moment. That's very weird but I did some experiments and for example this changes layout to US:

setxkbmap us; sleep 0.5; setxkbmap us,ru

while this does not:

sleep 0.5; setxkbmap us; setxkbmap us,ru

Any code with "sleep" smells and I hate it. But this seems like a bug or not well defined behavior, at least when using this utility. Still, better than nothing. So the catch is that Steam does exactly this, a delay before launch so the script doesn't work as expected. The game seems to be stuck in "Running" but nothing actually appears. Just press any key (like Ctrl or Alt) and it should launch. If the layout was US before launching it starts immeditately.

When the game is run in Russian layout, the keybindings don't work but I can get into settings and rebind them. This is what WASD looks like:

And no, switching layout while in game doesn't help (I can enter both cyrillic and latin in the in-game console switching layouts), the bindings still show codes instead of characters. And of course, after relaunching the game in the US layout I have to rebind the keys back to WASD for them to work.

[Linux] Keyboard controls mostly non-functional if the game was started in a non-US layout

Comments