| Filename | Latest commit message | Latest commit date |
|---|---|---|
8b7b8df74f
Groundwork for usb-tablet, which is the fix for the guest cursor and the
host's never being in the same place: a PS/2 mouse reports how far it
moved, two pointers accumulating deltas independently drift apart, and no
amount of care in the compositor can make them agree. An absolute device
reports where it is, so they coincide by construction.
- the HID driver no longer matches the boot subclass only. usb-tablet
declares subclass 0 and was refused at the door; hid_probe decides
what an interface actually is, and still declines what it cannot make
sense of.
- a non-boot HID interface is taken to be an absolute pointer and is
not asked for boot protocol, which it does not have -- that request
failing is what stopped it binding.
- tablet_report decodes the fixed 6-byte layout (buttons, 16-bit X,
16-bit Y, wheel) and scales the logical range to pixels there,
because it is the only place that knows the range.
- input_mouse_abs reports EV_ABS/ABS_X/ABS_Y so a reader can tell an
absolute position from a delta, and mouse_set_abs places the pointer
rather than nudging it.
- Schcom treats EV_ABS as authoritative and EV_REL as a nudge.
The device binds and identifies correctly: "usb-hid: tablet (absolute) on
slot 1, endpoint 0x81 every 4 ms".
It is NOT finished, and QEMU_INPUT is empty by default because of it. No
reports have yet been observed arriving on the tablet's interrupt
endpoint, so making it the default pointer would trade a cursor that
drifts for one that does not move at all. Opt in with
make qemu QEMU_INPUT='-device qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0'
Next step is to find out why nothing arrives: whether the first transfer
is queued but never completes, whether a completion needs re-arming for
this endpoint, or whether QEMU is not routing motion to the tablet at all
(`info mice`).
bootcheck 108 [ok], schcom-test passes.
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.