Linux: xcape compatibility - use virtual-key codes for processing keybindings

[Dreomite]

For now, switching to non-English keyboard layout or pressing Caps Lock renders Oni2 unusable (terminal Vim legacy). Perhaps, using virtual-key codes just like VSCode (and other modern text editors) would be a good idea? So no matter which layout is being used (EN QWERTY, EN DVORAK, RU ЙЦУКЕНГ, FR AZERTY, etc.), and whether Caps Lock pressed or not, keybindings are always processed correctly.

Note that VSCode implementation still has some flaws.

[jcorbin]

Seems related to #520

[bryphe]

This should be addressed now in the move from GLFW -> SDL2

[mrkishi]

I'm still unable to use <esc> on my Windows machine.

I have caps-lock remapped to esc through native Windows keyboard layout (so: 0x3A capslock 🡒 0x1B VK_ESCAPE). This works system-wide while Oni logs:

[INFO] Input - got keydown - text input:true
[INFO] Input - keyPressToString - key name: CapsLock
[INFO] Input - keyPressToString - processing keycode: 1073741881|CapsLock
[INFO] keyPressToString - key blocked: CapsLock

It seems this is an issue with SDL's key events: they don't seem to be translated through the system's keyboard layout. Testing an empty SDL project with event.key.keysym.sym I also get capslock instead of esc.

[Dreomite]

I thought Bryan meant that it's not yet but will be addressed any time soon. But in case I got it wrong, I haven't noticed any keypress-related behavioral changes in recent versions of Oni2 in my Arch machine. Still can't operate it with Caps Lock on and with non-QWERTY layouts.

[bryphe]

Ah, sorry I wasn't clear! The SDL2 changes are actually in, and we are now using the SDL_Keysym w/ the virtual keycode to process input. So in theory at least, we are now doing this 😬

Although - seems like there are still bugs (either in our integration, or in SDL2's handling)!

@Azumgi - which non-QWERTY layout are you using? I just tested with dvorak via setxkbmap us -variant dvorak and it seemed to work as expected for basic cases (opening quickopen, switching to insert mode, etc). I also tried remapping escape via setxkbmap -option caps:escape, and this worked as expected - caps lock worked via escape.

Do you have a specific repro I can try? Keyboard layout + keystrokes you tried? Are you using setxkbmap or another way to set the layout? Hopefully we can get this unblocked!

[bryphe]

(And following up with @mrkishi on Discord to get more info on how CapsLock is being re-mapped on Windows)

EDIT: Looks like the Windows keyboard layout is being created with http://www.kbdedit.com/

[LeonB]

I'm using xcape to map capslock to ctrl and escape and I'm having similar issues. Capslock mapped to escape work, Capslock mapped to Ctrl doesn't work. I tried searching for some onivim log but I can't find it?

[moljac024]

Having the same issue in Gnome 3. Remapped caps lock to control. Trying to use caps lock as control doesn't work in oni2

[Liblor]

I'm using xcape to map capslock to ctrl and escape and I'm having similar issues. Capslock mapped to escape work, Capslock mapped to Ctrl doesn't work. I tried searching for some onivim log but I can't find it?

I can confirm, I have the same issue

[Dreomite]

@bryphe I'm sorry for leaving a partially wrong comment and not answering/clarifying anything afterwards. Got some IRL problems to deal with, so I had to cease almost all my online activities for a couple of months.

So, I played with the new changes a little. While switching from GLFW to SDL2 was a big improvement, Oni keypresses handling still have some inconveniences.

1. [Linux specific?] The Revery.Key.Keycode.getName method in keyPressToString uses new SDL2 backend which doesn't detect dynamic layout switches.

   For example, if you set en and ru layouts as

   setxkbmap -layout "us,ru" -option "grp:alt_shift_toggle"

   then run Oni, then press shift+alt, and then press л, that method will return K, because it did not see layout switching and still think it's en layout. Or vice versa.

   SDL2 picks active layout when:

   • SDL2 app is launched
   • (right after) setxkbmap is called

   It's easily reproducible with bare bones SDL2 application which prints SDL_GetKeyName output.

   This leads to first inconvenience:

   oni2/src/Store/InputStoreConnector.re

   Lines 207 to 213 in 7981176

   	let updater = (state: State.t, action: Actions.t) => {
   	switch (action) {
   	| KeyDown(event) =>
   	let isTextInputActive = isTextInputActive();
   	event
   	|> Handler.keyPressToCommand(~isTextInputActive)
   	|> handleKeyPress(state);

   While handleKeyPress works with actual typed character, keyPressToCommand deduces character based on initially selected layout + keycode. This can lead to confusing situations, such as:

   • ru,us layout, switched to us
     • Pressed: k; Vim receives: k
     • Pressed: Ctrl+k; Vim receives: C-л
   • us,us(dvorak-intl) layout, switched to us(dvorak-intl)
     • Pressed: t; Vim receives: t
     • Pressed: Ctrl+t; Vim receives: C-k

2. Active Caps Lock still renders Oni unusable. Perfectly, I should be able to use h,j,k,l and other mapped keys even with Caps Lock on.

3. Active non-Latin layout still renders Oni unusable. VSCode, for example, solves this by using predefined maps to convert a bunch of specific layouts to QWERTY to be able to use keybinds. However, they also have the same dynamic layout switching problem.

Maybe (2) and (3) are irrelevant to Oni, I'm not sure.

[d-r-q]

Atom (with vim-mode-plus) is the only editor where non-latin layouts works seamlessly out of the box.

Also I would like to highlight the case of punctuation commands in normal mode (i.e. $) - in russian layout it mapped to ; and while it's possible to configure ST3 & Neovim to work in russian layouts in general, I believe, that it's impossible to configure them to handle such commands. It would be great, if Oni will support such case

[ianelletson]

I use Microsoft Powertools (formerly autohotkey) to remap my CTRL and ALT on my keyboard. Omnivim doesn't detect these remaps nor does it detect the keys' original keycodes. This means no shortcuts work, at all, rending Omnivim entirely unusable.

This is on Windows 10. Is there going to be any resolution to this issue or should I refund?

[bryphe]

@ianelletson - I worried about this getting buried so I opened a new issue to track: #2164 I suspect there's different root causes, per-platform, so wanted to make sure this didn't get lost. Most of the investigation on this particular issue has been related to Linux (setxkbmap, etc)

Is there going to be any resolution to this issue or should I refund?

All the issues marked daily editor blocker are on our radar to fix. Just a matter of timeframe - there may be a quick fix, or it might involve a more in-depth revamp of our input layer (in other words... if SDL2 doesn't support it - will be more work!) If you don't want to wait - happy to refund you, just send me an e-mail (the one on my github profile is perfect).