57aff40228
docs/ was ten files where a plan, a description, a guide and a bug report all
sat next to each other. It is now architecture/ (what SchOS is), plan/ (what it
will be), guides/ (how to work on it) and history/ (why it is like this), with
an index that states the one rule holding it together: when something is
finished it moves from plan/ to architecture/ and is rewritten as a description
of the thing rather than a record of building it.
A ticked checkbox says the work happened. It does not say what the work
*produced*, and six months later the checkbox is all that is left. The network
stack proved the point: finished, verified end to end, and for a month the only
description of it anywhere was a checkbox four levels of indentation deep.
So roadmap.md went from 534 lines to 181 -- nothing deleted, the done work
graduated. Seven subsystems that were finished and undescribed now have
descriptions: boot, kernel, syscalls, filesystem, networking, graphics, usb,
init. Every one ends with "What it does not do", which is the section that pays;
a document listing only strengths is marketing, and the reader who needs it most
is the one about to trip over a limitation nobody wrote down.
schfs.md still opened with "phases 1 through 3 1/2 are done, phase 4 is next"
long after all five had landed. It is a description now, with the phase record
and the hard-won bugs moved to history/.
Three corrections found on the way, all load-bearing:
* projects/schcom/README.md claimed SCM_RIGHTS was done. There is no
sendmsg/recvmsg in the kernel at all, and an entire GUI plan rested on it.
* The root README said "No TCP/IP" months after the stack landed.
* history/kernel.md sec.7 was marked "in progress" on a problem that process
groups solved.
Also adds plan/1.0.md, which draws a finish line so the open list stops being
infinite, and marks schwm/ and schde/ superseded: in Wayland the compositor is
the window manager, so that split dissolves rather than being abandoned.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
4.6 KiB
Schcom — the SchOS Compositor
Owns the display. Every pixel that reaches the screen goes through it.
Clients do not draw to the framebuffer; they draw into their own buffers and hand them over. Schcom decides what is on top of what, composites the result, and presents it. It also owns input: it reads the raw event devices and sends each event to whichever client should have it.
That is the whole job. Window placement is not part of it — that is SchWM's, and Schcom exposes a protocol for it rather than implementing policy itself.
Status
v0 runs. A client connects, is given a shared buffer, draws into it and
commits; the result is composited and presented. Verified end to end by
make schcom-test, which boots SchOS, runs the compositor and a client, then
screendumps the framebuffer and asserts the pixels 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: a
compositor that cannot order two surfaces cannot host a window manager.
What exists:
- framebuffer output through
/dev/fb0and the fbdev ioctls, double-buffered - a versioned protocol over a Unix socket, with a handshake that must come first
- shared-memory buffers, one per surface, owned by the compositor
- surface / attach / commit semantics: nothing is shown mid-draw
- input from
/dev/input/eventN, routed to the topmost surface - clients that die are cleaned up, including their shm segments
- multiple clients, composited bottom-to-top in creation order
What does not exist yet: damage tracking beyond "repaint everything", multiple outputs, subsurfaces, and any focus model beyond "topmost". Those are additions rather than rewrites, which is the reason for committing to the surface/commit model now instead of growing into it later.
Building
Not part of the OS build. Needs make ports first, for the sysroot's libc:
make projects # builds and stages into sysroot/bin
make # rebuilds the image so the binaries are on it
make schcom-test # boots it and checks the pixels
What it needs from the kernel
| Need | State |
|---|---|
Shared memory (shmget/shmat/shmdt) |
done |
mmap of /dev/fb0 |
done |
| Framebuffer geometry via the fbdev ioctls | done |
| Unix domain sockets | done |
| Raw input events — key down/up with modifiers | done |
SCM_RIGHTS |
not implemented — there is no sendmsg/recvmsg at all |
| Mode setting and double buffering | partial — virtio-gpu binds, no modeset API yet |
Design notes
- Buffers are shared memory, not pipes. A pipe means copying every frame; at 800×600×32 that is 1.9 MB per frame per client.
- The compositor owns the segment, not the client. It has to survive a client crashing mid-frame, and it must not be something a client can resize underneath the compositor.
- One protocol, versioned from the start. SchWM and SchDE are separate programs, so this is a real compatibility surface on day one. Every message carries its own length, so an unknown message is skipped rather than desynchronising the stream — that is what lets a v0 compositor survive a v1 client.
- Policy belongs to SchWM. If Schcom starts deciding where windows go, the
split has already failed.
CREATE_SURFACEcarries x/y today only because there is no SchWM yet to ask.
On Wayland
Decided: Schcom moves onto Wayland, replacing the protocol below while keeping the architecture. See
docs/plan/wayland.md.
The protocol is deliberately Wayland-shaped — surfaces rather than windows,
buffers attached and made visible only on commit, and the compositor telling
clients when to draw. Wayland is MIT-licensed, so it can be linked against
without any conflict with Apache-2.0 (see docs/licensing.md), and
supporting it later is intended.
The one place v0 knowingly diverges: a buffer handle is a System V shared memory
id passed as an integer, where Wayland passes a file descriptor over
SCM_RIGHTS. struct schcom_surface carries a handle_kind field precisely so
that switching would be a new value rather than a protocol break.
That field cannot save us, and this README used to claim SCM_RIGHTS was
done. It is not — there is no sendmsg/recvmsg in the kernel at all. And
Wayland's wl_shm_create_pool passes a descriptor with no alternative form, so
our protocol being flexible is not the flexibility that is needed. Adding
descriptor passing is item 1 of
docs/plan/foundations.md.