Initial commit: Schunix as it stands before the SchOS rename

An x86-64 operating system built from xv6, now largely rewritten: SMP,
a copy-on-write root filesystem (SchFS), PCI/USB/virtio drivers, a TTF
rasteriser, and a Linux-numbered syscall ABI.

No history before this point -- the tree was never under version control.
This commit exists so the rename that follows has something to undo to.

projects/schcom/README.md

@@ -0,0 +1,42 @@
+# Schcom — the Schunix 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
+
+Not started. Scoped only.
+
+## What it needs from the kernel first
+
+| Need | State |
+|---|---|
+| Shared memory (`shmget`/`shmat`/`shmdt`) | done |
+| `mmap` of `/dev/fb0` | done |
+| Framebuffer geometry via the fbdev ioctls | done |
+| **Unix domain sockets**, with `SCM_RIGHTS` | **missing** — `socket()` is a `NO_LINUX` stub |
+| **Raw input events** — key down/up with modifiers | **missing** — input only arrives cooked, through the tty line discipline |
+| Mode setting and double buffering | **missing** — needs the virtio-gpu driver |
+
+The two marked missing are hard blockers, not inconveniences. A client and
+the compositor have to pass a buffer handle between them, and a pipe cannot
+carry one. And a compositor that reads the tty gets line-buffered text
+delivered to a single foreground process, which is not input in any sense it
+can use.
+
+## Design notes, so far
+
+- **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. shm exists for this.
+- **One protocol, versioned from the start.** SchWM and SchDE are separate
+  programs, so the protocol is a real compatibility surface from day one, not
+  after the fact.
+- **Policy belongs to SchWM.** If Schcom starts deciding where windows go, the
+  split has already failed.