kitty keytester#5877
Conversation
|
@zeertzjq Eww, this is what I get for Ctrl-Shift-a:
WTH? Edit: fixed numlock state (which is currently missing in xterm.js) |
|
Hmm, unmapped default mappings still interfere with key reporting? It works if I use ones that don't have default mappings in kitty:
Or, if I add this to kitty config: Then all of the Ctrl-Shift combinations are reported properly... |
|
@zeertzjq Thanks for the pointer. From an app developer perspective - which are the useful flag combinations? I would start with "Disambiguate escape codes" (1) and map my keyboard in a json file. Then we can fill it with other useful combinations and prolly other keys (like from mac keyboards). |
|
From reading the spec I get:
Here let's never set flags 1 and 8 together (since 8 implies 1). And with addition that "Report event types" (2) doesn't make sense without disambiguating escape codes (1 or 8) as mentioned in kovidgoyal/kitty#9999, the flag combinations that make sense are:
|
|
@zeertzjq Did a first mapping of my keyboard for mode 1 and with all modifiers off. Since my layout is german qwertz I added the code in brackets where it differed from the reported key (taken from I think we don't have to repeat the whole set for all modifier states but can reduce the complexity to proper modifier bits stacking and just do a few 2nd and 3rd shift peeks. Otherwise creating the maps gets really exhausting with the keytester script (except for numpad report changes). |
|
Already suspected this - for full support of mode 8 we gonna need keyboard layout support in xterm.js to correctly unshift the code being sent. Chrome knows this: const layout = await navigator.keyboard.getLayoutMap();
const code = e.code; // e.g., "KeyA", "Digit1"
const unshifted = layout.get(code); // returns string for that physical key (unshifted)All other browsers don't implement this interface for security reasons. Maybe we could create an addon with custom qwerty, qwertz etc. mappings. The addon could ask for the correct mapping on terminal startup, if The issue goes further, mode 2 is also affected by this - basically any mode, that sends sequences with the key value as the unshifted base character. Which makes the keyboard protocol layout/localization dependent - it does not really report keys but layout base chars. This is ok for a TE that has access to the layout information, but we don't have that outside of chrome. Also MDN flags @zeertzjq Does neovim make use of the sequence form of unicode reporting keys in some ways? I wonder now, why the protocol does not refer to key identifiers reporting real keys instead of layout mappings. It carries the layout problem over to app side. An app that wants to apply its own custom key layout would have to do an extra indirection of |
I'm not sure if I understand the question, but I remember some related bug reports: |
- layout detector - browser helper to create layout maps - DE, ES, GR, RU, US maps
|
With the last commit I have implemented a basic layout detector, that can be plugged into xterm.js. The hard part is providing sufficiently many layout mappings. For this I created a browser helper page to gather the needed information by pressing through all keys (preview). The user feedback in case the layout is still undetermined is not done here. |
|
Removed the layout detector stuff as it gets too big. Furthermore for native app integrations For pure browser integration I gonna create an extra package with all xkb keyboard maps. This then can be used in an addon. |
|
Have created a package with the xkb keymaps here: https://github.com/jerch/xkb-layouts |
|
@jerch would this be a good thing to live in the helper CLI instead? https://github.com/xtermjs/vtc |
|
@Tyriar Yes the key tester with its tons of data files is prolly better suited for outside of xterm.js to not bloat the repo further and further. When I am done with the basic basic test strategy I can move the stuff over. The layout maps need to be a separate installable package, so a later mainly browser only addon can use them. This is a huge follow-up undertaking, without that we basically cannot offer kitty keyboard protocol support in browser integrations, as we never can report the right keys in the sequence form. The keyboard protocol impl needs an API point for injecting a keyboard layout provider, but for that I have no clear picture yet. |
3 participants
keytester for the kitty protocol.
draft for now, in the end the keytester should collect the data for different keys and events in different states and export them in a json file for automated testing.