Replies: 1 comment 1 reply
-
The table you mentioned is AFAIK the exact list of named keys supported by Keymapper for either input or output. You don't have to have the key I just added this to my config and I then then output
If this is not what you meant, could you expand on what you'd want to be able to output? Keymapper can use keys outside of that table for both input and output using keycodes. For instance, I can do:
..and then monitor on Keymapper's virtual input device using
The name |
Beta Was this translation helpful? Give feedback.
-
Currently, unless I'm missing something, I can't seem to map keys that actually exist, but not on my particular keyboard. For example, I like to map the high F keys for specific vim bindings. I have to do some convoluted stuff with kitty term currently, because keymapper will only map keys that exist on my actual keyboard.
I propose allow output mappings of keys that exist in the protocol outlined here, whether the keyboard currently used has the keys or not. It seems that adoption is becoming widespread and that is probably a safe baseline. Or at least this table, regardless of the keys existence on my keyboard.
Basically, this is the difference between mapping synthetic keys that no other programs will understand, such as keymapper's VirtualX keys, and synthetic keys that exist in the globally shared key space.
Beta Was this translation helpful? Give feedback.
All reactions