| Filename | Latest commit message | Latest commit date |
|---|---|---|
bf9ac843f7
Moving the mouse repainted the whole screen. At 1280x800 that is a million pixels of desktop fill, every surface re-blitted, and a 4 MB copy to the framebuffer -- per event. Under emulation the pointer lagged the mouse by whole seconds, and that was not the emulation's fault: moving a 10x10 cursor does not require touching four megabytes. Two changes, and the second matters as much as the first. Damage tracking: one rectangle, unioned from whatever actually changed, and only those rows are redrawn and copied out. A pointer move damages where it was and where it is; a commit damages that surface; a client going away damages what it had. One rectangle rather than a list, because in practice the changes are a cursor and the window under it, and a list costs more bookkeeping than it saves. Draining input: a single mouse movement produces a burst of EV_REL ending in EV_SYN, and the loop handled one event per poll and repainted. So the compositor rendered every intermediate position of a cursor that was never seen at those positions. Both queues are now drained before anything is painted. handle_input grew a distinct "queue empty" return for it -- EV_SYN changes nothing but is not the end of the burst, and a drain that stopped there would leave the rest queued. Also cuts the loader's resolution prompt from four seconds to one and a half, on both the BIOS and UEFI paths. Four was mine and it was too long: it is paid on every unattended boot, and adding four seconds to every start to offer a menu nobody usually wants makes the common case worse to serve the rare one. schcom-test passes, including two overlapping clients and stacking order. bootcheck 108 [ok]. 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.