Disable kanata in linux TTY or work with custom vconsole keymap?

[noctuid]

This is a question, not sure if there is some feature that could be added to help.

I'm using a custom colemak keymap for ttys (KEYMAP in /etc/vconsole.conf). I don't use a display manager/graphical login manager and would prefer to just use the basic builtin keymap support in console instead of kanata, so that just in case anything goes wrong, I can still log in. Currently, I start kanata after X, though once it starts, it affects the layout on all ttys, making them essentially unusable without first stopping kanata. For example, colemak r now gives p since colemak p is in the QWERTY r position.

Not sure if you or anyone else has some idea for how to work around this.

[jtroo]

You could have a layer that is fully transparent, which you could switch to while on the ttys. Would need to make sure that the layer-switching key/combo is on a key that does not get remapped. For example I have a qwerty layer and a dvorak layer in my personal layout. I use the grave/backtick key, which isn't remapped, as a tap-hold where the tap is still grave and the hold is layer-while-held with layer-switching on the number keys.

[noctuid]

Nice, hadn't noticed that switch-layer switched base layers. I have plenty of keys I don't use/remap on my laptop keyboard, so that's definitely a good enough workaround.

It's a little unfortunate that the two don't work together though. Interestingly enough, kanata works fine on top of any sort of XKB remapping it seems (as long as they don't run after kanata start), but it never works with tty remapping.

[noctuid]

Actually this does not work for all keys. For example, muhenkan normally shows as keycode 102 in xev (94 for console). On this empty layer muhenkan, henkan, and katakana/hiragan all show as keycode 248/nosymbol and do not work to what I have them bound to in my console keymap. Any ideas?

[jtroo]

Ah, you've found a bug where there are missing key mappings in this file, which maps from OS codes to the keyberon library's codes.

https://github.com/jtroo/kanata/blob/main/src/keys/mappings.rs

A workaround that could be used while this bug is not fixed is to cycle between configurations - instead of having an unmapped layer, you could have a second configuration that unmaps all of the keys except for a few necessary to cycle back to the other configuration.

https://github.com/jtroo/kanata/blob/main/docs/config.adoc#live-reload

You could also try your hand at fixing this in that file and compiling yourself (and open a PR :) ) - I don't have a keyboard these keys to test myself. The mappings don't need to go to sensible names, it just needs to go to unused slots. Changes would probably be here:

kanata/src/keys/mappings.rs

Line 344 in 4738e4f

OsCode::KEY_MAIL => KeyCode::K0xAE,

kanata/src/keys/mappings.rs

Line 171 in 4738e4f

KeyCode::K0xAE => OsCode::KEY_MAIL,

And can see below for the keyberon names. Looking at this again, it seems like they should go to an IntlX or LangX key, but I'm not sure which ones.

kanata/keyberon/src/key_code.rs

Line 217 in 4738e4f

// According to QMK, 0xA5-0xDF are not usable on modern keyboards. The keys below are