Schcom is gone; the desktop path is Xorg now, Wayland groundwork next

SchOS will not write its own compositor. projects/schcom, its test and its make targets are deleted. roadmap.md section 5 is
now the road to Wayland (udev/eudev, a /sys/devices tree and uevent netlink, libinput and libseat, a DRM device via the GPU
plan) and 5b is the boot manager rework (Niveus/skeuomorphic UEFI GUI). XLibre, Xorg or a Wayland compositor from Alpine,
whichever suits; Xorg for now.

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

docs/plan/roadmap.md

@@ -54,22 +54,44 @@ what is present ([boot.md](../architecture/boot.md)).
 - **udev's job** — a uevent socket and `/sys/devices` — so X and others are told about devices instead of being
   given a list.
 
-## 5. Schcom, the installer, and SchDE
+## 5. The desktop, and the road to Wayland
 
-**Schcom** (`projects/schcom/`) is SchOS's own compositor. v0 is 715 lines that composite clients over a wire format of its
-own, and everything it was blocked on in the kernel now exists: Unix sockets, descriptor passing, `memfd`, evdev, framebuffer
-`mmap`. The plan is in three steps, each useful on its own:
+SchOS does not write its own compositor. (Schcom, a 715-line v0, was deleted: its wire format was a dead end, and a
+compositor worth running is years of work that Alpine already packages.) The desktop is **Xorg with Window Maker** now
+([desktop.md](../architecture/desktop.md)); **XLibre**, the Xorg fork, is a drop-in alternative if Alpine carries it, and a
+Wayland compositor (labwc, sway, weston, a GNOME or KDE session) is the larger step. What Wayland — and a modern X — need
+from the system, in the order they are useful:
 
-1. **The installer's GUI is Schcom's first real client.** An installer wants a window, a list, a progress bar and a handful of
-   input events — small enough to be the program that forces Schcom's protocol to be real, and independent of Xorg, which is not in
-   the installation environment. It needs a wire format for clients that is designed (Wayland-shaped: surfaces, buffers shared by
-   descriptor, input events), not the v0 one.
-2. **If that works, Schcom becomes useful in its own right**: window management as a module of the compositor (a compositor *is*
-   its window manager), multiple clients with focus and stacking, damage tracking.
-3. **SchDE on top of it**: a panel, a launcher, a wallpaper and settings, as ordinary clients — only once there is a Schcom worth
-   putting them on. Until then the desktop is Xorg with Window Maker ([desktop.md](../architecture/desktop.md)).
+1. **udev.** Today Xorg is *told* its input devices (`xorg.conf.d/10-schos.conf`) because nothing announces them. The fix is
+   Alpine's `eudev` (or `udev`) running on SchOS, which wants: a **uevent netlink socket** (`NETLINK_KOBJECT_UEVENT`, with the
+   `add`/`remove`/`change` messages and their environment), a real **`/sys/devices` tree** with `/sys/bus/*/devices/*` and
+   `/sys/class/*/*` as symlinks into it, `uevent` files that can be written to replay events (`udevadm trigger`), and devtmpfs
+   that udev can create nodes in. libinput then enumerates evdev devices through it.
+2. **libinput and libseat** (seatd is in Alpine): evdev with the properties libinput reads (`ID_INPUT_*` from udev), and a way
+   for a non-root compositor to take the keyboard and the display from the kernel — the `VT_PROCESS` handshake exists.
+3. **A DRM device.** Wayland compositors want `/dev/dri/card0` with KMS, and Mesa wants `renderD128`. SchOS has neither: it has
+   `/dev/fb0`. This is the GPU plan ([gpu.md](gpu.md)) — Linux's own `amdgpu` run by LDLS and `/dev/dri` served by that
+   process — and, for machines without a real GPU driver, a *simple-framebuffer* DRM shim (Linux's `simpledrm`, which is a
+   `.ko` LDLS could also host).
+4. **dma-buf, `epoll`-able sync files and the rest of the Linux graphics ABI**, as the compositors turn out to need them.
 
-Nothing here starts before [1.0.md](1.0.md)'s register is empty.
+None of this is a kernel rewrite: it is the Linux interfaces that already exist half-built (`/sys`, netlink, evdev, `SCM_RIGHTS`,
+`memfd`), finished until real programs stop asking for what is missing. The method is the one that has worked all along: `apk
+add` the program, run it, and fix what it names.
+
+Nothing here starts before [1.0.md](1.0.md)'s register is empty, except where the owner says otherwise.
+
+## 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 installer and `.sip`
 
@@ -96,7 +118,7 @@ Open questions, all wanting a decision before code:
   now, or not?
 - **Can the kernel mount a `.sip` read-only directly?** If it can, the installation environment's root can simply *be* the `.sip`.
 
-The GUI for this is a Schcom client (above).
+Its GUI is the boot manager's (5b) — the installation environment starts in it — or an X client.
 
 ## 6. SchFS beyond SchOS