Boot manager: Niveus window, keys and wells, Instrument Sans, pointer, other systems, working power entries

The F8 menu is redrawn in the Niveus language: a window with three lights,
bevelled keys with a lit edge, wells for panels, anti-aliased corners and a
soft shadow, set in Instrument Sans rasterised into include/gfx/nvfont.h
(tools/python/mknvfont.py, make nvfont). Scale doubles on screens 1400 px tall
or more. Lists taller than the screen scroll.

The keyboard still drives everything, and a mouse, touchpad or tablet does
too: both UEFI pointer protocols are polled, hover moves the highlight, a
click activates. The cursor stays hidden until the pointer has really done
something, since the firmware installs a pointer protocol with or without a
mouse. The 'keep this resolution?' countdown is one ten-second budget however
many times the pointer moves.

Loaders found at well-known paths on any volume (Windows, Ubuntu, Debian,
Fedora, Arch, openSUSE, systemd-boot, rEFInd, other BOOTX64.EFI) are listed
and chain-loaded with LoadImage/StartImage. 'Reboot to firmware' used to halt;
it now sets OsIndications and restarts, and Restart and Shut Down call
ResetSystem.

Checked under QEMU+OVMF: menu, resolution list (incl. 2560x1600 at double
scale), system information, shut down, firmware setup, chain-loading a copy of
the loader from a second disk, and a full boot of the ISO to the login prompt.
Pointer hover and click were checked only with synthetic events: in this setup
a USB mouse or tablet delivered no event to the loader (one USB I/O handle
appeared but no pointer protocol came from it), and why was not established.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EVRhxi9zpdW2uDUN4FVcao

docs/architecture/boot.md

@@ -330,9 +330,64 @@ Dropping back to protected mode to re-enter through the 32-bit multiboot path
 is a mode switch whose failure mode is a triple fault with no console. The
 32-bit entry is still present in `entry.S` and now has no caller.
 
+### The boot manager
+
+F8 (or `o` on a serial line) opens the boot manager. It used to be a text list
+on a dark plate; it is now drawn in the Niveus language the site is drawn in
+(`docs/Website/niveus`): a window with three lights, keys with a lit upper edge
+and a shadow beneath, panels cut into the surface as wells, a graphite ground
+that darkens towards the bottom, and the mark above the list.
+
+What makes that possible in a loader is that nothing in it is large:
+
+- **Shapes** are rounded rectangles with a vertical gradient. Corners are
+  anti-aliased by supersampling only the corner pixels, against a colour the
+  caller names. Nothing reads the framebuffer back, because that memory is
+  uncached on real hardware and a read per pixel is the difference between a
+  menu that appears and one that crawls. (The one exception is the pointer,
+  which saves sixteen by nineteen pixels.)
+- **Type** is Instrument Sans, the face Niveus ships. A TrueType rasteriser
+  does not belong in a loader, so `tools/python/mknvfont.py` renders it once
+  into `include/gfx/nvfont.h` as 8-bit coverage bitmaps with fractional
+  advances, at the size for ordinary screens and at twice that for screens 1400
+  pixels tall or more. Rasterising at the real size is what keeps it crisp;
+  doubling pixels does not.
+- **Layout** is computed from the item list, not drawn from fixed positions: a
+  list taller than the screen drops the mark, then scrolls with a bar.
+
+An entry is a label, a newline and a line of detail. The entries are:
+
+| Entry | Does |
+|---|---|
+| Boot SchOS / (verbose) | the two ways of starting this system |
+| other systems | one entry per loader found at a well-known path on any volume: Windows Boot Manager, Ubuntu, Debian, Fedora, Arch, openSUSE, systemd-boot, rEFInd, and any other `\EFI\BOOT\BOOTX64.EFI` that is not this one. Chosen, they are started with the firmware's own `LoadImage`/`StartImage`, and if the other loader returns, the menu is still here |
+| Resolution | the list of modes the firmware offers, or a typed size, with the "keep this?" confirmation |
+| System Information | firmware, UEFI revision, processor, memory, display, ACPI |
+| Firmware Setup | sets `OsIndications` and restarts into the firmware's own settings; on firmware that does not support it, says so instead of restarting for nothing |
+| Restart, Shut Down | `ResetSystem` |
+| Remote debugging | `make DEBUG=1` builds only |
+
+Keyboard, mouse, touchpad and touchscreen all drive it: both UEFI pointer
+protocols are polled (a mouse reports movement, a tablet reports position),
+hover moves the highlight, a click activates, and the wheel scrolls. All input
+goes through one function, `wait_event()`, so every screen behaves the same way.
+The cursor stays hidden until the pointer has actually done something, because
+the firmware's console layer installs a pointer protocol whether or not a mouse
+is attached. USB devices appear some time after their controller is connected
+and the menu is already up by then, so the loader connects every controller when
+the menu opens and looks for pointers again twice a second for ten seconds.
+
+The "keep this resolution?" confirmation counts ten seconds down once, however
+many times the pointer moves over the button: a person with a garbled screen
+waving a mouse around must not be able to keep postponing the revert.
+
+**Not verified:** hover and click were exercised with synthetic events. Under
+QEMU and OVMF a USB mouse or tablet never delivered an event to the loader, so
+the pointer path has not been seen working on a device -- real hardware first.
+
 ### The menu is on the serial line too
 
-The three F8 screens paint into the framebuffer, which is the right place for
+The screens paint into the framebuffer, which is the right place for
 them on a machine with a screen and nowhere at all on one driven over a serial
 cable — which is how this loader is usually driven. `f8_window()` already went
 out of its way to support that, accepting `o` as well as F8 because *"a serial
@@ -351,7 +406,7 @@ its text across the menu that was just painted there.
 Two details that are not cosmetic:
 
 - **The item number is shown only where it is a key you can press.** The boot
-  menu takes 1–5. The resolution list takes only W/S and Enter and is longer
+  menu takes 1–9. The resolution list takes only W/S and Enter and is longer
   than nine entries, so numbering it printed `:`, `;`, `<` past the ninth — a
   character nobody can type, offering to select something.
 - **Q goes back as well as Esc.** On a serial line a lone `ESC` byte is

docs/architecture/debugging.md

@@ -29,10 +29,10 @@ asked for one. That is the right default and it has one bad consequence —
 to enable it.** A laptop with no serial port that stops before it can draw has
 nowhere to say why, and `schinitd enable` needs a prompt that does not exist.
 
-So a build made with `make DEBUG=1` has a sixth entry in the F8 menu:
+So a build made with `make DEBUG=1` has one more entry at the end of the F8 menu:
 
 ```
-  > 6. Remote debugging: off
+  > Remote debugging: off
 ```
 
 Picking it toggles the entry, booting carries the choice through

docs/plan/roadmap.md

@@ -82,15 +82,21 @@ Nothing here starts before [1.0.md](1.0.md)'s register is empty, except where th
 
 ## 5b. The boot manager
 
-The loader ([boot.md](../architecture/boot.md)) is a text menu: a splash, "Press F8", a list of options. UEFI gives much more:
-a graphics-output framebuffer at the panel's native mode, a pointer protocol, file systems to read themes from. The plan is a
-boot manager that is worth looking at — in the **Niveus / skeuomorphic** style the site and the wallpapers already use (the
-Shift mark, real materials, depth) — and usable: a mouse and keyboard, a list of what can be booted (this ISO, a SchFS
-partition, other operating systems' loaders), the options that live in the F8 menu now (resolution with its "keep this?"
-confirmation, verbose boot, drivers off), and an honest failure screen. It is its own piece of work in `boot/uefi/`
-(a small text and image renderer in the loader — the kernel's TrueType rasteriser is not available yet at that point) and it
-replaces the boot-time display handling that grew by accretion (GOP mode choice, the "keep this resolution" probe, the font scaling
-in the kernel) with one design.
+The loader ([boot.md](../architecture/boot.md#the-boot-manager)) is now a Niveus-styled window: bevelled keys, wells, Instrument Sans,
+keyboard and pointer, a list of other systems it finds on the disks and can chain-load, the F8 options (resolution with its
+"keep this?" confirmation, verbose boot), and real Firmware Setup, Restart and Shut Down.
+
+Still to do:
+
+- [ ] boot entries from a file on the ESP (several kernels, command lines, "drivers off", a default and a timeout), instead of
+      the two fixed ways of starting this system
+- [ ] a SchFS partition as a boot source, not just the volume the loader came from
+- [ ] an honest failure screen for the loader's own errors (today `die()` prints to the console)
+- [ ] the pointer path verified on a real machine; QEMU with OVMF never delivered a USB mouse event to the loader
+- [ ] light appearance, and a theme read from the ESP
+
+It is its own piece of work in `boot/uefi/`; the kernel's TrueType rasteriser is not available at that point, which is why the
+loader carries a pre-rasterised face (`include/gfx/nvfont.h`).
 
 ### The installer and `.sip`