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/Website/index.html

@@ -405,7 +405,6 @@
         Xorg on the framebuffer with Window Maker, <code class="nv-code">xterm</code> and a few X clients;
         NetSurf for the web. No acceleration yet — the GPU is a plan, and the plan is Linux's own
         <code class="nv-code">amdgpu</code> through LDLS.
-        Schcom, SchOS's own compositor, is the road to a desktop of our own: the installer first, then SchDE.
       </div>
     </article>
 

docs/architecture/README.md

@@ -16,7 +16,6 @@ its distribution.
 | Kernel | **SchIFT** | Multi-core x86-64 kernel with a modular VFS |
 | Filesystem | **SchFS** | Transactional, copy-on-write, the root filesystem |
 | API | **SchAPI** | The native programming interface — *designed, not built* |
-| Compositor | **Schcom** | SchOS's own compositor — v0 runs ([../plan/roadmap.md](../plan/roadmap.md) §5) |
 | Packages | **apk** | Alpine's package manager manages the root; SchOS itself is the package `schos-base` |
 
 Twelve virtual terminals sit under all of it -- `/dev/tty1`..`tty12`, Ctrl+Alt+F1..F12

docs/architecture/desktop.md

@@ -5,8 +5,9 @@ driver and the `evdev` input driver, Window Maker as the window manager, and `xt
 `startx` runs `wmaker`. Nothing here is written by SchOS except the kernel interfaces it
 stands on and four small files in `tools/posix/mkaroot.sh`.
 
-**Xorg is the desktop for now, not for ever.** SchOS's own compositor, Schcom, is the road to a desktop of its own — the installer's
-GUI first, SchDE on top later ([../plan/roadmap.md](../plan/roadmap.md) §5).
+**Xorg is the desktop for now, not for ever.** SchOS will not write its own compositor (the one it had, Schcom, was deleted).
+What comes next is whichever of XLibre (the Xorg fork), Xorg or a Wayland compositor from Alpine suits the machine; the groundwork
+Wayland needs — udev, `/sys/devices`, libinput, a DRM device — is in [../plan/roadmap.md](../plan/roadmap.md) §5.
 
 ## Why X and not Wayland
 

docs/architecture/graphics.md

@@ -17,7 +17,7 @@ first thing here.
 | **About** | Pixels and text | *Frames* |
 | **Operations** | `draw_pixel`, `fill_rect`, `putc`, `text_at` | `acquire`, `present`, `wait_vblank` |
 | **Buffering** | None. Direct writes to the scanout. | Double-buffered |
-| **Users** | The console, PSOGM, GMMOS | Schcom (v0 and its successors); Xorg draws through `/dev/fb0` instead |
+| **Users** | The console, PSOGM, GMMOS | None today — Xorg draws through `/dev/fb0` |
 | **Must work when** | **Nothing else in the system does** | Userspace is healthy |
 
 That last row is the reason they are not one interface. The console and the

docs/guides/testing.md

@@ -14,7 +14,7 @@ reporting that it started.
 |---|---|---|
 | `make schfs-check`, `make kmem-test`, `ldls-inspect`/`ldls-run` | Host-native unit suites and the Linux-module loader run on the build machine | The filesystem's logic, the slab allocator's bookkeeping, and a `.ko`'s layout, in about a second |
 | `tools/windows/bootcheck.ps1` | A real boot, driven over the serial console | That the system answers correctly |
-| `make crashqr`, `make schcom-test` | A boot, then pixel assertions from the host | That the *screen* is right |
+| `make crashqr` | A boot, then pixel assertions from the host | That the *screen* is right |
 
 The levels exist because each catches what the one below cannot. A unit test
 cannot tell you the kernel fails to boot; a boot test cannot tell you the screen
@@ -97,17 +97,11 @@ can; the rest are run by hand or by a script:
 
 ```sh
 make crashshot && make crashqr   # crash the kernel, decode the QR out of the framebuffer
-make schcom-test                 # boot, run the compositor and a client, check the pixels
 ```
 
 `tools/windows/splashshot.ps1` counts colours. **That exists because a log-only
 harness once passed on a blank screen.**
 
-`schcom-test` asserts **from the host** — the compositor's own report that it
-composited something proves nothing. It runs two overlapping clients and checks
-that the newer one wins in the overlap, because a compositor that cannot order
-two surfaces cannot host a window manager.
-
 Other capture tools, all in `tools/windows/`: `dispshot`, `fbshot`,
 `splashshot`, `textshot`, `ttyshot`.
 

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.