kbd: three layouts, and the arrow keys were sitting on top of UTF-8

`∞`, `→`, `≤` and `'` could not be typed. `ą` and `ę` could. That pairing is
the whole diagnosis: KBD_UP was 0xE2 and its neighbours filled 0xE0..0xE9,
which are exactly the UTF-8 lead bytes for three-byte characters. Every
character in U+0800..U+FFFF -- most punctuation, every arrow, every maths
symbol, the whole of CJK -- arrived as a value the console read as an arrow key
and helpfully turned into `ESC [ A`. Two-byte sequences lead with 0xC4 and
nothing claimed 0xC4, so Polish came through and the rest did not.

The chord codes already knew this rule and said so in a comment. The navigation
keys predate them and were never brought in line. Stated once, in kbd.h: a key
produces either a Unicode codepoint or a value above 0x10FFFF, and nothing in
between means anything. KEY_* -> KBD_*, which also settles a silent collision
-- include/input.h defines its own KEY_HOME, KEY_UP and KEY_END as evdev
numbers, and kbd.c includes both headers, so three macros were being quietly
redefined in the one file that used them.

Then the layouts, which is what the codepoint-sized keycodes were for.

kernel/dev/keymap.c: us, pl, de. A layout is four tables -- plain, Shift,
AltGr, Shift+AltGr -- of uint32 codepoints. uint32 and not uchar is the reason
the file exists: `ó` fits in a byte and `ą` does not, and half a Polish
alphabet is not a Polish layout.

Two things deliberately are *not* tables:

  - **Ctrl is derived from the plain codepoint.** The table it replaces was
    indexed by scancode, which quietly assumed US -- on QWERTZ the Y and Z keys
    swap, so Ctrl+Z would have suspended a job only on some layouts.
  - **Caps Lock is a case toggle on the result**, so AltGr+a with Caps Lock is
    `Ą`. No second table could say that, because Caps Lock combines with AltGr
    rather than replacing it. Latin Extended-A alternates upper/lower by
    codepoint but not all the same way round -- Ł is U+0141 (odd) and Ą is
    U+0104 (even) -- so Polish lands in both halves and the parity matters.

kbdgetc() encodes to UTF-8 and returns the bytes one call at a time.
consoleintr()'s contract is bytes: the serial line hands it UTF-8 already and
it could not tell an encoded codepoint from a byte of the same value.

The layouts live in the kernel. Linux's loadkeys compiles a text keymap and
uploads it a key at a time through KDSKBENT, which puts the data in userspace
-- and a machine whose /usr has not mounted then has no layout at all. Here the
kernel always has a working keyboard and `loadkeys` only names which one.
KB_GETLAYOUT/KB_SETLAYOUT/KB_LISTLAYOUT; /etc/vconsole.conf and an
os.schos.keymap job for the boot-time choice. No dead keys, so French and
Spanish are absent rather than wrong.

/etc/locale.conf and LANG=C.UTF-8 in profile and zshenv. Only the charset half
of that is real -- musl decodes UTF-8 whatever the locale says and ships no
locale data -- but an unset LANG reads as "ASCII only" to everything that asks,
which is its own way of producing `?`.

And two symlink bugs found while chasing

    zsh: locking failed for /root/.zsh_history: operation not permitted

on every boot. symlink() is the classic atomic lock -- create the link, and if
it exists someone else holds it -- and zsh distinguishes EEXIST ("contended,
retry") from anything else ("this cannot work, give up"). sys_symlink returned
a bare -1, which is -EPERM, so every zsh on the machine took the second branch
on a filesystem that supports symlinks perfectly well. Same errno class as
commit 75ccf98.

The second one the first was hiding: **divesymlink() has been in fs.c since the
fork and nothing ever called it.** A symlink behaved as a small file containing
its own target, so `cat link` printed the target's *name*. open() and openat()
follow the final component now (O_NOFOLLOW gives ELOOP), and stat() and lstat()
stop being the same function, since which one follows is the only difference
between them. Mid-path symlinks are still not resolved -- that belongs in
namex(), which would re-enter lookup holding a directory lock.

Verified on the emulated keyboard, not just over serial: AltGr+a/e/s gives
ąęś, Shift+AltGr gives ĄĘŚ, Caps Lock+AltGr gives ĄĘŚ, de types zy for the
physical y/z keys and @€µ on AltGr. `∞ 'x' → ≤ • — …` typed over serial now
survives. Three fresh boots: 0 lock failures, 0 faults.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Nexoniarz 2026-09-20 01:09:32 +02:00
commit 4e3e345b41
15 changed files with 994 additions and 208 deletions

View file

@ -4,7 +4,7 @@
#include "klog.h"
#include "dbg.h"
#include "vt.h"
#include "kbd.h" /* KEY_VT_SWITCH -- the terminal-switch chords */
#include "kbd.h" /* KBD_VT_SWITCH -- the terminal-switch chords */
#include "gfx.h"
#include "theme.h"
#include "irq.h"
@ -434,14 +434,14 @@ erase_one(struct vt *v)
// ---------------------------------------------------------------------------
// Ctrl+Alt+Shift+F1..F6 switch terminals. kbd.c reports them as
// KEY_VT_SWITCH+n so that the
// KBD_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_VT_PREV && key != KEY_VT_NEXT &&
(key < KEY_VT_SWITCH || key >= KEY_VT_SWITCH + NVT))
if (key != KBD_VT_PREV && key != KBD_VT_NEXT &&
(key < KBD_VT_SWITCH || key >= KBD_VT_SWITCH + NVT))
return 0;
// A program that called VT_SETMODE(VT_PROCESS) owns switching on this
// terminal. Dropping the chord entirely would be worse than not binding it:
@ -449,9 +449,9 @@ console_vt_hotkey(int key)
// falls through to the line discipline as an ordinary key.
if (!vt_kernel_switches())
return 0;
if (key == KEY_VT_PREV) vt_cycle(-1);
else if (key == KEY_VT_NEXT) vt_cycle(+1);
else vt_switch(key - KEY_VT_SWITCH);
if (key == KBD_VT_PREV) vt_cycle(-1);
else if (key == KBD_VT_NEXT) vt_cycle(+1);
else vt_switch(key - KBD_VT_SWITCH);
return 1;
}
@ -467,8 +467,8 @@ consoleintr(int (*getc)(void))
// Terminal switching happens before the line discipline sees anything:
// the chord is not input for the terminal you are leaving.
if (c == KEY_VT_PREV || c == KEY_VT_NEXT ||
(c >= KEY_VT_SWITCH && c < KEY_VT_SWITCH + NVT)) {
if (c == KBD_VT_PREV || c == KBD_VT_NEXT ||
(c >= KBD_VT_SWITCH && c < KBD_VT_SWITCH + NVT)) {
release(&input_lock);
int taken = console_vt_hotkey(c);
acquire(&input_lock);
@ -481,8 +481,10 @@ consoleintr(int (*getc)(void))
// terminal a terminal: the keyboard follows the eyes.
struct vt *v = vt_current();
// Input mapping, before anything looks at the character.
if (v->tio.c_iflag & ISTRIP) c &= 0x7f;
// Input mapping, before anything looks at the character. ISTRIP is about
// seven-bit lines and applies to characters only -- masking a keycode
// would turn an arrow key into whatever letter its low seven bits spell.
if ((v->tio.c_iflag & ISTRIP) && c < KBD_SPECIAL) c &= 0x7f;
if (c == '\r') {
if (v->tio.c_iflag & IGNCR) continue;
if (v->tio.c_iflag & ICRNL) c = '\n';
@ -567,12 +569,13 @@ consoleintr(int (*getc)(void))
// Arrow keys and the rest of the navigation block, as escape sequences.
//
// These arrive as single keycodes -- KEY_UP is 0xE2 -- and used to be
// pushed into the input buffer exactly like that. A terminal has never
// worked that way, and 0xE2 in particular is the worst possible choice of
// byte: it is a UTF-8 lead byte for a three-byte character, so a reader
// decoding UTF-8 swallowed the next two keys waiting for continuations
// that never came. Every arrow key corrupted the two keystrokes after it.
// These arrive as single keycodes and used to be pushed into the input
// buffer exactly like that. A terminal has never worked that way, and the
// values chosen made it worse: KBD_UP was 0xE2, a UTF-8 lead byte for a
// three-byte character, so a reader decoding UTF-8 swallowed the next two
// keys waiting for continuations that never came -- every arrow key
// corrupted the two keystrokes after it. The keycodes now sit above
// U+10FFFF where nothing can collide with them; see include/kbd.h.
//
// What a terminal sends is `ESC [ A`, and what makes zsh's line editor
// work is receiving that. The sequences below are the DEC/xterm ones that
@ -580,16 +583,16 @@ consoleintr(int (*getc)(void))
{
const char *esc = 0;
switch (c) {
case KEY_UP: esc = "\033[A"; break;
case KEY_DN: esc = "\033[B"; break;
case KEY_RT: esc = "\033[C"; break;
case KEY_LF: esc = "\033[D"; break;
case KEY_HOME: esc = "\033[H"; break;
case KEY_END: esc = "\033[F"; break;
case KEY_PGUP: esc = "\033[5~"; break;
case KEY_PGDN: esc = "\033[6~"; break;
case KEY_INS: esc = "\033[2~"; break;
case KEY_DEL: esc = "\033[3~"; break;
case KBD_UP: esc = "\033[A"; break;
case KBD_DN: esc = "\033[B"; break;
case KBD_RT: esc = "\033[C"; break;
case KBD_LF: esc = "\033[D"; break;
case KBD_HOME: esc = "\033[H"; break;
case KBD_END: esc = "\033[F"; break;
case KBD_PGUP: esc = "\033[5~"; break;
case KBD_PGDN: esc = "\033[6~"; break;
case KBD_INS: esc = "\033[2~"; break;
case KBD_DEL: esc = "\033[3~"; break;
}
if (esc) {
// Not echoed. In raw mode -- which is where a line editor lives, and
@ -610,12 +613,19 @@ consoleintr(int (*getc)(void))
}
}
// Any keycode still here is a special nobody translated. Dropping it is
// the only safe thing: storing it would truncate to a byte and type a
// character the user did not press.
if (c >= KBD_SPECIAL)
continue;
if (v->in.e - v->in.r >= VT_INPUT_BUF)
continue; // buffer full: drop it
// Everything else goes in, including bytes above 127 -- those are UTF-8
// continuation bytes, and the old `c >= 32 && c <= 126` test silently
// refused every non-ASCII character anyone tried to type.
// Everything else goes in, including bytes above 127 -- those are UTF-8,
// arriving a byte at a time from the serial line or encoded by kbdgetc,
// and the old `c >= 32 && c <= 126` test silently refused every non-ASCII
// character anyone tried to type.
v->in.buf[v->in.e++ % VT_INPUT_BUF] = c;
echo(v, c);