[linux] esc key not working

[voidplayer]

I use this to swap esc and caps lock keys:

setxkbmap -rules evdev -model evdev -layout us -variant altgr-intl -option caps:swapescape

some (non-source) games recognize the swapped key. Others dont but respect the old esc key.

in CS:GO neither work (neither esc nor swapped caps lock key).

Its pretty similar to other source games. Either respect my swapped key or dont... but make one of them work (preferably, respect my swapped key) :)

Thanks

[ml-]

I can confirm. Xkb Option: caps:swapescape "Escape" seems to be hardcoded and is not bindable to any other key. It works in Counter-Strike: Source even though it doesn't recognize the switched keys and opens the menu + toggles capslock when hitting the Esc-Key.

CS:GO seems to ignore both Esc/Capslock keys, which brings huge limitations since most UIs are not usable without Escape

[benwaffle]

I have the same problem. Should be reproducable if you install gnome-tweak-tool, run it > typing > caps lock > swap esc and caps lock.

[ml-]

Until now I've been using a bash function to quickly swap caps and escape before starting the game but I actually noticed that I don't need the CapsLock Key at all.

So guys, do yourself a favor and use caps:escape instead of ~~caps:swapescape~~

[Tele42]

LibSDL2 has provisions to get keyboard input by keycode or scancode. While keycodes should respect xkb remapping, it does not handle international keyboards as well as using scancodes.

I believe CS:GO is using scancodes, but I need a valve dev to confirm. Can a dev confirm which input method is used and decide if CS:GO will support xkb remapping?

[h1nk]

Almost 6 years and this hasn't been addressed whatsoever. My escape key on my keyboard is physically broken and I already use caps lock for other stuff so simply setxkbmap -optioning caps to escape is not an option. I've xmodmap'ed menu to escape because of my broken keyboard key and this has worked on every single application I've ever used, all but Source Engine of course. xdotool is extremely buggy when in a fullscreen game window so that's not a solution, no such X11 option for menu:escape exists so that's not a solution and finally "cancelselect" is un-keybindable for no apparent reason so that's not a solution. So I'm just stuck unable to even do anything basically.

[ruifm]

Can this be addressed or at least a workarround? At least make cancelselect actually bindable to other keys...

[SeerLite]

+1 for this. Came back to the game after some years to see if this was resolved. I see it's not the case, disappointing.

[sergio97]

+1 I can't trigger cancelselect at all which is quite annoying. As a workaround I start calling a vote (F5) and then cancel, which is equivalent to pressing escape.

[iBurley]

Having the same issue. I use the GNOME desktop and I've used a gsettings command to put control on caps lock and it doesn't register in-game.

[proxict]

Can we bump the priority of this issue? It has been bothering us for over 7 years and it seems like only a little effort could be done to fix it.

[SeerLite]

If you want a workaround you could try a very basic KMonad configuration that maps Caps Lock to Escape. It creates a new keyboard device so all programs (and thus games) will treat it correctly.

[sioodmy]

still not fixed btw

[roket1428]

9 years later its still not fixed...

[sioodmy]

lmao

[vadcx]

This is a multi-layered issue now. I checked this under current X11, Manjaro KDE (Plasma 5.27.11, KDE Frameworks 5.115.0). Please note that CS2 recently changed to scancode-based key registration to fix keyboard layout issues like https://github.com/ValveSoftware/csgo-osx-linux/issues/3337

Notation: PHYSICAL_KEY(LOGICAL_KEY).

> bind capslock blabla
Interpreting bind command as:
    bind scancode57 "blabla" // US English key name "CAPSLOCK"

> bind escape cancelselect
Interpreting bind command as:
    bind scancode41 "cancelselect" // US English key name "ESCAPE"

• CAPS(ESCAPE):

  • :heavy_check_mark: Panorama UI: Escape as expected in new menu UI (main menu and interacting with Panorama UI in-game)
  • :stop_sign: In-game actions: Still triggers bind for "capslock" aka scancode57

• ESCAPE(CAPS)

  • :heavy_check_mark: Panorama UI: Works as Caps in new UI, same as above
  • :stop_sign: In-game actions: Still triggers bind for "Escape" aka scancode41 or opening the game UI

Because the interpretation differs between in-game and Panorama, you see the following behaviour:

• Start a practice map to join the game, spawn
• Press ESCAPE(CAPSLOCK) to trigger the game menu, even if you expected only Capslock to trigger (and Capslock state really is toggled system-wide!)
• Now when Panorama UI is in focus, you actually need to press the correctly interpreted CAPSLOCK(ESCAPE) for logical Escape to close the menu. Since that key isn't interpreted as Caps by the system, you leave the menu without untoggling Capslock state.

Similarly, Keyboard settings save Panorama's interpretation of keys. So if you want to change binding for CAPS(Escape) using the settings, it will save the logically correct key, but the in-game bind will rely on the physical interpretation of that key.

PS:

# enable caps remapping
setxkbmap -rules evdev -model evdev -layout us -option caps:swapescape

# disable (back to default, reset options)
setxkbmap -rules evdev -model evdev -layout us -option