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/1.0.md

@@ -60,8 +60,7 @@ boot on real hardware from a USB stick
 
 The test used to end with *reboot — the file is still there*. That clause is **dropped**, deliberately: 1.0 is a **live**
 system. The root lives in RAM and nothing written to it survives a reboot, and that is what the project is calling finished.
-Persistence (an installer, or a persistent partition) is after 1.0, and its GUI is Schcom's job — see
-[roadmap.md](roadmap.md) §5.
+Persistence (an installer, or a persistent partition) is after 1.0 — see [roadmap.md](roadmap.md) §5.
 
 ---
 
@@ -90,7 +89,6 @@ directory that has said "to be deleted" for months is the corner, not the cure.
 
 | | Where it stopped |
 |---|---|
-| **`projects/schcom/`** | A compositor v0 (about 700 lines) with no client but its own demo: the desktop is Xorg. Kept on purpose — it is to draw the installer, and later SchDE ([roadmap.md](roadmap.md) §5) — but until that starts it is built and connected to nothing. |
 | **The in-kernel LDLS window** | `vm.c` maps the kernel image a second time in the top 2 GB at every boot, and `include/ldls/ldls.h` describes a `/dev/ldls` loader — the start of loading Linux modules *into the kernel*, which [ldls.md](../architecture/ldls.md) rule 2 says is not how it is done. Nothing calls either. **Delete it**, or decide. |
 | **`display_ops`** | `acquire` and `wait_vblank` are in the vtable, implemented by one driver at most, with no consumer: Xorg draws through `/dev/fb0`. Kept for the GPU work ([gpu.md](gpu.md)); that is the reason it stays. |
 | **Socket activation** | `schinitd` parses `[Socket name]` and remembers the path. Nothing holds the socket. This is the entire reason for copying launchd, and it is the half that was not built. |
@@ -129,7 +127,7 @@ Neither cancelled nor in progress. **Do not open these.**
 
 | | |
 |---|---|
-| `projects/schinst/` | the installer, the installation environment, `.sip` — drawn by Schcom |
+| `projects/schinst/` | the installer, the installation environment, `.sip` |
 | `projects/schfs-linux/` | SchFS as a filesystem for Linux |
 | [gpu.md](gpu.md) | amdgpu and nouveau through LDLS — measured, with the work it needs written down |
 | [finch.md](finch.md) | Finch inside SchOS (the language itself is finished and lives in its own repository) |

docs/plan/README.md

@@ -40,8 +40,8 @@ Plans leave this directory when they are done. These did, and what replaced them
 
 And one that was **decided against**: `wayland.md`. Wayland needs DRM/KMS, libinput, udev and libseat, and DRM/KMS
 alone is a kernel graphics subsystem. The desktop is X. The reasoning moved to [desktop.md](../architecture/desktop.md).
-`SchWM` and `SchDE` were removed from the tree as READMEs with no code: Schcom is its own window manager, and SchDE returns as
-ordinary clients of Schcom when there is a Schcom to build them on. Meanwhile the window manager is Window Maker.
+`SchWM`, `SchDE` and the compositor `Schcom` are gone from the tree: SchOS uses other people's window manager and desktop — Window Maker
+now; XLibre, Xorg or a Wayland compositor later — and puts its work into what they need underneath (udev, DRM).
 
 ---
 
@@ -50,11 +50,11 @@ ordinary clients of Schcom when there is a Schcom to build them on. Meanwhile th
 Set by [1.0.md](1.0.md), which is the authority. **1.0 is reached** (a live system; persistence is not part of it).
 What is left before anything new starts:
 
-1. **Empty the register**: decide the unused in-kernel LDLS window (delete it, or use it), build socket activation
-   or remove the key, and give `projects/schcom/` its first client.
-2. **Then**, whatever [roadmap.md](roadmap.md) says is next. The two things the owner wants most are the installer
-   drawn by Schcom — SchOS's own compositor, and the road to SchDE ([roadmap.md](roadmap.md) §5) — and GPU
-   acceleration on the laptop ([gpu.md](gpu.md)). Finch inside SchOS ([finch.md](finch.md)) comes after.
+1. **Empty the register**: decide the unused in-kernel LDLS window (delete it, or use it), and build socket activation or
+   remove the key.
+2. **The owner's list** ([roadmap.md](roadmap.md)): the Wayland groundwork (udev first, §5), making LDLS good enough that the GPU
+   driver can run ([gpu.md](gpu.md)), a boot manager worth looking at (§5b), then the installer, then Finch inside SchOS
+   ([finch.md](finch.md)).
 
 ## What this plan does not address
 

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
 

docs/plan/schapi.md

@@ -3,7 +3,9 @@
 Status: **direction agreed, not yet implemented**, and frozen until 1.0 ships
 ([1.0.md](1.0.md)). Read it as a direction and not as a schedule: written when the plan was a
 compositor of SchOS's own, it has not been revisited since the desktop became Xorg and the
-packages became Alpine's, and §7 (what happens now) in particular predates both. Nothing in this document
+packages became Alpine's, and §7 (what happens now) in particular predates both. It also assumed SchOS would write its
+own compositor (Schcom) for the API to be designed *from*; that compositor was deleted, and SchOS's desktop
+is other people's, so read every mention of Schcom below as "the desktop". Nothing in this document
 changes what is being built this week; it changes what everything is being
 built *towards*. See §7 for what actually happens now.