kitty kbd: ISO_Level3_Shift not recognized as a modifier

[dnkl]

It looks like notcurses doesn't recognize the ISO_Level3_Shift modifier (and most likely, ISO_Level5_Shift too): https://sw.kovidgoyal.net/kitty/keyboard-protocol/#functional-key-definitions.

Instead, it treats the key code as a unicode codepoint:

I believe AltGr is the key usually mapped to ISO_Level3_Shift . I don't have a physical key to ISO_Level5_Shift, and have no idea which key it typically corresponds to.

(I guess simply calling them ISO_LevelN_Shift, instead of AltG, is fine too).

notcurses 3.0.0 on foot 1.10.2-28-g72a99554 (Linux 5.11.16-artix1-1)
68 rows (15px) 161 cols (7px) 1020x1127 rgb+256 colors
gcc-11.1.0 (LE)
terminfo 6.3.20211021 libdeflate 1.8 GPM n/a
avformat 58.76.100 avutil 56.70.100 swscale 5.9.100 avcodec 58.134.100

[dankamongmen]

no idea what these keys are, but i'll look into it =]

[dnkl]

On European(?) layouts, AltGr is mapped to ISO_Level3_Shift, and provides a third shift level for keys. For example, my 2 key can generate four different symbols: 2, ", @ and ².

2 and " are the normal un-shifted and shifted (i.e. using Shift) symbols.

@ and ² are produced by holding AltGr and AltGr+Shift.

No idea what ISO_Level5_Shift is, but guess it's used in some XKB layouts to provide yet another shift level.

[dankamongmen]

only four shift levels? we must go deeper

[dnkl]

[dankamongmen]

we now have the necessary definitions, and ought be mapping them up in kitty_functional(). i don't think we're yet treating them as modifiers, though. if you could verify that we properly register the keypresses, i'll move forward with the latter.

[dnkl]

Getting "Special [...] 'unknown'", which I suspect is the expected result? I've only been able to test ISO_Level3_Shift, but don't see why ISO_Level5_Shift shouldn't work as well.

[dankamongmen]

7107c90 should have it saying the correct thing, sorry

[dankamongmen]

so these are modifiers, and probably ought be reported with [acsX], huh?

[dnkl]

Works!

[dnkl]

so these are modifiers, and probably ought be reported with [acsX], huh?

Hmm, not sure what you mean? Is that a literal X?

In any case, I don't see modifiers being reported differently, in neither foot nor kitty.

[dankamongmen]

sorry, so there's shift, ctrl, and alt; should l[35]shift be treated like a modifier? i.e. ought i be reporting with 'a' that level 3 shift was being held? so the [acsX] prefix on each line would be [acsX35]

[dankamongmen]

basically do i need add l3shift and l5shift to my ncinput struct:

diff --git include/notcurses/notcurses.h include/notcurses/notcurses.h
index 0e44b8e76..23cf1df39 100644
--- include/notcurses/notcurses.h
+++ include/notcurses/notcurses.h
@@ -1120,6 +1120,8 @@ typedef struct ncinput {
   bool alt;          // was alt held?
   bool shift;        // was shift held?
   bool ctrl;         // was ctrl held?
+  bool l3shift;      // iso level 3 shift (altgr)
+  bool l5shift;      // iso level 5 shift
   // FIXME kitty protocol also exposes hyper, meta, caps_lock, num_lock
   enum {
     NCTYPE_UNKNOWN,

are these "Hyper" and "Meta"?

[dnkl]

are these "Hyper" and "Meta"?

No, I don't think so. There are other keys (Hyper_{L,R} and Meta_{L,R} that map to the Hyper and Meta modifiers.

The kitty protocol's encoding of modifiers includes hyper and meta, but not the ISO_LevelX_Shift shift states. So no, I don't think you should treat them as modifiers.

On the terminal side (when we generate the CSI), the ISO_LevelX_Shift modifiers are handled slightly different. For example, Alt+Shift+2 would result in a CSI where the base key is '2'. But AltGr+Alt+2 would result in a base key of '@'.

[dnkl]

One important thing here is that there's a very distinct difference between a modifier being enabled, and a specific key being pressed.

For example, there's only one Control modifier. But there are two Control keys (Control_R and Control_L). They just so happen to enable the Control modifier (in most layouts).

So, ISO_Level3_Shift could be mapped to the Hyper shift level. But it's not for you to bother with :) The terminal will (through the current XKB layout).

Put another way, you shouldn't enable/disable modifier state when seeing modifier key press/release events. I.e. just rely on the encoded modifier state in the CSIs.

Clear enough? :)

[dankamongmen]

sounds good!