freeze: one register for everything half-built, and the corners cleared
The failure this is against is not scope creep. It is abandonment by promotion:
a thing gets built to the point where it works, the next thing becomes more
interesting, and the first is left in a corner -- in the tree, not finished, not
deleted, and not in any list. Enough of those and the tree stops matching its
own documentation.
docs/plan/1.0.md now holds the register, and it is the only place anything
half-built is listed. Four sections, because the kinds are genuinely different:
built and connected to nothing (the text layer, a font from disk, socket
activation, wait_vblank); started and stopped part-way (foundations 2-5, hybrid
H2, Schcom v0, a released PCI device that nothing brings back); named in a "what
it does not do" and still true; and frozen -- scoped, unstarted, not to be
started. The rule is that nothing enters except by being finished or deleted,
and that adding a row requires closing one.
1.0.md already said "two things in flight, never three". It was right and it was
not being followed.
Then the corners themselves, because a register written over a tree full of them
is just a longer list:
- cmd/init is deleted. Nothing had execed /bin/init since initcode.S changed
to /bin/schinit; it was built and installed on every image as an unreachable
fallback, and an unreachable fallback rots rather than saves.
- projects/schwm/ and projects/schde/ are deleted. Both said "to be deleted"
in their own first paragraph, which proves only that a directory marked for
deletion is not deleted by being marked. README-only, no code lost, and the
arguments each made are moved into wayland.md where they are still true.
- projects/schcom/schcom and schcom-demo were tracked binaries. Untracked, and
.gitignore'd.
Three code comments and one document described a boot that has not happened
since 7d44eb7. cons_serial_only starts set, but kmain clears it on its first
lines now, so the splash does not survive the boot and the kernel log is on
screen from the start. That reversal was earned by a Chromebox with no serial
port freezing at boot showing nothing at all, and the comments still argued the
losing side of it.
The site:
- a download page. One ISO, what it has actually been run on -- one machine,
under test -- Ventoy and dd, what the first boot looks like step by step,
and the build if you would rather. The support table names one Chromebox
rather than listing hardware, because one Chromebox is the entire bare-metal
record and a list would be fiction.
- Assets/usb.svg, drawn to the same rule as the other marks: two tones,
geometry only, the accent spent in one place, and that place is the activity
light because it is the part that tells you something is happening.
- Download is in both navs and is the hero's primary action; a closing band
ends the front page on it.
- the uberblock-slots and drivers-outside-the-kernel figures are gone. Three
numbers left, including the fastfetch one, which stays because it is funny.
Two things caught by rendering the pages instead of assuming: .hero p was
beating .filemeta on specificity and the file line was coming out at body size,
and the dd command was one line long enough that the card clipped it at `conv=`
-- a destructive command that can scroll half of itself out of view is a good
way to take somebody's disk. It is two lines now.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
This commit is contained in:
Nexoniarz
parent
d3c37f82b6
commit
c0ed23cc56
24 changed files with 586 additions and 257 deletions
|
|
@ -28,11 +28,18 @@ Concretely, code in 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. |
|
||||
|
||||
`schwm/` and `schde/` used to be here and have been **deleted**. In Wayland the
|
||||
compositor *is* the window manager — there is no protocol by which a second
|
||||
process places another's windows — and a panel or a launcher is an ordinary
|
||||
client that needs no home of its own until one is written. Both directories held
|
||||
a README and no code, and both had said "to be deleted" for long enough to prove
|
||||
that a directory marked for deletion is not deleted by being marked. What they
|
||||
argued for survives as a module boundary inside Schcom; see
|
||||
[`docs/plan/wayland.md`](../docs/plan/wayland.md).
|
||||
|
||||
**`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
|
||||
|
|
@ -43,15 +50,22 @@ 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.
|
||||
Nothing here is a dependency of the kernel build, and nothing here is pointed at
|
||||
by anything above it.
|
||||
|
||||
## 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/plan/roadmap.md`.
|
||||
`schcom/` has a v0: 715 lines that run, over a wire format of its own. **That
|
||||
wire format is superseded** — the compositor moves onto Wayland, keeping the
|
||||
architecture and replacing the protocol. See
|
||||
[`docs/plan/wayland.md`](../docs/plan/wayland.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.
|
||||
Everything Schcom was blocked on in the kernel now exists: unix domain sockets,
|
||||
raw input events, shared memory, framebuffer `mmap`, and — as of the descriptor
|
||||
passing work — `SCM_RIGHTS`, which is the one thing a Wayland client cannot be
|
||||
written without. What is still missing is a **shareable memory object**, item 2
|
||||
of [`docs/plan/foundations.md`](../docs/plan/foundations.md): a Wayland buffer
|
||||
is a file descriptor for memory, and a System V segment id is not one.
|
||||
|
||||
`schinst/` and `schfs-linux/` are scoped and unstarted, and are **frozen** —
|
||||
see [`docs/plan/1.0.md`](../docs/plan/1.0.md).
|
||||
|
|
|
|||
|
|
@ -55,8 +55,16 @@ make schcom-test # boots it and checks the pixels
|
|||
| Unix domain sockets | done |
|
||||
| Raw input events — key down/up with modifiers | done |
|
||||
| `SCM_RIGHTS` | done — `sendmsg`/`recvmsg`, see [`docs/architecture/networking.md`](../../docs/architecture/networking.md#descriptor-passing) |
|
||||
| A shareable memory object | **missing.** A Wayland buffer is a descriptor for memory; a System V segment id is not one. Item 2 of [`docs/plan/foundations.md`](../../docs/plan/foundations.md), and the one thing now standing between this directory and a Wayland compositor. |
|
||||
| Mode setting and double buffering | partial — virtio-gpu binds, no modeset API yet |
|
||||
|
||||
> **The v0 protocol below is superseded and the code is frozen.** It runs, and
|
||||
> it is kept because it is the only thing in the tree that has ever composited
|
||||
> anything — but nothing more will be added to it. SchWM and SchDE are referred
|
||||
> to throughout and both have been deleted; read those mentions as "the policy
|
||||
> module" and "a layer-shell client". See
|
||||
> [`docs/plan/wayland.md`](../../docs/plan/wayland.md).
|
||||
|
||||
## Design notes
|
||||
|
||||
- **Buffers are shared memory, not pipes.** A pipe means copying every frame; at
|
||||
|
|
|
|||
Binary file not shown.
Binary file not shown.
|
|
@ -1,34 +0,0 @@
|
|||
# SchDE — the SchOS Desktop Environment
|
||||
|
||||
> **Superseded as a directory, not as an idea.** A panel, a launcher and a
|
||||
> settings app are ordinary Wayland clients using `wlr-layer-shell`. This
|
||||
> directory is to be deleted; they need no home of their own until one of them
|
||||
> is written.
|
||||
>
|
||||
> See [`docs/plan/wayland.md`](../../docs/plan/wayland.md).
|
||||
|
||||
The parts you actually look at: a panel, a launcher, settings, a file
|
||||
manager, a terminal.
|
||||
|
||||
SchDE is a set of ordinary Schcom clients plus whatever shared widget code
|
||||
they end up needing. Nothing in it is privileged and nothing in it is
|
||||
special — if SchDE can do something that a third-party program could not, the
|
||||
line has been drawn in the wrong place.
|
||||
|
||||
## Status
|
||||
|
||||
Not started. Last of the three, and deliberately so: there is no point
|
||||
designing a panel before there is a compositor to put it on.
|
||||
|
||||
## What it will need that does not exist yet
|
||||
|
||||
- **Text rendering.** Everything here is text, and the console's fixed 8×16
|
||||
CP437 grid is not usable for it. See `docs/plan/wayland.md` — a real
|
||||
glyph cache and rasteriser, and layout as a library in `lib/` so the
|
||||
terminal and the file manager are not each solving it.
|
||||
- **A widget toolkit**, however small. Even a panel needs buttons, labels and
|
||||
hit testing.
|
||||
- **A terminal emulator.** Note the direction: the *kernel* console parses
|
||||
ANSI today because it draws directly to the framebuffer. A GUI terminal is
|
||||
a client that parses ANSI itself and renders it with proportional-capable
|
||||
text. The two do not share code.
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
# SchWM — the SchOS Window Manager
|
||||
|
||||
> **Superseded.** In Wayland the compositor *is* the window manager — there is
|
||||
> no protocol by which a second process places another's windows. This directory
|
||||
> is to be deleted, and what it argues for survives as a module boundary inside
|
||||
> Schcom rather than a process boundary.
|
||||
>
|
||||
> See [`docs/plan/wayland.md`](../../docs/plan/wayland.md).
|
||||
|
||||
Policy. Where windows go, which one has focus, what happens when you drag a
|
||||
title bar, how alt-tab behaves, what a window looks like at its edges.
|
||||
|
||||
SchWM is a *client* of Schcom, not part of it. It talks the same protocol
|
||||
every other client does, plus a privileged extension that lets it position
|
||||
and stack surfaces it does not own. That extension is the entire difference
|
||||
between a window manager and an ordinary application.
|
||||
|
||||
## Status
|
||||
|
||||
Not started. Blocked on Schcom, which is blocked on the kernel — see
|
||||
`../schcom/README.md`.
|
||||
|
||||
## Why it is separate from the compositor
|
||||
|
||||
Merging them is the common shortcut and it is the one that hurts later.
|
||||
Compositing is mechanical and must never stall: it runs every frame and a
|
||||
mistake there is a frozen screen. Window management is policy, full of
|
||||
special cases and personal taste, and it changes constantly. Putting them in
|
||||
one process means every experiment with focus behaviour risks the thing that
|
||||
puts pixels on the screen.
|
||||
|
||||
Keeping them apart also means SchWM can be restarted, replaced, or simply not
|
||||
run. A Schcom with no window manager should still show a full-screen client —
|
||||
that is a useful state to be able to reach when something is wrong.
|
||||
Loading…
Reference in a new issue