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.