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

kernel/core/console.c

@@ -2,7 +2,7 @@
 #include "types.h"
 #include "defs.h"
 #include "vt.h"
-#include "kbd.h"   /* KEY_ALT_F1 -- the terminal-switch chords */
+#include "kbd.h"   /* KEY_VT_SWITCH -- the terminal-switch chords */
 #include "gfx.h"
 #include "theme.h"
 #include "irq.h"
@@ -361,15 +361,22 @@ erase_one(struct vt *v)
 // Keyboard input
 // ---------------------------------------------------------------------------
 
-// Alt+1..6 switch terminals. kbd.c reports them as KEY_ALT_F1.. so that the
+// Ctrl+Alt+Shift+F1..F6 switch terminals. kbd.c reports them as
+// KEY_VT_SWITCH+n so that the
 // decision of what a chord *means* is made here, where the terminals are,
 // rather than in a driver that should not know they exist.
 int
 console_vt_hotkey(int key)
 {
-  if (key < KEY_ALT_F1 || key >= KEY_ALT_F1 + NVT)
+  if (key < KEY_VT_SWITCH || key >= KEY_VT_SWITCH + NVT)
     return 0;
-  vt_switch(key - KEY_ALT_F1);
+  // A program that called VT_SETMODE(VT_PROCESS) owns switching on this
+  // terminal. Dropping the chord entirely would be worse than not binding it:
+  // it would vanish instead of reaching the program that asked for it. So it
+  // falls through to the line discipline as an ordinary key.
+  if (!vt_kernel_switches())
+    return 0;
+  vt_switch(key - KEY_VT_SWITCH);
   return 1;
 }
 
@@ -384,12 +391,14 @@ consoleintr(int (*getc)(void))
       continue;
 
     // Terminal switching happens before the line discipline sees anything:
-    // Alt+F2 is not input for the terminal you are leaving.
-    if (c >= KEY_ALT_F1 && c < KEY_ALT_F1 + NVT) {
+    // the chord is not input for the terminal you are leaving.
+    if (c >= KEY_VT_SWITCH && c < KEY_VT_SWITCH + NVT) {
       release(&input_lock);
-      console_vt_hotkey(c);
+      int taken = console_vt_hotkey(c);
       acquire(&input_lock);
-      continue;
+      if (taken)
+        continue;
+      continue;   /* VT_PROCESS: nothing sensible to hand the tty yet */
     }
 
     // Input goes to whichever terminal is on screen. That is what makes a

kernel/dev/kbd.c

@@ -60,7 +60,8 @@ kbdgetc(void)
   shift |= shiftcode[data];
   shift ^= togglecode[data];
 
-  // Alt+1..6 before the character tables, because there is no character to
+  // Ctrl+Alt+Shift+F1..F6 before the character tables, because there is no
+  // character to
   // look up: it is a chord that means "show me a different terminal". What it
   // means is decided in console.c, which is where the terminals are; this only
   // has to name it. See console_vt_hotkey().
@@ -69,9 +70,9 @@ kbdgetc(void)
   // Ctrl+Alt+1 and on AltGr+1 as well, so a chord aimed at the host -- or a
   // Polish keystroke -- would switch terminals behind your back. Exactly left
   // Alt, and nothing else held.
-  if ((shift & (CTL | SHIFT | ALT | RALT)) == ALT &&
-      data >= SCAN_1 && data < SCAN_1 + NVT)
-    return KEY_ALT_F1 + (data - SCAN_1);
+  if ((shift & (CTL | SHIFT | ALT | RALT)) == (CTL | ALT | SHIFT) &&
+      data >= SCAN_F1 && data < SCAN_F1 + NVT)
+    return KEY_VT_SWITCH + (data - SCAN_F1);
 
   c = charcode[shift & (CTL | SHIFT)][data];
   if(shift & CAPSLOCK){

kernel/dev/vt.c

@@ -697,3 +697,24 @@ vt_index(struct vt *v)
 {
   return v ? v->index : 0;
 }
+
+// May the kernel act on the switch chord?
+//
+// Not if the terminal on screen is in VT_PROCESS: a program has said it will
+// handle switching itself, and the whole point of saying so is that the chord
+// belongs to it now. This is the documented Unix answer to "my application
+// wants that key", and it is the one a display server will use -- Schcom, on
+// the terminal it owns, so that Ctrl+Alt+Shift+F2 reaches its own compositor
+// bindings instead of yanking the screen out from under it.
+//
+// What this does *not* do yet: deliver relsig/acqsig and wait for VT_RELDISP.
+// Linux signals the owning process on every switch request and blocks until it
+// answers, which is how a display server gets to release the GPU first. There
+// is nothing here that needs to release anything, so the kernel simply stops
+// switching rather than negotiating. When Schcom needs the handshake, this is
+// where it goes, and struct vt_mode already carries the fields for it.
+int
+vt_kernel_switches(void)
+{
+  return vt_current()->mode != VT_PROCESS;
+}

kernel/sys/sys_fs.c

@@ -1174,12 +1174,26 @@ addr_t sys_ioctl(void)
         return -ENFILE;
     }
 
-    // VT_GETMODE/VT_SETMODE describe whether the kernel or a process drives
-    // switching. There is only the kernel here, so report the default and
-    // accept the default; refusing outright would stop a program that only
-    // wanted to check.
-    if (request == VT_GETMODE || request == VT_SETMODE)
+    // VT_GETMODE/VT_SETMODE: who drives switching.
+    //
+    // These were accepted and ignored, which was a lie with a consequence --
+    // a program could ask for the chord and be told yes while the kernel kept
+    // taking it. VT_PROCESS now genuinely stops the kernel switching, so an
+    // application that wants Ctrl+Alt+Shift+F2 can have it.
+    if (request == VT_SETMODE) {
+        struct vt_mode *m = (struct vt_mode*)user_ptr(argp, sizeof(*m));
+        if (!m) return -EFAULT;
+        if (m->mode != VT_AUTO && m->mode != VT_PROCESS) return -EINVAL;
+        vt_for_minor(f->ip->minor)->mode = m->mode;
         return 0;
+    }
+    if (request == VT_GETMODE) {
+        struct vt_mode *m = (struct vt_mode*)user_ptr(argp, sizeof(*m));
+        if (!m) return -EFAULT;
+        memset(m, 0, sizeof(*m));
+        m->mode = (char)vt_for_minor(f->ip->minor)->mode;
+        return 0;
+    }
 
     return 0;
 }