tty: Ctrl+Alt+Shift+F1..F6, and VT_SETMODE actually works

Alt+1..6 was a worse choice than the Alt+F-keys it replaced, and the reason
is the one that matters: anything the kernel swallows is taken from every
program that will ever run here, permanently.

Alt+<digit> is Meta-digit. zsh's own line editor binds it as digit-argument --
Alt+1 Alt+2 x repeats x twelve times -- and every readline editor does the
same. Yesterday's chord broke that system-wide, which is exactly the failure
mode of picking a chord applications want.

Working the whole space instead of one axis of it:

  the HOST takes    Alt+F4, Alt+F2, Ctrl+Alt+F1..F6
  APPLICATIONS want Alt+anything (Meta), Ctrl+letter, Ctrl+Shift+digit
                    (Ctrl+Shift+2 types ^@), bare F-keys
  the LAYOUT wants  AltGr+letter -- Polish diacritics

Ctrl+Alt+Shift+F1..F6 is in none of those sets. Display managers bind the same
chord without Shift, so adding it steps out of the host's way, and no terminal
application binds a triple-modified function key.

Which chords actually reach a guest was measured rather than assumed: a
temporary probe in kbdgetc logged every modified keypress and QEMU's sendkey
fired each candidate at it. Everything reached the guest, Ctrl+Alt+F2
included -- so that conflict is the host's display manager, not QEMU. The same
probe corrected an earlier claim: `sendkey altgr-2` produces no event at all,
so the previous commit's "AltGr+2 did not fire" was never actually tested.

And the escape hatch is real now. VT_SETMODE was accepted and ignored, so a
program could ask to own the chord, be told yes, and still not get it.
VT_PROCESS genuinely stops the kernel switching. Together with the EVIOCGRAB
path -- which kbdgetc already checks before the chord is recognised -- there
are three honest layers: nothing, VT_PROCESS, exclusive grab.

What VT_PROCESS still does not do is the VT_RELDISP handshake; struct vt_mode
carries relsig/acqsig for when Schcom needs to release the GPU before the
screen changes hands.

Verified by screendump hash: Alt+2 reaches zsh as Meta, Ctrl+Alt+F2 and
Ctrl+Shift+F2 leave the screen untouched, Ctrl+Alt+Shift+F2 switches.
schfs-check passes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
This commit is contained in:
Nexoniarz 2026-09-13 13:05:43 +02:00
commit fe2f5e1bf8
9 changed files with 170 additions and 58 deletions

View file

@ -36,32 +36,40 @@
#define KEY_INS 0xE8
#define KEY_DEL 0xE9
// Alt+1..Alt+6 -- switch virtual terminal.
//
// Above 0xFF deliberately. kbdgetc returns an int and consoleintr takes one,
// and every value that fits in a byte is already either a character or a
// UTF-8 continuation byte. A chord that collided with one of those would be
// typed into the terminal instead of switching away from it.
// Alt+1..Alt+6 -- switch virtual terminal.
// Ctrl+Alt+Shift+F1..F6 -- switch virtual terminal.
//
// Above 0xFF deliberately. kbdgetc returns an int and consoleintr takes one,
// and every value that fits in a byte is already either a character or a
// UTF-8 continuation byte. A chord that collided with one would be typed into
// the terminal instead of switching away from it.
//
// The number row rather than the function keys, and left Alt rather than
// either, because everything else was already taken:
// Choosing this took two wrong answers. Anything the kernel swallows is taken
// from every program that will ever run here, permanently, and the obvious
// candidates are all spoken for on one side or the other:
//
// Alt+F4 the host window manager closes the QEMU window
// Alt+F2 GNOME and KDE open a run dialog
// Ctrl+Alt+F1..F6 the host switches its *own* virtual terminals
// AltGr+anything Polish diacritics, and AltGr is Ctrl+Alt on some setups
// Ctrl+Shift+key widely bound inside applications
// HOST takes it, before the guest ever sees it
// Alt+F4 the window manager closes the QEMU window
// Alt+F2 GNOME and KDE open a run dialog
// Ctrl+Alt+F1..F6 the display manager switches its *own* terminals
//
// Alt+digit survives all of that. It is matched exactly -- Ctrl+Alt+1 and
// AltGr+1 do nothing -- so a chord meant for the host never reaches here.
#define KEY_ALT_F1 0x120
#define SCAN_1 0x02 // 1..6 are scancodes 0x02..0x07
// APPLICATIONS want it, and would never get it again
// Alt+<anything> Meta. zsh's own line editor binds Meta-digit as
// digit-argument; every readline editor does too
// Ctrl+<letter> control characters
// Ctrl+Shift+<digit> types a character -- Ctrl+Shift+2 is ^@
// F1..F6 alone help, and whatever a full-screen program wants
//
// THE KEYBOARD LAYOUT wants it
// AltGr+<letter> Polish diacritics, and on some setups AltGr is
// delivered as Ctrl+Alt
//
// Ctrl+Alt+Shift+F1..F6 is in none of those sets. Display managers bind the
// same chord *without* Shift, so adding it steps out of the host's way, and
// no terminal application binds a triple-modified function key. Four keys is
// more than one wants to press, which is correct for something done rarely
// and deliberately -- and `chvt N` is there for everything else.
#define KEY_VT_SWITCH 0x120
#define SCAN_F1 0x3B // F1..F6 are scancodes 0x3B..0x40
// C('A') == Control-A
#define C(x) (x - '@')

View file

@ -133,6 +133,21 @@ struct rlimit {
#define VT_ACTIVATE 0x5606
#define VT_WAITACTIVE 0x5607
// VT_SETMODE modes. VT_AUTO is the kernel switching on its own; VT_PROCESS
// means a program has taken switching over and the kernel must keep its hands
// off the keyboard.
#define VT_AUTO 0x00
#define VT_PROCESS 0x01
#define VT_ACKACQ 0x02
struct vt_mode {
char mode; // VT_AUTO or VT_PROCESS
char waitv; // unused here
short relsig; // signal on release -- not delivered yet
short acqsig; // signal on acquire -- not delivered yet
short frsig; // unused
};
struct vt_stat {
uint16 v_active; // active terminal, 1-based
uint16 v_signal; // unused; Linux keeps it for VT_SETMODE

View file

@ -118,6 +118,10 @@ struct vt {
int sid; // session that owns this terminal, 0 = none
int opened; // times it has been opened, for /dev/tty
// VT_AUTO or VT_PROCESS. In VT_PROCESS a program has claimed switching and
// the kernel stops acting on the chord -- see vt_kernel_switches().
int mode;
};
// The active terminal, and the one the framebuffer is showing.
@ -142,5 +146,6 @@ void vt_repaint(struct vt *v); // grid -> framebuffer, if active
uint32 vt_rgb(uint8 idx); // palette index -> RGB
int vt_index(struct vt *v); // 0-based number of a terminal
int vt_kernel_switches(void); // 0 if a program owns switching
#endif // VT_H