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: