nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions

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

Browse source 
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
Download patch file Download diff file Expand all files Collapse all files

21
kernel/dev/vt.c
View file

@ -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;
}