Keyboard mappings with setxkbmap on Linux not working

[tallpants]

• VSCode Version: 1.11.0
• OS Version: Ubuntu 16.04

I have my Caps Lock key bound to Escape using setxkbmap on Linux. This worked fine till 1.10, but broke with 1.11. At first I thought it was an issue with the VSCodeVim extension, but the issue persists with all the other Vim extensions on the marketplace as well. Pressing the escape button still works as expected.

The binding is still respected everywhere else in the operating system, it's only Visual Studio Code that ignores it for some reason.

Steps to Reproduce:

1. Run setxkbmap -option caps:escape (binds caps to escape for the duration of the session)
2. Hitting caps lock when in insert mode (with a Vim extension like VSCodeVim installed) no longer puts you normal mode.
3. Hitting escape still works as expected and puts you in normal mode.

[jspaine]

Same, with swapescape. Oddly caps lock works as escape to cancel in the keybinding editor, and either caps lock or escape cancel the F1 menu. Tried disabling all extensions, wiping user settings and using an empty workspace to no avail.

I have problems with numpad keys too. With num lock off they do nothing, but work as number keys with it on. If I press a direction with numpad off, nothing happens, but then turn it on and type a number and the cursor will move and then put the number.

In the keyboard shortcuts editor numpad PgDn, for example, shows up as numpad3 whether num lock is on or off.

[alexdima]

This is something that might be broken by us dispatching based on scan codes. I am sorry about it, I need some time to investigate how these options should be handled. i.e. should Chromium handle these mappings or should we do it at the application layer.

Workaround to switch VS Code to dispatch based on key code again. Add the following setting:
"keyboard.dispatch": "keyCode" and restart VS Code

[tallpants]

Thanks for the workaround! 👍

[graves501]

The workaround works like a charm, thanks!

[tobico]

I have a similar issue, with my Caps Lock bound to Control, where Code is unable to autoclose the quick open window when pressing Ctrl+Tab and then releasing Control. I've tested the workaround and it does not solve this issue.

Note: this appears to be specifically an issue with detecting the modifier key. Caps+Tab still launches the quick open just fine, and I have other remapped key bindings for arrow key movements that also work fine.

[navxio]

this workaround isn't working for me on vscode 1.12.2-1..

[alexdima]

@navdeepio Can you please follow our troubleshooting guide at https://github.com/Microsoft/vscode/wiki/Keybindings#troubleshoot

If nothing in there works, then please proceed to create a new issue using the steps in the "I have tried all of the above" section.

[Chillee]

@alexandrudima Do you guys plan on fixing this issue at some point? Or is the workaround satisfactory as a long term solution?

[alexdima]

@Chillee This method needs to be enhanced to account for setxkbmap customizations and then we might need some tweaks here to cover mappings of those scan codes

[Chillee]

Is it tricky or is it feasible as a first time contribution?

[olejorgenb]

What's the rationale for dispatching based on "code"? Does this means that dvorak and international users have the same physical hotkeys as qwerty and americans also? (which is arguable a good thing, but possibly quite confusing)

I assume "code" means keycode and "keycode" means keysym in X11 lingo.

[truly-irham]

This is how I make Caps Lock an additional Esc for vim extension in vscode in POP!_OS 19.10:

1. "sudo apt install gnome-tweaks"

2. "gnome-tweaks"

3. go to "Keyboard & Mouse" and click on "Additional Layout Options"

4. inside "Caps Lock Behavior" choose "Make Caps Lock an Additional Esc"

5. go to vscode "File" then "Preferences" then "Settings"

6. Type "dispatch"

7. choose "keyCode"

8. done

now this thing works

Thanks for quoting this. I really don't know why the workaround "keyboard.dispatch": "keyCode" in settings.json doesnt sync with the gui settings. It's great if someone could clarify this perhaps :/ I use arch btw

[diogogmt]

Switching the dispatch mode to keyCode is working again; "keyboard.dispatch": "keyCode"

[MossabDiae]

I'm using colemak , vscode didn't respect capslock as backspace which I set using setxkbmap , setting "keyboard.dispatch": "keyCode" did work but all the shortcuts were remapped based on the new layout which was uncomfortable .
the solution I did was :

• setting keyboard.dispatch back to code
• manually setting capslock to delete characters in keybindings.json (Preferences: Open keyboard shortcuts (JSON))

    {
        "key": "CapsLock",
        "command": "deleteLeft",
        "when": "editorFocus"
    },

I'm sure this issue will remain open until I show it to my grandson one day, I'm 24 ...

[kylebakerio]

I just drop in to watch the fire burn every time I get a new notification. This issue is literally the reason I don't give VScode a real chance and stick with sublime, not willing to deal with it every time I re-install. caps lock as ctrl being seamless matters more to me.

[aflag]

@kylebakerio it's free software, you can always fix it yourself and make lots of people happy.

[kylebakerio]

I am not invested in this project. There are other editors. People rave about VS code, it was the hottness for a while, I wanted to give it a shot. It's not my field of expertise, so I'd be very inefficient getting up to speed on this. I also frankly have my own projects, work, and open source projects I contribute to. Just not in the cards for me.

It's surprising that a project sponsored by Microsoft doesn't have their shit together and prioritize what to me is fixing a bug in something ground level--getting keyboard mappings handled right in a code text editor on linux. I've never encountered this bug in another project on linux, it just isn't hard to respect key mappings in a vanilla gnome environment... And if it is, it doesn't speak well of their code architecture and design choices.

I feel like a bit of a troll here on this thread now, but it's become some kind of sad trash fire to watch, kind of can't help it. The last time I had this experience was watching the Chromium "bug report" for the garbage built-in hotkey that was present for years that made backspace = "go back" history navigation if you weren't in an active text field... which meant if you accidentally lost focus on text field (say, but tapping your mouspad with your palm on a laptop while typing) and hit backspace, you could lose all you had typed.

For years I watched the conversation rage on about this. I just sat in disbelief that such a moronic default couldn't be fixed. They finally did! couple years back. my god. anyways, same as here, would just pop in when I'd get email notifications as the conversation accumulated back and forth, year after year.... This bug has was reported in ubuntu 16.04! We're in the 21.10 era now! Jesus!

[alexdima]

I am sorry that it takes us a long time to fix this issue. The problem is that we are not X11 experts, and that our time is very limited and split between other issues. Unfortunately, we don't really get any community contributions in this area. I can only guess that is because the underlying node module is written in C++ and a contributor would need to be an expert in or at least understand the inner workings of X11.

Last month I spent about 3 days (!!) just reading the X11 specification such that I could fix:

• KDE: Reading keyboard layout reads the wrong one #24166
• Keyboard layout changes are not detected on Linux #23690
• (and then as a regression) keyboard shortcuts do not work for correct languaga although correct language active in gnome session #135848

You can find the changesets I did at https://github.com/microsoft/node-native-keymap and assess how easy or complex doing them is:

• microsoft/node-native-keymap@91db859
• microsoft/node-native-keymap@65b214d
• microsoft/node-native-keymap@c5f039f
• microsoft/node-native-keymap@9c26199
• microsoft/node-native-keymap@47dbdb6

We also need to improvise, for example we now have a new thread running that is just listening to X11 keyboard state change events (in parallel to whatever Chromium is doing with X11). Is that a good design? Is that a bad design? We don't know, because we're not experts in X11. We also got some ugly freezes because of trying to join that thread (e.g. #135108), so that's why we try to ask for community help.

Contributing with comments that do not contain technical content is not helpful in this particular case. Please take a moment and consider the following positive ways in which you can contribute:

• review the C++ code
• create a PR that fixes a problem (e.g. memory leaks?)
• create a PR that implements a new feature in this area (e.g. wayland support)
• read the X11 / wayland spec and comment with technical content or links that point us to what we should be doing

To clarify, there is always the workaround to use "keyboard.dispatch": "keyCode", it is not the case that this issue does not have a workaround. If "keyboard.dispatch": "keyCode" does not work, then it means that the setxkbmap you have defined also does not work in any Chromium based browsers.

[kylebakerio]

Hey, I'm sympathetic to that, interesting to hear that it isn't somewhere clearly defined as a best practice. Atom is another chromium based code editor--does it not exhibit this bug? If so, could one not look at how they've implemented it?

However

If "keyboard.dispatch": "keyCode" does not work, then it means that the setxkbmap you have defined also does not work in any Chromium based browsers.

This doesn't seem to be true, as I use chrome as a power user, and never have the issues I've seen in VScode, including with this setting. ¯\_(ツ)_/¯

[akosfekete]

Another workaround for this could be using kbct to remap keys instead of setxkbmap (it works on a lower level and even supports Wayland). It's not a one-to-one replacement, but it solved a bunch of issues for me (it requires the uinput kernel module to be loaded though)

[kylebakerio]

For whatever it's worth, an interesting VSCode extension made me give vscode yet another try.

I'm on pop 21.10 (an ubuntu variant, with gnome), using the same gnome-set caps-lock-as-control I've always had, and it's working as far as I can tell--so, progress!

I used to also have multiple languages installed, and that had also caused a subtle weird bug--don't have multilang set for now, so can't verify that issue is gone, but just thought I'd pop in and throw that out there.

[haoadoreorange]

@alexdima, I have ctrl J set to workbench.action.quickOpenNavigateNext (vim nav) and also have GNOME Make Caps Lock an Ctrl, so I can press caps J to navigate as such.

In my case the navigation does work so I suppose it's not a key dispatch problem. However, workbench.action.quickOpenNavigateNext is supposed to select the option on key release and indeed using ctrl J does so but caps J does not, it only moves the selection.

What can be the issue here that blocks the "choose" action ?

[Gingercookie]

Using Ubuntu 22.04 LTS I have achieved some level of success by remapping the system keycode for caps lock to another key (one that I never use, right_control). This way, my system reads the incoming caps lock press as a different key entirely, and thus eliminates the need to bother with keyboard.dispatch in the settings.

Caveat : I didn't figure out a way to map two key codes to the same key symbol. This means whatever key you take over will need to be remapped to something else, or be completely disabled. (Works great if you want to swap two keys). The way I did it, the right control key is now a "dead" key on my system. If someone else knows how to make that happen, that would be a much better solution.

How to change your system keymap :

1. Edit keymap sudo vim /usr/share/X11/xkb/keycodes/evdev
2. Find the key you want to map to (in my case RCTL), and edit as needed.

        // <RCTL> = 105;        // Unmap right control key from right control
        <RCTL> = 66;            // Map caps lock key (66) to right control

3. Close all GUI applications and save all work before the next step!
4. Restart your x11 server sudo systemctl restart display-manager

[alanhoyle]

I'm seeing this same issue on macOS 13, using the OS's built-in Colemak keymap, on various VSCode-based web IDEs including:

• github CodeSpaces
• gitlab IDE (locally hosted)
• Code-server (locally hosted)

While accessing those IDEs through the following browsers:

• Chromium-based browsers (incl. Brave and Chrome)
• Firefox
• Safari

The work-around with Settings: "keyboard.dispatch": "keyCode" makes this work for me in any of those.

Native macOS VSCode works perfectly without any need for Settings modifications!

[fweth]

Can confirm what @alanhoyle is saying for ChromeOS 116 (and older versions) as well.

[ixaxaar]

Have been observing the same issue with arch + vscodium.
I needed to modify delete -> home and also reconcile with the fact that there is no tilde key on one of my keebs.

The only solution I finally could work with is with vscode keybindings:
Fortunately, got chatGPT to generate this.

[
  // Insert -> Home
  {
    "key": "insert",
    "command": "cursorHome",
    "when": "editorTextFocus"
  },
  // Shift+Insert -> Shift+Home
  {
    "key": "shift+insert",
    "command": "cursorHomeSelect",
    "when": "editorTextFocus"
  },
  // Ctrl+Insert -> Ctrl+Home
  {
    "key": "ctrl+insert",
    "command": "cursorTop",
    "when": "editorTextFocus"
  },
  // Ctrl+Shift+Insert -> Ctrl+Shift+Home
  {
    "key": "ctrl+shift+insert",
    "command": "cursorTopSelect",
    "when": "editorTextFocus"
  }
]

[Khayet]

Here's a rather simple workaround that helped me as a user of KDE Plasma, Fedora 38 (Wayland):

Instead of checking the option "Make Caps Lock an additional Ctrl" under "Caps Lock behavior" in the System Settings (Keyboard > Advanced), I check "Caps Lock as Ctrl" under "Ctrl position". This works for me, maybe it's helpful to other Plasma users as well.

[rkjnsn]

Currently, there's a setting to toggle between the legacy keyCode property, which takes the layout into account but requires “creative solutions”, and the new code property, which ignores layout entirely and reports only the physical location of the key, requiring VSCode to do its own layout mapping. Why not instead use (or offer the option to use) the more-modern key property, which takes the layout into account like keyCode, but is designed with cross-platform use in mind and thus avoids some of the problems of the legacy keyCode property.

Looking at the key value is analogous to looking at the decoded ksym value on Linux, which is what almost all native applications do, aside from things like games, VMs, and remote desktop tools.

[l8l]

As of December 2023, I still experienced this issue that switching Esc and Capslock was not respected by Vscode despite never having had an issue in any other app. The "keyCode" workaround worked for me but I'd appreciate this to be fixed. As a first step, one could let "keyboard.dispatch": "keyCode" just be the default on Linux for example?

[beenotung]

Workaround to switch VS Code to dispatch based on key code again. Add the following setting:
"keyboard.dispatch": "keyCode" and restart VS Code

A reminding, you need to actually restart VSCode for this change to take effect.
Restart extension host is not enough.

[barafael]

Previously this workaround worked fine for me, however recently using plasma6/wayland and it no longer works.

[rabyj]

Previously this workaround worked fine for me, however recently using plasma6/wayland and it no longer works.

@barafael Does the original keyboard dispatch setting work for you? Or the workaround mentioned by @Khayet ?

I wouldn't expect the X11 solution to work for Wayland, considering wayland handles keycodes differently from x11 (setxkbmap doesn't interact with Wayland protocols, and this issue is about setxkbmap originally).

[barafael]

@rabyj the original solution. The other workaround isn't applicable to my use.
Btw I have the identical issue under plasma6/x11.

[barafael]

@rabyj never mind! I made a mistake, it does work. Thanks :)