nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions
SchOS/.claude/memory/schcom-v0.md
Nexoniarz 50e61e431b memory: Schcom v0, and the order change that put it before the installer 
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>
2026-08-09 23:12:56 +02:00

3.1 KiB
Raw Blame History

name description metadata
schcom-v0 Schcom v0 runs — surfaces, shm buffers, commit semantics, input routing; Wayland-shaped on purpose, verified by checking pixels from the host
node_type type originSessionId modified
memory project d4821aa9-2e49-40da-91e7-90ef9ed9997e 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

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.