50e61e431b
Records that the GUI stack moved ahead of the installer, that Schcom v0 runs and how to prove it, the decisions behind the protocol shape (Wayland-shaped, MIT so linkable, shm id rather than SCM_RIGHTS for now), and the one-display-device trap in the screendump test. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
66 lines
3.1 KiB
Markdown
66 lines
3.1 KiB
Markdown
---
|
|
name: schcom-v0
|
|
description: "Schcom v0 runs — surfaces, shm buffers, commit semantics, input routing; Wayland-shaped on purpose, verified by checking pixels from the host"
|
|
metadata:
|
|
node_type: memory
|
|
type: project
|
|
originSessionId: d4821aa9-2e49-40da-91e7-90ef9ed9997e
|
|
modified: 2026-08-09T21:12:35.466Z
|
|
---
|
|
|
|
**Schcom v0 works** (2026-08-09, commit fe64620). A client connects over a Unix
|
|
socket, is handed a shared buffer, draws and commits; the compositor composites
|
|
and presents. `projects/schcom/`.
|
|
|
|
Both blockers its README listed had already been done — AF_UNIX sockets and
|
|
`/dev/input/eventN` — so nothing was actually in the way when this started.
|
|
|
|
## How to build and prove it
|
|
|
|
```sh
|
|
make ports # once: the sysroot libc it links against
|
|
make projects # builds, stages into sysroot/bin
|
|
make # rebuild the image so the binaries are on it
|
|
make schcom-test # boots, runs it, checks the pixels FROM THE HOST
|
|
```
|
|
|
|
`make schcom-test` is the part that matters. It screendumps the framebuffer
|
|
through the QEMU monitor and asserts three pixels: the client's colour in the
|
|
middle of the surface, the compositor background away from it, and the white
|
|
border exactly at the requested origin — so "the buffer arrived" and "the buffer
|
|
arrived at the wrong offset" cannot pass for each other. The compositor's own
|
|
report that it composited something proves nothing.
|
|
|
|
**Run it with one display device.** The test passes `-vga std` and *not*
|
|
`-device virtio-gpu-pci`: with two, `screendump` captures whichever QEMU thinks
|
|
is active, which need not be the one `/dev/fb0` maps.
|
|
|
|
## The decisions worth not re-litigating
|
|
|
|
- **Wayland-shaped from the start.** Surfaces, not windows; nothing visible
|
|
until `COMMIT`; the compositor tells clients when to draw. Wayland is
|
|
**MIT-licensed**, so linking it later is fine under Apache-2.0
|
|
([[schunix-licensing]]), and Nexoniarz intends to add it.
|
|
- **The one deliberate divergence:** a buffer handle is a System V shm id, not
|
|
an fd over `SCM_RIGHTS`. `struct schcom_surface` has a `handle_kind` field so
|
|
the switch is a new value, not a protocol break.
|
|
- **The compositor owns the shm segment**, never the client — it must survive a
|
|
client dying mid-frame and must not be resizable underneath it.
|
|
- **Every message carries its own length**, so an unknown message is skipped
|
|
rather than desynchronising the stream. That is what lets a v0 compositor talk
|
|
to a v1 client.
|
|
- **Back buffer, one copy out.** Compositing straight into the framebuffer shows
|
|
every intermediate state.
|
|
- **Placement is not Schcom's.** `CREATE_SURFACE` carries x/y only because there
|
|
is no SchWM yet to ask.
|
|
|
|
## Not done
|
|
|
|
Damage tracking (it repaints everything), multiple outputs, subsurfaces, any
|
|
focus model beyond "topmost", and mode setting. All additions rather than
|
|
rewrites — which was the reason for committing to surface/commit now.
|
|
|
|
**SchAPI / `libschunix` is still not started.** See
|
|
[[schunix-schapi-direction]]: the stable ABI is meant to be a library, not the
|
|
syscall table, and Schcom currently talks to musl and raw syscalls like anything
|
|
else. Nothing about Schcom blocks it.
|