input: kitty: don’t fallback to the XKB symbol

When handling “generic” keys (i.e. keys not in the Kitty keymap), we
use the pressed key’s Unicode codepoint as “key” in the kitty CSI.

If we failed to convert the XKB symbol to a Unicode codepoint, we used
to (before this patch), fallback to using the XKB symbol as is.

This can never be correct... and it caused us to emit a meaningless
CSI for XKB_KEY_ISO_Next_Group, which confused e.g. Kakoune.
This commit is contained in:
Daniel Eklöf 2021-12-16 12:37:58 +01:00
parent 55c5f0590e
commit 4c5f53878e
No known key found for this signature in database
GPG key ID: 5BBD4992C116573F
2 changed files with 6 additions and 4 deletions

View file

@ -52,6 +52,8 @@
* Font size adjustment (“zooming”) when font is configured with a
**pixelsize**, and `dpi-aware=no`
(https://codeberg.org/dnkl/foot/issues/842).
* Key presses triggering keyboard layout switches also being emitted
CSI codes in the Kitty keyboard protocol.
### Security

View file

@ -1329,7 +1329,7 @@ emit_escapes:
else {
key = xkb_keysym_to_utf32(sym_to_use);
if (key == 0)
key = sym_to_use;
return false;
/* The *shifted* key. May be the same as the unshifted
* key - if so, this is filtered out below, when
@ -1349,6 +1349,9 @@ emit_escapes:
final = 'u';
}
if (key < 0)
return false;
xassert(encoded_mods >= 1);
char event[4];
@ -1365,9 +1368,6 @@ emit_escapes:
size_t left = sizeof(buf);
size_t bytes;
if (key < 0)
return false;
if (final == 'u' || final == '~') {
bytes = snprintf(p, left, "\x1b[%u", key);
p += bytes; left -= bytes;