KDE: Reading keyboard layout reads the wrong one

[goetzc]

Since version 1.11.1 (last I used was 1.10.2), the shortcut to "Toggle Line Comment" (which was Ctrl+/) now zooms out, like when pressing (Ctrl+-). Pressing Ctrl+Shift+7 does work, but Shift+7 is &. The actual layout when writing text, is correctly set to US, but shortcuts are interpreted as DE.

• VSCode Version: 1.11.1
• OS Version: Arch Linux 64-bit (using the .tar.gz version)
• Desktop environment: KDE Plasma 5.9
• Current keyboard layout: EN-US

Steps to Reproduce:

1. Open Keyboard Shortcuts.
2. Find the shortcut and edit it.

Inside Developer: Inspect Key Mappings there is no VK_OEM_2.

Some interesting values:

Layout info:
{
	"model": "pc104",
	"layout": "de,us",
	"variant": "",
	"options": "grp:win_space_toggle,kpdl:dotoss,altwin:meta_alt,caps:ctrl_modifier",
	"rules": "evdev"
}
isUSStandard: false

	"Minus": {
		"value": "ß",
		"withShift": "?",
		"withAltGr": "\\",
		"withShiftAltGr": "¿"
	},

	"Slash": {
		"value": "-",
		"withShift": "_",
		"withAltGr": "–",
		"withShiftAltGr": "—"
	},

The issue seems to be that when there are multiple layouts configured, VS Code sets as key layout the first value for layout form setxkbmap -query, ignoring the current layout. If I switch to be en,de then VS Code uses the EN layout, as it is the first in the list. It would be handy if VS Code could use the current layout instead of the first from the list.

[alexdima]

@goetzc

On Linux, we don't detect when keyboard layouts are changed while VS Code is running. We read the keyboard layout information on start-up and cache it for the entire lifecycle of the window. I'm thinking you're not hitting this issue and you are restarting vscode in between changing keyboard layouts.

We use X11 APIs in the C++ node module to determine the current keyboard layout and its mappings. We loop over each "scan code", fabricate an 4 XEvent(s) (with various modifier keys on/off), dispatch it, and read the produced characters: https://github.com/Microsoft/node-native-keymap/blob/master/src/keyboard_x.cc#L171

I have seen this reported before on CentOS - #23505

I am not sure I understand what's going on, it appears that changing the keyboard layout at the Operating System level fails to update the keyboard layout as seen by X11 or by our used APIs in X11. In other words, on Ubuntu, for example, changing the keyboard layout from the OS results in X11 being aware of the change.

In other words, it appears under Ubuntu, switching the keyboard layout results internally in a setxkbmap de,en or setxkbmap en,de, etc. I am not sure how we should detect the keyboard layout under these other distributions. If you have any experience on the topic, I would love if you could take a look at the C++ implementation, a second pair of eyes would be more than welcome, and perhaps there's something very easy we're missing.

[alexdima]

A workaround in the meantime would be to force us back into dispatching based on keyCode:

"keyboard.dispatch": "keyCode"

[alexdima]

Related: #23505

[ggabriel96]

A similar issue started happening with me on Fedora 25. Toggle Line Comment stopped working after 1.11.1 and if I try to reassign it, Code reads Ctrl+; instead of Ctrl+/. Tried with US alternative international and Portuguese (Brazil) layouts and restarting the app, with no luck :(

Edit: the suggested workaround seems to fix it for me. Thanks for that! Really!

[goetzc]

Hey, just to clarify, for me the workaround was changing the layout order returned by setxkbmap -query as VS Code seems to pick the first one on startup. When using the global KDE keyboard shortcut to switch layout (or the plasmoid) the output from setxkbmap doesn't change.

KDE's System Settings can change this too:

[SolarLiner]

I can reproduce the bug in Ubuntu and Manjaro GNOME. setkbxmap does not change according to the current layout, but to the order of preference in the Language settings. Therefore changing the keyboard layout and restarting VS Code is not a viable workaround.

What's the downside of using "keyboard.dispatch": "keyCode"? It seems that some key combinations are changed (like toggling line comment on French layout, default is CTRL+SHIFT+: but with dispatch set to keyCode, it's just CTRL+:).

[HereThereBeMonsters]

I have the same issue in Kubuntu 18.04.1. Interestingly, I have the issue in IntelliJ 18.2 too.
I use a different layout on my laptop keybopard an external keyboard. When coding, I usually use the external keyboard, so the ordering workaround solved the problem in both programs for me.

[rdrey]

This just happened to me in Ubuntu 19.04 with Gnome3, no KDE involved. Maybe we could replace the KDE in the title with Linux? Edit: also, with a German layout listed before US, the Undo / Redo keys were swapped. It looked like undo wasn't working at first. Maybe that'll get indexed by google and make debugging this a bit easier for someone :P

[Caleb-T-Owens]

Is it worth making a list of operating systems that, if they are affected by this bug that the "keyboard.dispatch": "keyCode", setting is applied by default or at least a check for Ubuntu to apply the setting because I imagine, as one of the more popular Linux distros, especially among newer Linux converts that quite a few people may find this to be a problem?

[Yuuki77]

I have a same issue in Mac OS

The actual layout when writing text, is correctly set to AU, but shortcuts are interpreted as JP.
but the issue was resolved when I changed the keycode dispatching settings.

Layout info:
{
	"id": "com.apple.inputmethod.Kotoeri.Roman",
	"localizedName": "Romaji",
	"lang": "en"
}

[cazdlt]

Same issue here using LATAM Keyboard Layout on Kubuntu 18.04 and VSCode 1.50.0

Apparently configuration is alright but key mappings are messed up, some keybindings just wouldn't work (eg. ctrl+} was being read as ctrl+]).

On VSCode:

"layout":
   "model": "pc101",
   "layout": "latam",
   "variant": "",
   "options": "",
   "rules": "evdev"
}, ...

On bash

$ setxkbmap -query
rules:      evdev
model:      pc101
layout:     latam

[dmgr]

The problem hits me as well. I have started VSCode when on regular QUERTY layout and changed to COLEMAC after when using external keyboard:

$ setxkbmap -query
rules:      evdev
model:      pc105
layout:     pl
variant:    colemak
options:    caps:capslock

For keyboard shortcuts VSCode still works like I have had a QUERTY layout.

"keyboard.dispatch": "keyCode" workaround works fine for me, I am not aware of any nasty side effects though.

[guitassinari]

I'm having the same issue using Ubuntu 20.04.

I'm using a notebook with an external US international keyboard. I frequently change between Brazilian Portuguese layout (for chatting) and English US layout (for coding). Everything works fine while I'm typing on VSCode. But keyboard shortcuts are always being executed as Brazilian Portuguese layout, which actually prevents me from running some of them.

@alexdima workaround fixed it for me.

$ setxkbmap -query
rules:      evdev
model:      pc105
layout:     us,br,us
variant:    ,,
options:    grp_led:scroll,grp:win_space_toggle

[Glitchy-Tozier]

@alexdima Yup, you're right, i'm on Linux (Mint).

For everyone else, as already mentioned, Settings → Application → Keyboard → "Keyboard: Dispatch" → select "keyCode" worked to fix this problem, but it would be best if it didn't occur in the first place.

EDIT: This also is a big problem with a family of German keyboards (NEO and it's derivatives). Quite a few of the movement-keys on layer 4 (can be seen here https://maximilian-schillinger.de/keyboard-layouts-neo-adnw-koy.html) are ignored by VS Code.

[RalfJung]

Same issue here, I recently started switching between DE and US keyboard layouts regularly (my laptop keyboard is DE but the external keyboard I am using is US) and vscode now acts up and interprets shortcuts as DE even when the active layout is US. All other applications work fine, so this must be something quirky about how vscode specifically receives keyboard input. I am using KDE.

Thanks for pointing me to the "keyboard.dispatch": "keyCode" workaround. :) Maybe that should be the default?

On Linux, we don't detect when keyboard layouts are changed while VS Code is running.

Restarting vscode does not help, so that is not the problem.

[Glitchy-Tozier]

Thanks for pointing me to the "keyboard.dispatch": "keyCode" workaround. :) Maybe that should be the default?

I agree that this would be very helpful for a lot of people.

[alexdima]

While we now detect the active keyboard layout correctly on startup, the issue #23690 still remains, i.e. we do not detect the active keyboard layout changes while VS Code is running.

To verify, you can use Ubuntu 20.04 and install additional keyboard layouts e.g. you can install German:

• chose a certain keyboard layout (e.g. German/Switzerland) using the picker in the top bar
• close all VS Code windows
• open an editor and run the command Developer: Inspect Key Mappings
• search for Shift+Digit7 and check that the Key is /
• chose another keyboard layout (e.g. English/US) using the picker in the top bar
• close all VS Code windows
• open an editor and run the command Developer: Inspect Key Mappings
• search for Shift+Digit7 and check that the Key is &