# PiKVM software in a container

**Claim.** The Bootscry client for the Comet also works against PiKVM's own software (kvmd), run in a container with fake hardware. This supports the PiKVM driver's design. It is not a run on a PiKVM unit.

**Method.** On 2026-10-16, kvmd was built into PiKVM's own test image and run without privileges, bound to the loopback address, with fake hardware. PiKVM's usual test command needs privileges and loads a kernel module, so it was not used on a shared host. The kvmd source stayed outside the repository, because it is GPL-3.0.

**Result.** Pointed at the container with a throwaway certificate pin, the client logged in and read device information, keyboard and mouse state, power state, media state and streamer state. A key press, a three-key chord, typing, a pointer move, a click and an input reset were all accepted. A screen grab failed in the right way: the container has no capture device, kvmd reported no signal, and the client raised its no-signal error. The same checks run as four repeatable tests that skip when the container is not running.

**Why it matters.** The Comet's interface comes from kvmd, and this run agrees with that. It is why the PiKVM driver is a thin variant of the Comet driver.

**Sample size.** One kvmd version, one platform profile, one container.

**Not tested.**
- Video: no screen, frame timing or signal detection.
- Power and virtual media, which are switched off in the container.
- Whether a target receives a key. Input goes to a fake device, and kvmd reports the keyboard as online even then.
- Two-factor login, other users, and other kvmd login methods.
- Other kvmd-based devices, such as a PiKVM V4, which may differ.

**Limits.** The PiKVM stays at Untested on the supported devices page until a real unit has run the driver.