| Filename | Latest commit message | Latest commit date |
|---|---|---|
fe6462088a
Clients connect over a Unix socket, are handed a shared buffer, draw into it and commit; Schcom composites and presents. Both of the hard blockers its README listed -- unix domain sockets and raw input events -- have been done for a while, so nothing was in the way. The model is Wayland's, on purpose. A surface is not a window: it is a rectangle of pixels with no policy attached, because placement belongs to SchWM and the moment this program starts deciding where windows go the split has failed. Nothing is shown until COMMIT, so a client halfway through drawing is never presented. The compositor tells clients when to draw rather than letting them render frames nobody sees. Wayland is MIT-licensed and supporting it later is intended, so the divergences are the ones that are cheap to undo: a buffer handle is a System V shm id rather than an fd over SCM_RIGHTS, and the message carries a handle_kind field so switching is a new value rather than a protocol break. Every message carries its own length, so an unknown message is skipped instead of desynchronising the stream -- which is what lets a v0 compositor survive a v1 client. The compositor owns the shm segment, not the client: it has to survive a client crashing mid-frame, and it must not be something a client can resize underneath it. A dropped connection takes its surfaces and their segments with it. Composites into a back buffer and copies once, because compositing straight into the framebuffer shows every intermediate state -- the flicker would be the whole desktop being repainted under the user's eyes. projects/ gets build glue for the first time: `make projects` builds against the sysroot's libc and stages into sysroot/bin. It is not a dependency of anything above it, and `make` never descends there. Verified by `make schcom-test`, which boots SchOS, runs the compositor and a client, screendumps the framebuffer and asserts the pixels on the host. That last part is the point -- the compositor reporting that it composited something proves nothing, and a screenshot nobody inspects proves less. It checks the client's colour mid-surface, the compositor's background, and the white border exactly at the requested origin, so "arrived" and "arrived at the wrong offset" cannot pass for each other. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
| .. | ||
| schcom | ||
| schde | ||
| schfs-linux | ||
| schinst | ||
| schwm | ||
| README.md | ||
projects/
Things that run on SchOS rather than things that are SchOS.
Everything above this directory — kernel/, boot/, lib/, cmd/,
include/ — is the operating system: it boots, it owns the hardware, and it
is one program that either works or does not. Everything in here is an
ordinary program that talks to it through syscalls, exactly as toybox does.
The split exists because the alternative gets bad quickly. A compositor, a window manager and a desktop are each larger than the kernel will be for a long time. Grown inside the OS tree they would blur into it: a compositor would start reaching into kernel headers because they are right there, the build would grow a dependency from the kernel to a GUI, and "does SchOS boot" would stop having a clear answer. Keeping them separate forces the boundary to be a real interface — syscalls and protocols — rather than a shared header nobody meant to share.
Concretely, code in here:
- links against the sysroot's libc, never against kernel headers
- talks to the kernel only through syscalls and
/dev - can be built, run and debugged without rebuilding the kernel
- may be split into its own repository later without untangling anything
What lives here
| Directory | What it is |
|---|---|
schcom/ |
SchOS Compositor. Owns the display, composites clients, routes input. |
schwm/ |
SchOS Window Manager. Window placement, decoration, focus, on top of Schcom. |
schde/ |
SchOS Desktop Environment. Panel, launcher, settings, file manager. |
schinst/ |
The installer, the installation environment, and .sip tooling. |
schfs-linux/ |
SchFS as a filesystem for Linux. FUSE first, a kernel module later. |
schfs-linux/ is written to stand on its own. It does not mention SchOS
anywhere, and that is deliberate rather than an oversight: it is intended to be
the first piece released, and it has to make sense to somebody who has never
heard of the OS it came from — a filesystem is judged as a filesystem. The
connection can be made later, once there is a finished system to connect it to.
Practically, that means anything added there needs its own licence header, its
own README framing, and no cross-references into this tree. It shares the
format with kernel/fs/schfs/, not the prose.
They stack: SchDE needs SchWM needs Schcom needs the kernel. Nothing points the other way, and nothing here is a dependency of the kernel build.
Status
All four are scoped and none is started. What each is waiting on is written
in its own README, and the ordering is in docs/roadmap.md.
The short version: Schcom cannot start until the kernel has unix domain
sockets (for the client protocol and for passing buffer handles) and raw
input events (a /dev/input that bypasses the tty line discipline).
Shared memory and framebuffer mmap are already done.