Re: [PATCH v2 0/3] support for the kernel 7.1 modifier-aware KT_CSI keysym type

[Alexey Gladkov <legion@kernel.org>]

On Tue, Jun 23, 2026 at 06:48:55PM -0400, Nicolas Pitre wrote:
> Linux kernel 7.1 introduces modifier-aware escape sequence generation
> for the console keyboard:
> 
>   4af70f151671 ("vt: add modifier support to cursor keys")
>   5cba06c71c71 ("vt: add KT_CSI keysym type for modifier-aware CSI sequences")
>   c1d2deb6492f ("vt: add fallback to plain map for modifier-aware key types")
> 
> The new KT_CSI keysym type produces xterm-style CSI tilde sequences
> (ESC [ n ~, or ESC [ n ; mod ~ when Shift/Alt/Control are held) with
> the modifier state encoded at runtime. A single plain map entry covers
> all modifier combinations, instead of consuming a func_table string
> slot per combination.

Here's what's bothering me. These patches disrupt the logic behind how
keymaps work.

Previously, userspace determined which modifier key should generate which
sequence. We had `string F1 = "\033[[A"` and use it in any position:
`alt keycode 16 = F1`.

After your patches, modifier handling has been moved to the kernel.
The escape sequence `ESC[11;03~` will be generated only if Csi_F1 is set
to `alt keycode 16 = Csi_F1`. So, for Csi_*, the modifier has taken on
a special meaning. I can't bind the Alt+Csi_F1 sequence to any other
modifier key.

> This series adds the userspace counterpart:
> 
> Patch 1 teaches libkeymap the Csi_* keysym names (Csi_Home, Csi_End,
> Csi_Delete, Csi_Insert, Csi_PgUp, Csi_PgDn, Csi_F1..Csi_F20, matching
> the kernel UAPI values) and documents modifier-aware keys in
> keymaps(5).
> 
> Patch 2 adds a contrib script (with optional systemd unit) that
> reconciles the "linux" terminfo entry with the loaded keymap: F1-F5
> in CSI form and Backtab as ESC [ Z are not what the stock terminfo
> entry expects.
> 
> Patch 3 keeps the default keymaps on their traditional bindings and
> adds an opt-in overlay (linux-keys-csi.inc) that switches the function
> and navigation keys to the Csi_* keysyms. The boot script applies it
> only when the running kernel supports KT_CSI, so nothing changes on
> older kernels.
> 
> Changes since v1 (addressing Alexey's review):
> 
>  - Patch 1: bump NR_TYPES in summary.c so KT_CSI appears in
>    "dumpkeys --long-info".
> 
>  - Patch 3: reworked from an in-place conversion (which broke pre-7.1
>    systems) into the opt-in overlay described above.
> 
> v1: https://lore.kernel.org/kbd/20260612014857.1668427-1-nico@fluxnic.net
> 
> Tested with make check, a staged "make install" (overlay installs and
> resolves by name), and the terminfo script exercised live on Fedora 43.
> 
> Nicolas Pitre (3):
>   libkeymap: add support for KT_CSI keysym type
>   Add kbd-terminfo-fixup script and systemd service
>   keymaps: add opt-in CSI overlay and load it when the kernel supports
>     it
> 
>  .gitignore                                   |   1 +
>  Makefile.am                                  |  16 +
>  configure.ac                                 |  18 ++
>  contrib/kbd-terminfo-fixup                   | 303 +++++++++++++++++++
>  contrib/kbd-terminfo-fixup.service.in        |  13 +
>  data/keymaps/i386/include/linux-keys-csi.inc |  83 +++++
>  docs/man/man5/keymaps.5                      |  77 +++++
>  src/libkeymap/ksyms.c                        |   3 +-
>  src/libkeymap/summary.c                      |   2 +-
>  src/libkeymap/syms.ktyp.h                    |  39 +++
>  tests/data/keymap0-summary.txt               |  26 ++
>  11 files changed, 579 insertions(+), 2 deletions(-)
>  create mode 100755 contrib/kbd-terminfo-fixup
>  create mode 100644 contrib/kbd-terminfo-fixup.service.in
>  create mode 100644 data/keymaps/i386/include/linux-keys-csi.inc
> 
> -- 
> 2.54.0
> 

-- 
Rgrds, legion