Evidence
One page per claim, with its method and limits. The repeatable hardware measurements started with one Comet and one mini PC on 2026-09-29 and 2026-09-30. The install and rescue sessions ran on 2026-10-01 and 2026-10-02 on two machines. Later records add a second KVM (a Sipeed NanoKVM on a Raspberry Pi), first runs of drivers for VNC consoles and for a Dell iDRAC9, a JetKVM setup, healthy-machine baselines and KVM-side identification. The NAS recovery is a separate operator account and post-mortem, without an independent action log.
Raw test records are described on each page. Two recorded sessions are published as videos on the home page: the weirdo install and troubleshooting session, and the rescue card on a second machine. The earlier Comet BIOS capture is still served and has its own capture record. The full raw frame sets are not published.
Read in this order for the strongest proof first:
- Real recovery: nas-recovery.
- Input on real targets: typing, mouse-accuracy, then input-check.
- OCR: ocr-role, then bios-ocr and vlm-vs-ocr.
| Page | Claim in one line |
|---|---|
| nas-recovery.md | A Comet with local OCR was used to diagnose and fix a real boot loop on a headless NAS |
| platforms.md | The unit suite passes on Linux and macOS in CI; Windows is experimental and fails 31 mock-only tests |
| ocr-role.md | Why local OCR mattered in the recovery, using numbers from the pages below |
| mouse-accuracy.md | The target's kernel sees the mouse within 1/32767; X within 1 px |
| typing.md | 25/25 exact strings, fast and slow |
| bios-ocr.md | On a real BIOS, RapidOCR 0.98, Tesseract 0.94 |
| vlm-vs-ocr.md | Strict phrases of 32: local VLM 31, Tesseract 22, RapidOCR 16 |
| boot-menu-catch.md | Setup reached on a real AMI BIOS by tapping a key through POST |
| comet-quirks.md | What the Comet does differently from upstream PiKVM |
| unattended-install.md | BIOS setup and two Debian installs driven over the KVM, then a SystemRescue card boot-tested, booted on the real machine and on a second one; every mistake listed |
| m1s-bringup.md | Two ODROID-M1S boards brought up over the KVM with a rescue card; the hardware watchdog reset left the board dark, which the KVM showed and the network could not |
| nanokvm-first-runs.md | A Sipeed NanoKVM runs through the same driver layer: screen, typing, mouse and a mounted disk image, on one unit |
| input-check.md | The target's own kernel sees the keys and mouse of two different KVMs as sent, 17 of 17 on each |
| baselines-and-reboots.md | A healthy machine read through its KVM, ssh and the network together, then one timed reboot on each of two machines |
| kvm-side-identification.md | What a KVM alone can say about the machine behind it: a picture hash fails, the text layout does better |
| rfb-qemu-first-runs.md | A VNC console driver reproduces QEMU's BIOS and UEFI screens exactly; no hardware controller tried |
| idrac-first-run.md | A screenshot through one Dell iDRAC9 works with the console privilege and is refused to Read Only |
| pikvm-software-container.md | The client runs against PiKVM's own software in a container; no PiKVM unit, no video |
| jetkvm-day-one.md | One JetKVM set up and its interface recorded; a first frame in 1.2 s from a scratch client; no driver yet |
Common limits: one lab, one operator, mostly one unit of each device, multiple individually documented targets. Nothing here is a vendor-wide success rate.