The display becomes danos's first multi-threaded service. A mouse-listener
thread runs beside the compositor loop; the compositor stays the single owner
of the framebuffer, and the cursor it draws is a top-z layer moved from the
listener's accumulated position over a single-slot latest-value CursorChannel
(Thread.Mutex) with a coalesced self-ipc.send poke that wakes the parked
replyWait (docs/display.md, docs/threading.md).
Two kernel-level findings this surfaced, both fixed:
- IPC handles are per-Task, not per-address-space — a thread reaches another
thread's endpoint via ipc.lookup() to install its own handle.
- Concurrent IPC from two threads raced unlocked kernel state (flaky #GP);
create_ipc_endpoint / ipc_register / ipc_lookup now take the big kernel
lock like call/reply_wait/send already did (the kernel heap has no lock of
its own yet — heap.zig: "a lock comes with threads/SMP").
Also decouples display-demo: it no longer draws a cursor (the service owns it)
or blocks its animation loop on a mouse read, so a normal boot shows one
responsive cursor and animation that runs independent of the mouse. The
display-demo test now spawns the input service to keep that independence honest.
New test display-cursor (smp:4) drives synthetic motion end to end. Verified:
zig build, zig build test, and the full 29-case QEMU guardrail suite all green.
daniel