Our own IP KVM: an eight-layer RK3576 main board with an RK628H HDMI bridge, a Rust streaming daemon, and a light-sensor rig that times the video latency every change adds. Measured at 26.5 ms added at 1080p60 and 35.7 ms at 4K60.
WarpKVM is an IP KVM: it captures a machine's HDMI output, streams it to a browser or a native client, and sends keyboard, mouse and mass storage back over USB, so the machine can be run from anywhere down to the BIOS. We design all of it. Two pieces of hardware run the same software today: WarpKVM 01, our own RK3576 main board with an RK628H HDMI bridge, and the DIY kit, a Luckfox Aura module on the RV1126B with an RK628H carrier board we designed. A third board, WarpKVM 02 on the RV1126B, is in design.

What we built
- WarpKVM 01 main board, rev A: Rockchip RK3576, RK628H HDMI-to-MIPI bridge on two 4-lane CSI links, 2 GB LPDDR4X on one x32 package, RK806S-5 PMIC, RTL8363NB three-port switch behind two gigabit jacks, BL-M8800DS2-40 Wi-Fi and Bluetooth module, 16 MB SPI NOR boot flash and microSD. Eight layers, 83 x 49.7 mm.
- A separate power board, rev A then rev B, joined to the main board by a 10-pin 0.5 mm flat flex and a 4-pin 5 V connector: USB-C power and the device port, the host port, and a PoE stage, with a TPS2121 power mux choosing between PoE and USB-C.
- warpd, the device daemon, in Rust with a small C shim: V4L2 capture, hardware H.264 encode through Rockchip MPP straight from the capture buffers, WebRTC and our own low-latency protocol, a web console served from the device, and a USB gadget for keyboard, mouse and mass storage.
- A native Windows client alongside the browser console, with hardware decode and a tearing present path.
- Kernel and driver work for the RK628H: 1080p at 120 and 144 Hz capture where the stock driver hangs, and a product EDID, so the KVM chooses the refresh rate the source sends.
- The DIY kit carrier board: RK628H on dual 22-pin CSI links to the Luckfox Aura, HDMI in, a 1080p60 HDMI out, and an 802.3af/at PoE variant.
- A glass-to-glass test rig: an HDMI splitter, two identical monitors and two light sensors, with its own scripts, validity checks and raw records.

Measured
The number we quote is the video latency the KVM adds, measured glass to glass. One HDMI source feeds a splitter: one output goes straight to a reference monitor, the other through the KVM, the network and the viewer to a second monitor of the same model. Two light sensors time the same on-screen change on both, 200 or more clicks a side, and the difference, less the measured offset between the two monitor legs, is what the KVM adds. The input path is not in it: the sensors click the source directly.
- Added, 1080p60, WarpKVM 01
- 26.5 ms text, 26.6 ms still, 27.9 ms motion
- Added, 1080p60, DIY kit
- 27.0 ms text, 26.7 ms still, 30.0 ms motion
- Added, 4K60, WarpKVM 01
- 35.7 ms, still screen
- Conditions
- Native client. 1080p60 on matched BenQ monitors; 4K60 on matched LG monitors, October 2026
- Board, 4K60
- 60 fps on both VEPU encoder cores, zero MIPI errors
- Ethernet
- 919 Mbit/s receive, 743 Mbit/s transmit, single stream, 0 FCS errors
- Thermals
- 60 to 63 °C streaming 4K60, open board, no airflow
- Memory at 4K60
- 388 MB used of a 1 GB cap, no swap. The cap is deliberate, to test whether a smaller DDR part would do
An earlier figure, 17 ms on a wired LAN in July 2026, measured a shorter span: from the first pixel entering the HDMI port to the browser draw call, on an RK3576 development board, with the viewer monitor left out.

Hard parts
The first was capture latency. The RK628H reads a frame out at the source's refresh rate, so at 60 Hz the last row arrives about 16.7 ms after the first, whatever the clocks are set to. Because the KVM presents the EDID, it chooses that rate: at 120 Hz a frame is at most 8.3 ms old when it is picked up, instead of 16.7. The second lever was starting the encode before the frame has finished arriving. On WarpKVM 01 that took capture to encoded frame from 33.9 ms to 21.3 ms and the glass figure from 40.0 ms to 28.4 ms. Start too early and the last rows go out stale: we swept the start point live and found the edge at 10.07 ms after start of frame, then fitted a per-board guard at 11.04 ms, which brought the frame in at 18.3 ms.
The second was 4K60. One 4-lane CSI port would need 2376 Mbps per lane for 4K60, and the RK628H transmitter tops out at 1850. The board routes both of its CSI outputs, one to each of two identical D-PHY receivers on the RK3576, and the capture driver joins the halves. Encoding is the next limit: one VEPU core takes about 26.6 ms on a 4K frame, more than the 16.7 ms a 60 Hz frame allows, so frames alternate between the RK3576's two encoder cores. That needed a patch to Rockchip's MPP library; with it the board holds 60 fps at 4K.
The third was measuring it honestly. The viewer's monitor refreshes on its own clock, so a frame waits anywhere from 0 to 16.7 ms for the scan to reach the sensor. A single run sits at one phase of that cycle and could read anywhere from about 27 to 41 ms on the same hardware. The fix is to run the viewer 0.1% off the source rate, so the phase sweeps every 16.7 s, log every viewer refresh, and weight the clicks so each phase counts equally. The rig turned up other effects too: a viewer graphics card left in its idle power state added 9.5 ms, so the native client now keeps it awake.

The fourth was the enclosure. Industrial designer Anson Cheung, previously a partner at Bould Design (Nest, Roku, GoPro), owned the exterior. The main board had to fit the shape he wanted, which set the 83 x 49.7 mm outline, the connector notches along one edge and every port position.

Bring-up
Two rev A boards came up on 2 October 2026. Power, DDR training at 2112 MHz on both channels, SPI boot, Ethernet on both ports, Wi-Fi, Bluetooth, HDMI out, HDMI audio from the RK628H, USB host and 4K60 capture on both CSI links all passed. The respin list is written down, and two items are worth showing. The microSD card-detect switch reads inverted through a transistor that is not needed, so the boot ROM cannot use it for recovery; U-Boot and the kernel work around it, and the fix for the next revision deletes the transistor. And the PoE stage sits at about 6.0 V with no load, just over the 5.99 V the power mux allows, so the mux never connects and the load that would pull the voltage down never arrives. One feedback resistor, 249k to about 232k, fixes it.

The DIY kit
The DIY kit runs the same daemon and console on boards anyone can buy: a 1 GB Luckfox Aura (RV1126B, four Cortex-A53 cores) under our RK628H carrier. The RV1126B encodes 4K at 30 fps in hardware, so that is the kit's ceiling, and its local HDMI output is 1080p60 only. It boots at a 3.7 W peak and streams under 4 W, inside an 802.3af PoE budget. Carrier board rev B has been in checkout since 14 September 2026; the firmware port is still in bring-up.

What's next
Rev B of the main board, and the latency cells not yet run: 1080p120, 4K30, the browser at 4K, and the input path from a click on the viewer to the target. WarpKVM 01 reservations are open at warpkvm.com, with shipping planned for Q2 2027.