From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 27F4539733E for ; Wed, 24 Jun 2026 08:51:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782291116; cv=none; b=BA5NaRb0zv+SOGcJVf2KaKbppPXaB1PBurJbBN0QP5WIoH0krQW9S7RcGdLmK/yOtsOGUccHPMqiOpqjA+ZsMuTgAQpQeoLIZqwLXztJUKEEVmI8JFVNGnbX/nLANsX1CKyI6NokuKNMhyHn7irug92mxBZzelB8esrqBWnNT3I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782291116; c=relaxed/simple; bh=CCXHKd3bLmjGKgarK5bKqcYQ7Tjgv6c332ykt5uuU1k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=a1hSCQh/We1n0ei5Fthbu8FyLarS3YAKRrEpYbanw6kwn9CwRxKZd+dZcp5klZbTTUZaGnuQYkRqoXCr7D5F6Bi4tLD5z3Y/XKoWZlBzB+Y1TzxlwKYUKgHJGKM86Lw2JKj8VDmU1/mphRPmtD+jZXrXPtR0e/4mbCRvOM1dz6Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oO7XYiGP; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oO7XYiGP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C85A21F00A3A; Wed, 24 Jun 2026 08:51:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782291114; bh=VlCDNq+yrmzU86kEZlBjEf6OaWeVBQWm3Bgw8W1UzJU=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=oO7XYiGPQxljHRhGESbUVIUfuVNlFhDdCH5BxuxGncw7zMan7DiFt+Du9s6+9oH8h PSvMNfCWn5MyMGMeCAexIzj8ZUNcIN7r3gNAM9x8TR2npFvm7c7RaVJNh57HQej3Wl xH8leYJSp0L5tfrHOE26taZC4n22e5mMPfTXZNH3STWG9+gpBov7qDCZ+1XvgQHPGT waZ3wUm5hyoSQen7olvrjXiqMaqMVo1N+HuzbyedZXebRJUa0yUG0rj2kqY7AYdzCO 2sE0DSgWp32fmHiL1YTWnuyv16GEYSkYRaLgRpWpb3Bs3lfYmRLQiSLjK3T/GmHEP4 rXhvIt9pm+G1g== Date: Wed, 24 Jun 2026 10:51:49 +0200 From: Alexey Gladkov To: Nicolas Pitre Cc: kbd@lists.linux.dev, gladkov.alexey@gmail.com, Greg Kroah-Hartman Subject: Re: [PATCH v2 0/3] support for the kernel 7.1 modifier-aware KT_CSI keysym type Message-ID: References: <20260623224858.3249421-1-nico@fluxnic.net> Precedence: bulk X-Mailing-List: kbd@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260623224858.3249421-1-nico@fluxnic.net> 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