SchOS/kernel/dev/kbd.c
Nexoniarz 4e3e345b41 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>
2026-09-20 01:09:32 +02:00

175 lines
5.4 KiB
C

#include "types.h"
#include "x86.h"
#include "defs.h"
#include "kbd.h"
#include "posix.h"
#include "vt.h" /* NVT -- how many terminals the chords reach */
#include "input.h"
#include "keymap.h"
// The chord, settable at run time through VT_SETCHORD.
//
// AltGr+F1..F6 by default. Every other candidate is taken by the host, by
// applications, or by the keyboard layout -- see include/kbd.h -- and AltGr
// with a function key is taken by none of the three: a Polish layout wants
// AltGr+*letter*, which still reaches the shell untouched, and no window
// manager binds AltGr with an F-key.
//
// AltGr+minus and AltGr+equals step to the previous and next terminal on the
// same modifiers, for when you have two and do not care which number they are.
//
// Zero modifiers disables all of it; `chvt N` still works.
uint vt_chord_mods = RALT;
uint vt_chord_base = SCAN_F1;
// Which scancodes are modifiers, and which are locks. Hardware facts rather
// than layout ones -- every layout agrees that 0x2A is a Shift key -- so they
// stay here while the character tables live in keymap.c.
static const uchar shiftcode[256] = {
[0x1D] = CTL,
[0x2A] = SHIFT,
[0x36] = SHIFT,
[0x38] = ALT,
[0x9D] = CTL,
[0xB8] = RALT // right Alt / AltGr -- see RALT in kbd.h
};
static const uchar togglecode[256] = {
[0x3A] = CAPSLOCK,
[0x45] = NUMLOCK,
[0x46] = SCROLLLOCK
};
// A key can produce more than one byte.
//
// consoleintr's contract with getc() is bytes: the serial line hands it raw
// UTF-8 already, and it would have no way to tell an encoded codepoint apart
// from a byte that happened to have the same value. So the keyboard encodes
// here and hands the bytes over one call at a time -- kbdintr loops until
// getc() returns negative, so a queue of at most four drains on its own
// before the next scancode is read.
static uchar pend[4];
static int pend_n, pend_i;
static int
queue_utf8(uint32 cp)
{
pend_i = 0;
if (cp < 0x80) {
pend_n = 0;
return (int)cp; // the common case: no queue at all
}
if (cp < 0x800) {
pend[0] = 0xC0 | (cp >> 6);
pend[1] = 0x80 | (cp & 0x3F);
pend_n = 2;
} else if (cp < 0x10000) {
pend[0] = 0xE0 | (cp >> 12);
pend[1] = 0x80 | ((cp >> 6) & 0x3F);
pend[2] = 0x80 | (cp & 0x3F);
pend_n = 3;
} else {
pend[0] = 0xF0 | (cp >> 18);
pend[1] = 0x80 | ((cp >> 12) & 0x3F);
pend[2] = 0x80 | ((cp >> 6) & 0x3F);
pend[3] = 0x80 | (cp & 0x3F);
pend_n = 4;
}
return pend[pend_i++];
}
int
kbdgetc(void)
{
static uint shift;
uint st, data;
uint32 cp;
if (pend_i < pend_n)
return pend[pend_i++]; // finish the last key first
pend_i = pend_n = 0;
st = inb(KBSTATP);
if((st & KBS_DIB) == 0)
return -1;
if(st & 0x20)
return -1;
data = inb(KBDATAP);
if(data == 0xE0){
shift |= E0ESC;
return 0;
}
// Feed /dev/input/event0 before the byte is turned into a character. This
// has to happen here rather than in a second handler because the byte can
// only be read from the port once -- whoever reads it owes it to everyone
// else. The console path below is untouched: both consumers see every key.
input_ps2_scancode(data, (shift & E0ESC) != 0);
// While something holds an exclusive grab on the keyboard, the console gets
// nothing. The shift/caps state below is still tracked, so releasing the
// grab does not leave the line discipline believing a modifier is held.
if(input_is_grabbed(INPUT_KBD)){
if(data & 0x80){
data = (shift & E0ESC ? data : data & 0x7F);
shift &= ~(shiftcode[data] | E0ESC);
} else {
shift |= shiftcode[data];
shift ^= togglecode[data];
}
return 0;
}
if(data & 0x80){
data = (shift & E0ESC ? data : data & 0x7F);
shift &= ~(shiftcode[data] | E0ESC);
return 0;
} else if(shift & E0ESC){
data |= 0x80;
shift &= ~E0ESC;
}
shift |= shiftcode[data];
shift ^= togglecode[data];
// The switch chord, before the character tables, because there is no
// character to look up: it is a combination 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().
//
// The modifier test is an equality, not a mask. `shift & ALT` would fire on
// 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 the
// modifiers named, and nothing else held.
if (vt_chord_mods != 0 &&
(shift & (CTL | SHIFT | ALT | RALT)) == vt_chord_mods) {
if (data >= vt_chord_base && data < vt_chord_base + NVT)
return KBD_VT_SWITCH + (data - vt_chord_base);
if (data == SCAN_MINUS) return KBD_VT_PREV;
if (data == SCAN_EQUALS) return KBD_VT_NEXT;
}
cp = keymap_lookup(data, shift);
if (cp == 0)
return 0;
if (cp >= KBD_SPECIAL)
return (int)cp; // arrows and the rest, not characters
return queue_utf8(cp);
}
void
kbdintr(void)
{
consoleintr(kbdgetc);
}
// The two headers describe the same bits to two different audiences, and a
// mismatch would be silent: a chord set from userspace would simply never
// match, and the only symptom would be a key that does nothing.
_Static_assert(VTC_SHIFT == SHIFT && VTC_CTRL == CTL &&
VTC_ALT == ALT && VTC_RALT == RALT,
"include/posix.h VTC_* must mirror include/kbd.h modifiers");