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.