Supported Network KVMs
We do not claim support we have not measured. A device is labelled with one of four strict status levels based on physical hardware verification.
Status Definitions
Full checklist passed on physical hardware in our lab, with exact firmware version and measured limits recorded.
Key functionality verified on physical hardware; remaining checklist items actively in progress.
Driver designed from vendor documentation or mock-tested only; no physical hardware run has taken place.
No driver written yet. Awaiting evaluation hardware or API documentation.
Hardware Matrix
| Device / Vendor | Status | Firmware tested | Verified capabilities |
|---|---|---|---|
| GL.iNet Comet (GL-RM1) Reference Hardware | Partial | RM1 V1.10.1 release3 (kvmd 4.82) | Eight behaviors catalogued with mixed evidence levels; streamer wake measured; mouse and typing measured; BIOS OCR and a boot catch measured on one target; keys and mouse checked against the target's own kernel (input check). |
| Sipeed NanoKVM Mini Sipeed | Partial | Application 2.5.2 | One unit and one Raspberry Pi target at a text console. Screen, typing, keys and mouse checked against the target itself, and a disk image mounted and seen by the target (NanoKVM first runs, input check). One run of each check. Power control and Wake-on-LAN untested. |
| Dell iDRAC9 Server management controller | Partial | 7.00.00.185 | Screen only, on one server: a picture of the server's screen taken through Redfish and read by the same reader and boot-phase classifier (iDRAC first runs). The driver sends no input by design. The picture needs the Access Virtual Console privilege, which also allows keyboard and mouse control; a Read Only account was refused. Other firmware untested. |
| VNC consoles Any RFB server | Untested | QEMU virtual machines only | The driver reproduced QEMU's BIOS and UEFI screens exactly and sent keys into the firmware (VNC first runs). No hardware controller's VNC server has been tried, so it stays Untested on hardware. |
| PiKVM (v3 / v4) PiKVM Project | Untested | None (no unit) | A driver exists, written from PiKVM's public interface on the same client the Comet uses, and mock-tested. The client has also run against PiKVM's own software in a container with fake hardware (PiKVM software in a container). It has not run on a PiKVM unit, so video, power and virtual media are unmeasured. |
| JetKVM JetKVM | Not started | None (unit set up, no driver) | One unit arrived and was set up in October 2026. Its interface was recorded from the web app it serves, and a scratch client received a first video frame (JetKVM day one). No Bootscry driver exists yet, and no input, media or power has been sent through it. |
| Sipeed NanoKVM (PCIe) Sipeed | Not started | None (awaiting hardware) | The PCIe model has not been tried. The Mini model is listed above. |
| TinyPilot Voyager TinyPilot | Not started | None (awaiting hardware) | Automation REST API documented; requires per-device Automation License. No physical test yet. |
A status above Untested always links to the evidence behind it. Each record names its sample size and what was not tested.
Comet evidence checklist
The GL.iNet Comet is our reference device. These items show what has been measured and what still needs testing before certification:
- Catalogued: Eight Comet behaviors, each marked live, source-only, or reported. This is not a claim that all have unit tests.
- Observed: Streamer wake from a sleeping state on one unit.
- Measured: Mouse positioning within 1/32767 in the target kernel and 1 px in X on the test bench.
- Measured: Exact keystroke delivery on 50 of 50 trials in fast and slow modes.
- Measured: AMI Aptio screen OCR with RapidOCR fuzzy score 0.98 on a small frame set.
- Observed: BIOS setup caught through POST on one board.
- Pending: Recovery when KVM or target is unplugged mid-run.
- Pending: Multi-target board matrix (testing beyond the psycho mini PC).
Invitation to manufacturers
Contact us about an evaluation unit (loan or gift; loans are returned). If the device is a fit and testing succeeds, we plan to build a dedicated driver and publish the checks we can complete, with measured limits. We will share draft findings with your engineering team before publication.