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 5F692260580 for ; Thu, 25 Jun 2026 21:40:29 +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=1782423630; cv=none; b=mL9M7Cyv/GJbNnv3ZtnLzj3fJkKFdUD9zvQHiIFhaaXkjm1LjcDKt2e8t2V08wE6ayYVJ2ozYVdvsP/x1I3OAo4/mZfwcagCGNhh7qx5Gt+pXiJKGLKlF0PbgCUSlf4jaa3MBqV2Ba0/hQ7/ZP3lQ/v6FFeDMIC2NEEh5BZH3+M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782423630; c=relaxed/simple; bh=IoX8lpp0XSx+0aoZXVjrm+SdiMoOH2/zL6KiYhC39yE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dQilQRefzk/vGFXOlH2h6azkzy6wL69eqMvgbLUdXF/m+nDQ606buplSqG9V6p1irAn69P3HcFPibTpqXmrKdzLsXXMfi5eau9BdoGACVJMs5bFOatAclHKDPmefV8l8wEtG8myQAaMsQfdOeDst15BqXbsz1meNCzKfrNcyNAk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UUitfShS; 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="UUitfShS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EEF7C1F000E9; Thu, 25 Jun 2026 21:40:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782423629; bh=JldWct8+CZC1p/iHagQQect2VIMZZS8VdTkO4NkPHUE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=UUitfShSyVqNdAqhIq424hOHW8Kfsmxrl5o1D25YFYtlMP5UEHNHWFdrUVPOEThGJ LxrrAxVP2oge1t4PXgLoeZvNoHtFL4vhP4h1wFtYlu1agYJQPRksJBly17BvfthxB2 AXfoe0eK1rvTut3X+E5Nb5xiVeNZf5nzi6N0BJccxC1HDpzDbs9ryweEb9FOYwe+FC u/ZR/svBSp4qCHklpLHR/OeMu59hKlyPjdnH8CkSt/v3KrFb23IsvwGwVMD4bPjc+1 693pfmXk8Ca9wM9x4W7rDTnH0+OEsj3Fdxnm3L6JjeWbSthSdRzkKVJUJfn5DEfi7a c8i3/STTAyFOA== Date: Thu, 25 Jun 2026 23:40:23 +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: On Thu, Jun 25, 2026 at 12:28:44PM -0400, Nicolas Pitre wrote: > On Wed, 24 Jun 2026, Alexey Gladkov wrote: > > > 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`. > > That mechanism is untouched. KT_FN strings behave exactly as before and > can still be placed in any position. KT_CSI does not replace them; it is > an additional keysym type alongside them. I guess I didn't mean it that way. I didn't say you broke KT_FN. You broke KT_CUR. > > 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. > > I think this conflates two separate things, and the one that matters > isn't actually constrained. > > 1. Csi_F1 does not take over the modifier columns. The kernel only falls > back to the plain entry when the modifier-specific slot is empty. > From c1d2deb6492f ("vt: add fallback to plain map for modifier-aware > key types"): > > if (shift_final && keycode < NR_KEYS && > (!key_map || key_map[keycode] == K_HOLE) && key_maps[0]) { > ... > if (type - 0xf0 == KT_CUR || type - 0xf0 == KT_CSI) > key_map = key_maps[0]; > } > > As soon as you bind, say, shift keycode 16 = Foo, that slot is no > longer K_HOLE, the condition is false, and your explicit binding is > used -- the automatic encoding never runs. The commit log says as > much: "Explicit modifier bindings still take precedence - the > fallback only triggers when the modifier-specific entry is empty." So > the keymap author keeps full control; Csi_F1 in the plain slot is > merely the default for the modifier combinations you leave unbound. > > 2. What you genuinely cannot do is make the Csi_F1 keysym emit an > encoding that disagrees with the keys physically held -- e.g. get the > Alt form ESC[11;3~ out of a Control press. That is deliberate: k_csi > reads the live modifier state, exactly like xterm, foot, kitty and > every other terminal that speaks these sequences. But if you want a > fixed, hand-picked sequence on a given modifier, that is precisely > what KT_FN strings are for, and they still work in any column: > > string AltF1 = "\033[11;3~" > control keycode 16 = AltF1 > > So nothing that was possible before is lost. KT_CSI is opt-in and > purely additive: it trades manual per-column control of a CSI > sequence's modifier field (which strings still give you) for not > having to enumerate -- and exhaust func_table with -- one string per > modifier combination. That is the whole reason the kernel side > exists. > > Nor is this a new departure for the keymap model: KT_CUR arrow keys > already derive their output from runtime state (VC_CKMODE), as does > KT_PAD (VC_APPLIC), and KT_CONS/KT_SHIFT/dead keys have never been > userspace strings either. A keysym type with kernel-defined, > state-dependent behavior is the norm, not the exception; KT_CSI > simply joins that set. Yes, the old mechanism (KT_FN) still exists and can still be used. What I'm trying to say is that Csi_* significantly changes the user experience. If now the user controls what will be in which position. However, Csi_F1 changes its output depending on the active modifiers. KT_CONS is a bad example. KT_CONS is just a separate type. I can even assign it to Ctrl-X to switch to my especially favorite console. I can use Console_63 anywhere in the keymap, and it will always take me to console 63 and it will work regardless of any active modifiers. It's the same story with KT_PAD/KT_DEAD. You can put them anywhere you like in the keymap and they will behave the same way. That's not the case with KT_CSI. Let me give you another example. In the last release, I implemented initial support for converting xkb keymaps to kernel keymaps. The conversion generates a keymap on the fly from xkbcommon. xkbsupport encodes layout/group using KG_SHIFTL and KG_SHIFTR. So a single combination cycles through several layouts: - group 1: plain - group 2: shiftl - group 3: shiftr - group 4: shiftl | shiftr (this idea isn't new. It has been used in debian for a long time in the console-setup, and also in ubuntu and some others). This makes it impossible to use Csi_* in it, since Csi_F1 in the second layout will be recognized by the kernel as "F1 with Shift". And this seems to apply not only to KT_CSI, but also to the existing KT_CUR: k_cur() uses the same csi_modifier_param(). If the arrows end up in a layout group other than the first one via shiftl/shiftr, an extra Shift modifier will be generated in the escape sequence. And that's a real regression in userspace. I hope I've made my concerns more clear. -- Rgrds, legion