search

jtroo / kanata

Improve keyboard comfort and usability with advanced customization
GNU Lesser General Public License v3.0
2.16k stars 111 forks source link

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

Closed noctuid closed 1 year ago

noctuid commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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:

https://github.com/jtroo/kanata/blob/4738e4f37d0ada601b128d5a138cd83c22c96ecb/src/keys/mappings.rs#L344 https://github.com/jtroo/kanata/blob/4738e4f37d0ada601b128d5a138cd83c22c96ecb/src/keys/mappings.rs#L171

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.

https://github.com/jtroo/kanata/blob/4738e4f37d0ada601b128d5a138cd83c22c96ecb/keyberon/src/key_code.rs#L217