Vscode: 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": "¿"
    },



md5-0334f2aebc4a64630b65281f8fb48e08



    "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

[PinkFlufflyLlama]

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.