keyboard protocol: clarification on locked modifiers

[dnkl]

The keyboard speification doesn't really go into detail on how locked modifiers (e.g. CapsLock and NumLock) should be handled.

Regarding modifers, it does say that "The modifiers optional parameter encodes any modifiers pressed for the key event". "Pressed", not "effective", or "enabled".

Going on that alone, I would surmise that we should only report e.g. Caps and Num-lock in the key event, if those keys are actually pressed.

That is however not what I'm seeing in Kitty (on Linux, Wayland). There, at least NumLock is included in the modifier list of the key event whenever another non-consumed modifier is enabled.

For example, with \e[>1u, pressing Space while NumLock is enabled (not pressed) results in a normal space. But e.g. Ctrl+Space results in 32;133u. I.e. Ctrl and NumLock.

[kovidgoyal]

IIRC, kitty does not currently follow the spec exactly in that lock keys are only reported when some other modifier is present as well. I think this was done to make it easier for programs that kind of support CSIu to not get confused by the lock keys.

[kovidgoyal]

Or maybe I am misremembering, need to check when am at my dev machine.

[kovidgoyal]

Checking, I see caps_lock+space reported as expected when the caps_lock is engaged and the space key is pressed.

[dnkl]

Thanks for the quick fix/update! I'll update foot accordingly.

[rockorager]

Just to clarify this:

The intent is that with even \e[>1u, locked modifiers should be present for any keypress? Meaning if a user has numlock engaged, then the effect is that all keypresses are sent as escapes (since we need an escape to send the numlock mod). Same for capslock - any capslock key would then be sent as an escape sequence.

Do I have that correct?

[kovidgoyal]

No, that's precisely the use case I was thinking of when I said kitty doesn't follow the spec precisely. The lock modifiers are not reported for keys that dont already have a CSIu encoding. This is to make this mode useable in programs that still want to mostly use legacy key handling. So having caps lock engaged and pressing a will just send A. But, having caps lock engaged and pressing an function key does report the modifier since the function key is already encoded as an escape code not as a text.

So while technically this kind of violates the promise of this mode to disambiguate all keys (shift+A and caps_lock A are the same), its worth it for backwards compat. Easy to check with printf "\e[>1u"; showkey -a