# JetKVM: day one

**Claim.** One standard JetKVM was set up and its interface recorded from the web app it serves. A scratch client written for the day received a first video frame. Bootscry has no JetKVM driver yet, so this is a setup record, not a result about the device.

**Method.** The unit arrived on 2026-10-16 and was set up on 2026-10-17. Everything below was observed on the unit or read from the web app it serves. The device firmware is GPL-2.0. No source was read or copied, and the served web app was kept in a scratch folder, not in the repository.

**The unit.**

| Fact | Value read from the device |
|---|---|
| Firmware | app 0.5.9, system 0.2.8, stable channel. The vendor's latest equals both |
| Video | ready, 1920x1080 at 60 fps |
| First frame | 1.2 s after the start of a run that included login and signalling |
| What the target sees | a USB keyboard, absolute and relative mouse, mass storage and audio, and a monitor named "JetKVM v1" |
| Not present | ATX board, DC power board, serial console |

**Setup done, and why.**
- A long random password through the device's own first-run call. That one request crossed the lab network as plain HTTP, because the unit serves only HTTP until TLS is switched on.
- TLS switched on with a self-signed certificate. The device does not report its own certificate, so it could not be checked over a second path. It was pinned on first contact, after two identical handshakes.
- Automatic updates off, because a silent firmware change could break a driver that depends on the method names. Updates will be done by hand and recorded.
- A fixed address on the lab router.

**How the app talks to the unit.** A login over HTTPS sets a cookie. Signalling runs over a WebSocket. Video arrives as a WebRTC track, and control runs over WebRTC data channels: one carries JSON-RPC calls for settings, video, input, USB, virtual media and power, and others carry keyboard and mouse reports. There is no still-picture route, so a driver needs a WebRTC client and a video decoder. A WebRTC library installed cleanly in an isolated environment, so a driver would be an optional extra and the base package would stay free of it.

**What it is plugged into.** A lab machine sitting at a console that is already logged in as root. Only its screen was read. No input was sent.

**Sample size.** One unit, one setup, one first-frame time.

**Not tested.** Input, virtual media, power (the unit has no power board), a firmware update, a second client, a lost connection, and time to first frame on any network other than this lab.

**Limits.** No driver exists. Until one does and has run on the unit, the JetKVM stays at Not started on the supported devices page.