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?

[alexdima]

The work would be split between making first a change in native-keymap and then in vscode.

• the work in native-keymap would involve finding and using X11 specific methods that would capture/return the mappings done via setxkbmap and expose them in some form in the results of _GetKeyMap
• the work in vscode would involve making changes in macLinuxKeyboardMapper.ts, where the values returned from native-keymap are consumed, and where all keybindings decisions are done for OSX and Linux.

I would be very appreciative if anyone figures out the X11 specific methods / submits a PR for native-keymap. I can tweak or refactor (if the current model is incorrect) in VS Code.

The way we handle keybindings decisions is documented here

[kylebakerio]

Still experiencing weirdness with 1.21.1 in debian 9.

caps lock and ctrl swapping caused issues. seemed to partially help by swapping settings so that instead of "caps lock and control are swapped", I now have "caps lock is set as another control".

[dagolinuxoid]

Great, now I can use vim mode :)

[jhpratt]

The workaround unfortunately breaks other things, notable the Ctrl + ` shortcut to toggle the integrated terminal. And yes, I'm using a standard-ish layout (those two keys aren't affected).

[dagolinuxoid]

@jhpratt, Ctrl + ` works ( at least in my case it toggles the terminal without issues )

[Loridawn99]

Awesome

[pumpkinlink]

same problem as @jhpratt, the workaround breaks a lot of shorcuts, (I use an ABNT2 (Brazil) keyboard)

[pumpkinlink]

the workaround I found was:

1. open gnome tweak tool
1.1 disable the caps lock remap (re enabling caps lock default behavior)
2. open vscode
2.1. map "extension.vim_escape" to capslock
3. go back to gnome tweak tool
3.1 map caps lock to esc again

edit: making the above disabled my actual top left physical Esc key. so I made the follwing instead:

1. Reset the extension.vim_escape keybinding on the GUI Keyboards Shortcuts screen and remove everything related from keybinding.json
2. add the following to keybinding.json:

,
    {
        "key": "capslock",
        "command": "extension.vim_escape",
        "when": "editorTextFocus && vim.active && !inDebugRepl"
    },

now both my physical esc key and the xkbmap/gnome-tweak-took remapped caps lock key work as expected. my dconf settings are as follows:

org.gnome.desktop.input-sources.sources: "[('xkb', 'br')]"
org.gnome.desktop.input-sources.xkb-options: "['shift:both_capslock', 'caps:escape']"

[rustonaut]

@alexandrudima,
I just ran into this issue, too.
Is there a good reason why vscode uses scan codes?
I mean scan codes are not really meant to be used by a user application in Linux.
And not using the key codes mapped by xkb, will just lead to a repeatedly running
into problems for anyone using a rare keyboard or keyboard layout, or alternate input
device pretending to be a keyboard.

Also this won't go away with wayland, as (at last the Wayland implementations I
used) still use xkb internally.

[alexdima]

We are dispatching by default based on scan codes because those are the only things we receive from Chromium/Electron which we can trust to reflect reality and which have not been processed through magic Chromium mapping tables.

AFAIK, the story goes like this:

• JS keyboard events get a keyCode field on Windows
• this makes a lot of sense on Windows, as that is a concept that exists on Windows, and all applications on Windows should dispatch on KeyCodes. Exposing them from a browser to a web application seems natural...
• the problem is when the same concept is attempted to be supported on OSX and Linux, where there are kb maps but those concepts do not map clearly to the same keyCode concept from Windows.
• browsers have used creative solutions to come up with keyCode values which appear to make sense on Linux and OSX, but they are inherently broken because the concept of keyCode does not exist natively on those operating systems.
• we come along and need to render in the UI the key to be pressed to trigger a certain keybinding
• the creative solutions browsers came up with prevent us from building a reverse map from keyCode to produced character in order to display a good label in the UI.
• we switch to dispatch on code (scan code) which is a value that does not go through the creative solution and is passed to JS unprocessed. We implement https://github.com/Microsoft/node-native-keymap which uses OS APIs to map scan codes to produced characters. Unfortunately, the code we have on Linux, does not cover the setxkbmap customizations, it appears we need to improve that code...
• so, in cases where one is using setxkbmap it is probably better to dispatch using the previous keyCode solution, especially when using an English keyboard layout where the creative solution from browsers is reversible and we can print decent labels in the UI. But, when not using setxkbmap and when using a different keyboard layout (like de-DE, etc.) it is preferable to run VS Code with dispatching on code.

Because using setxkbmap is a hint for an advanced user, and using a regular keyboard layout (like de-DE) is not, we have made the decision to dispatch based on scan codes by default to cover most of the folks (including new Linux users). Advanced Linux users (that use setxkbmap) need to go through the hurdle of configuring the dispatch setting...

In the long term, it would be good if we'd improve https://github.com/Microsoft/node-native-keymap to also take into account setxkbmap customizations.

[andyl]

OMG this is so painful. Tried the keyCode workaround and @pumpkinlink workaround. Nothing works. (I'm using Xubuntu 18.04 btw). Is there a way to map the scan code to <Esc> ?

[alexdima]

@andyl Configure "keyboard.dispatch": "keyCode". Restart VS Code.

[rustonaut]

@alexandrudima thanks for the long explanation.

This is quite a quirky problem, I guess to best (but unlikely to be doable) solution would
be to fix how browsers handle keyboard events 😭 .

[alexdima]

They are working on it, it just takes time... https://wicg.github.io/keyboard-map/

[andyl]

@alexandrudima - yeah I tried the "keyboard.dispatch": "keyCode" workaround and it doesn't work on my system. Learning more about the escape key than I ever thought possible. In settings.yml I mapped kj to <Esc> - which does work. But for the real escape key no luck. Interestingly enough: I disabled the setxkbmap modification and it still doesn't work! I also tried to set extension.vim_escape to various Keybindings - no luck. Maybe I am experiencing a voodoo curse or anomalous cosmic rays.

[rustonaut]

The "keyCode" workaround just stopped working for me.

[efredzb]

Same here.

[JoschD]

Ubuntu 18.04.1 here: "keyboard.dispatch": "keyCode" still works. (With swapescape)

[mlcamilli]

Kubuntu 18.04 here: "keyboard.dispatch": "keyCode" doesn't work with capslock rebound to ctrl. VSCode still recognizes capslock, no other electron app / program does.

[certik]

In Ubuntu 18.04, to make Caps Lock become an Escape, apply this patch:

--- a/etc/default/keyboard
+++ b/etc/default/keyboard
@@ -5,6 +5,6 @@
 XKBMODEL="pc105"
 XKBLAYOUT="us"
 XKBVARIANT=""
-XKBOPTIONS=""
+XKBOPTIONS="caps:escape"
 
 BACKSPACE="guess"

restart the computer and add the "keyboard.dispatch": "keyCode" into your vscode settings.

[mlcamilli]

@certik did not work for me

[codethief]

Since a lot of people here seem have esc bound to their caps lock keys, let me throw in the hat for the folks that have ctrl bound to the space key. Yes, the space key.(†) Needless to say, VS Code doesn't handle this well with dispatch set to code – every time I use space as ctrl it interprets it as a key chord of space and ctrl+<the other key I'm pressing>.

I'm mentioning this because I am not sure solutions that add setxkbmap support to VS Code will solve this, as most solutions that bind ctrl to the space key seem to work in a different way from what I've gathered. (Though I should mention that I don't understand too much about the mess that is xmodmap, setxkbmap et cetera, so I could easily be wrong.) Anyway, it would be great if at least one of the "ctrl->space" implementations (see below) were supported eventually. :) …or if at least the "keyCode" dispatch mode doesn't get deprecated afterwards.

Speaking of which, the latter actually seems to work fine for me on a "de-DE" keyboard. @alexandrudima: Is there a particular reason the "code" mode is recommended for German keyboards or is there anything that doesn't work in "keyCode" mode that I haven't noticed?

--

† For those who haven't heard of this: The space key basically acts as ctrl when held down and as space when hit quickly. Not only is this a lot more comfortable to use as your strongest finger – the thumb – is doing all the work; it can also really work wonders when you're dealing with RSI-related issues. In case anyone's interested, here're some solutions I'm aware of that implement this:

• xcape (very simple installation and generally works great; though, when hot plugging another keyboard it sometimes needs to be restarted)
• at-home-modifier-evdev (more involved installation but probably the best / most polished solution of the bunch)
• Space2Ctrl (works ok-ish; hot plugging a keyboard trips it up in 99% of the cases)
• keydouble (last time I tried this, keyboard input lagged but maybe I did something wrong)

[andyl]

Yesterday I found that my problem was a bad setting in keybindings.json. Once I removed this, works fine on Xubuntu 18.04 configured using setxkbmap -option caps:swapescape.

[olofwalker]

On Ubuntu 18.04, if you remap the Capslock to Ctrl, you always have to press enter when using the Ctrl+Tab to switch to a new editor. But this behavior is not unique to VS Code, it also happens in the Vivaldi browser that have a similar "switcher".

Using the record keys in Keyboard shortcuts, I can see that when pressing Ctrl+Tab (using the remapped CapsLock as Ctrl) it reports CapsLock Ctrl+Tab, which is different from the "normal" Ctrl+Tab.

[mlcamilli]

I experience exactly what @olofwalker described. All of my bindings with capslock bound to ctrl do not work because of this

[manudurruty]

"keyboard.dispatch": "keyCode" stopped working.

[itgoyo]

thanks gay,"keyboard.dispatch": "keyCode", it works for me

[apahne]

I have mapped CTRL to Caps Lock.
"keyboard.dispatch": "keyCode" is not working.

That is deep in my muscle memory. All other apps honor that. VSCode became pretty much unusable to me.

[NanoDano]

I modified my settings.json to include "keyboard.dispatch": "keyCode", and it started working in Linux (Fedora Gnome). Thanks for that tip. I mapped my key using dconf write /org/gnome/desktop/input-sources/xkb-options "['caps:escape']". In Windows I use AutoHot key and have no issues.

[Deleted user]

I’m using Ubuntu, and have Caps Lock mapped to Ctrl.

What worked for me was using Gnome Tweaks, and setting “Ctrl position” to “Caps Lock as Ctrl”. I initially had “Caps Lock behavior” set to “Caps Lock is also a Ctrl”, but that did not work. Also "keyboard.dispatch": "keyCode" seems to be needed.

Hope this helps!

[mlcamilli]

@alexanderte super helpful, fixed my problems!

[LarnuUK]

Changing Keyboard: Dispatch to KeyCode seems to have no effect for me, or at least doesn't cause settings for pointer to use the modifier Xmodmap settings.

[revgum]

re: @alexanderte mentions using Gnome Tweaks to set "Ctrl position" and "Caps Lock behavior", I tried multiple options with the checkboxes and it only worked with the configuration in attached screenshot (along with "keyboard.dispatch": "keyCode")

[jhpratt]

Following up on my comment from April 2018 (~17 months ago). I just tried setting it to keyCode, and ran into the same issue as before — Ctrl + ` doesn't toggle the terminal. I've updated the version of Ubuntu, but it's otherwise the same.

@alexandrudima Is there any progress on this front? Is it something I might be able to take on?

[JamesLavin]

I found a partial workaround that might help other vim users. I tweaked the idea in https://dev.to/karlredman/navigate-your-vscode-like-its-1999-the-vim-way-3632 by adding the following to ~/.config/Code/User/keybindings.json:

    {
      "key": "capslock",
      "command": "extension.vim_escape",
      "when": "editorTextFocus && vim.active && vim.mode == 'Insert'"
    },

CapsLock is now triggering Esc to get me out of Vim's insert mode, but it's also toggling CapsLock, so I have to hit CapsLock a second time to undo that. (I tried using multi-command, https://marketplace.visualstudio.com/items?itemName=ryuta46.multi-command, to automatically call CapsLock a second time, but capslock doesn't seem callable as a command.)

This shouldn't be this hard. Sigh.

[sholderbach]

I found similar key rebinding problems with the new great jupyter notebook editor of the python extension.
The "keyboard.dispatch": "keyCode"setting is not correctly respected when using Esc mapped on the Caps Lock key to leave the jupyter notebook edit mode.

https://github.com/microsoft/vscode-python/issues/8020

Yet in the general editor and dialogs it works for me without a problem

[itachi-19]

"keyboard.dispatch": "keyCode"

Where to add this?

[LarnuUK]

"keyboard.dispatch": "keyCode"

Where to add this?

Open the settings (ctrl+,), and search for Dispatch. Or click the Open Settings (JSON) button (top right, shown below), and put the setting in your JSON (it is assumed you understand how to edit a JSON file):

[itachi-19]

"keyboard.dispatch": "keyCode"

Where to add this?

Open the settings (ctrl+,), and search for Dispatch. Or click the Open Settings (JSON) button (top right, shown below), and put the setting in your JSON (it is assumed you understand how to edit a JSON file):

Thanks a lot :)

[neoscaler]

This bug is still present, but the workaround also still works for me. I use the Workman-P keyboard layout, which has Backspace on Caps Lock.

[jpaniagualaconich]

The Dell XPS 13 7390 has a different home/end/pgup/pgdn layout than previous models.
To try and get a similar experience on the 7390, I remapped Home, End, Page Up and Page Down to AltGr+Left, AltGr+Right, AltGR+Up and AltGr+Down. It works with both "keyboard.dispatch": "code" and "keyboard.dispatch": "keyCode".

Problem is that the "original" PgUp and PgDn keys that I thought I disabled are still working on Electron apps, even though they're disabled for all the non electron apps. This is what xev shows for the disabled PgDn:

    KeyRelease event, serial 37, synthetic NO, window 0x6600001,
    root 0x136, subw 0x0, time 1695289, (141,560), root:(249,662),
    state 0x0, keycode 117 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

NoSymbol is not taken into account somehow and vscode still turns keycode 117 into a page down.

I can work around it by directly using setkeycodes but it would be awesome if I didn't need to.

[jhpratt]

For reference, my previous comment is still correct. Using keyCode does not work for me. Doing Ctrl + ` does not open the terminal as would be expected; neither of those keys are affected in any way by my keymapping. The extent of what I'm doing is having a British layout with minor modifications via Gnome.

[kylebakerio]

This is unbelievable. Only project I know of that has this problem. Never had an issue before. And a project this size, for programmers, still hasn't fixed this after years?

Embarrassing.

[NanoDano]

@kylebakerio Maybe you can ask for a refund.

[mahkoh]

@kylebakerio Maybe don't use Microsoft software on linux.

[ahmaddynugroho]

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

[kylebakerio]

For whatever it's worth, giving vscode another try after all these years, now on a clean debian 10 install, with a less complex keyboard setup (haven't gotten around to it), it seems to work... Only thing I've done is set caps lock to be ctrl using gnome-tweaks.

... until I tried setting a custom hotkey that is a default in sublime text, which is auto-indent on paste. When I tried to set to ctrl+shift+v, it somehow got confused by the capslock being a control again, and started making it so that I'd have to hit my hotkeys twice for them to work. I noticed some funniness with the input reading, it noticed it was capslock and didn't respect that it should ignore it is capslock and that it is just a ctrl.

I quickly just turned it off and manually indent things for now. I'm in the middle of a project, so I'm just giving vscode a chance for now.

Given this, I imagine if I had all my language settings and key modifiers, it still would have trouble dealing with keyboard inputs.

Maybe when my current sprint is done I'll spend some time getting to know vscode and trying to give it a chance, but this is just not a good sign.

[romin1122]

Thanks, It solved my problem as well. Awesome!

[tkkcc]

Hi, @sholderbach. Have you made it work in jupyter?

I am trying to map capslock to escape in jupyter notebook ui. In default keybings.json there is

{ "key": "escape", "command": "notebook.cell.quitEdit","when": "inputFocus && notebookEditorFocused" },

In self keybings.json, Changing escape to ctrl+capslock works, while changing to capslock fails. Also tried toggling "keyboard.dispatch": "keyCode"

[trululu96]

The workaround stopped working randomly, It did not improve after a reinstall. It particularly stopped working while on jupyter notebooks, on the rest of the app it works fine.

Version: 1.49.0
Commit: e790b93
Date: 2020-09-10T13:20:50.359Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Linux x64 5.4.0-7642-generic

[i-oliva]

setxkbmap -option lv3:rwin_switch

[lbrande]

I also have problems but I have instead used xmodmap to swap escape with the key just below escape (section on my keyboard). I've tried using "keyboard.dispatch": "keyCode" but it doesn't help at all. Binding ctrl+escape appears to work though. Any known solution?

[ihlec]

I also have problems but I have instead used xmodmap to swap escape with the key just below escape (section on my keyboard). I've tried using "keyboard.dispatch": "keyCode" but it doesn't help at all. Binding ctrl+escape appears to work though. Any known solution?

same issue here.
xmodmap bindings are broken

other remappings like KDE->Keyboard->Advanced works fine with the "keyboard.dispatch": "keyCode"

[Stigjb]

The "keyboard.dispatch": "keyCode" workaround has stopped working for me recently. The keys are still swapped in other applications, but now hitting caps lock in VS Code has absolutely no effect whether the dispatch is set to code or keyCode.

[Scoder12]

The "keyboard.dispatch": "keyCode" workaround was working but recently it isn't working anymore.

[kylebakerio]

Amazing. I've been following this issue for years. I don't know any other app on linux that has had so much trouble respecting this issue that I've ever interacted with--and it's a tool built specifically for developers to write code?

I guess it matters that it is built by microsoft?

[Scoder12]

False alarm, it started working again for me 🤷

[Stigjb]

It started working again for me as well 🤷

[joooooooooooooooooooooooooooooooooooosh]

Stopped working for me again.

[aflag]

Are there any hopes of this issue ever getting fixed? Are all chromium based apps affected? Has it been notified upstream?

[kylebakerio]

@aflag I've never experienced this issue with any other app (including other chromium based apps) in linux. this is a vscode-only issue for me, and has been repeatedly the handful of times I've given vscode a go over the years.

[aflag]

Indeed a bit weird. It seems there’s a workaround which I haven’t tested yet. Can’t say I’ve tried too many electron based apps before, though.

It took me a while to realise what the bug was, I thought vscode was dropping input from time to time. It was very confusing, until I figured out what was going on. If it’s too difficult to fix, maybe trying to identify that something may be wrong during startup and showing a popup with a suggestion to try that work around would go a long way. It’d have definitely made my life easier/less frustrating a couple days ago.

[rishadbaniya]

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

[gorilskij]

I'm swapping Caps Lock and Backspace and the keyCode option has recently stopped working (Ubuntu 20.04, code 1.55.2)

[fahadbr]

this is also a problem for me using setxkbmap settings. i started looking into using interception-tools combined with caps2esc (https://gitlab.com/interception/linux/tools) as an alternative set up and it seems to work with vscode. (capslock works as escape again)

I would suggest people looking into interception-tools as a workaround

[AntonOfTheWoods]

@alexdima you are still assigned to this ticket, and we haven't seen any action in a while. I see the W3C keyboard-map has a draft version from March of this year.

Might one option be to try and detect that some xkb fooery is going on and alert the user to look at a FAQ about this issue, if we still need to wait for a proper fix? It's little niggles like this that keep us zealots from becoming full converts :-).

[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:

• #24166
• #23690
• (and then as a regression) #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.