# ESP-KVM on the ESP32-P4: an IP-KVM that does not need the target's OS

> ESP-KVM turns an ESP32-P4 board and a TC358743 HDMI-to-CSI bridge into a browser-served KVM: HDMI capture, USB keyboard and mouse, and HTTPS on the device. It is for homelab and server owners who need a BIOS screen or a dead kernel, not a desktop session.

**espkvm/espkvm** — IP-KVM on the ESP32-P4: HDMI capture, USB keyboard and mouse, and a browser console over HTTPS

- Repository: https://github.com/espkvm/espkvm
- Website: https://espkvm.io
- Stars: 476 · Forks: 34
- Language: C
- License: Apache-2.0
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/espkvm-espkvm

## What an IP-KVM on an ESP32-P4 actually replaces

Remote desktop runs on the machine. That is the whole problem. If the target is sitting in a BIOS setup screen, showing a boot menu, or running a kernel that panics before the network comes up, there is no remote desktop to connect to. ESP-KVM takes the other position: a small board plugs into the target's HDMI output and a USB port, and serves the screen, keyboard and mouse to a browser. The README frames it exactly that way, as working where remote desktop cannot, including a machine with no operating system on it at all.

The audience follows from that. Homelab owners with a headless box in a rack, people who administer machines they cannot physically reach, and anyone who has driven to an office to press a key. The project also lists an ipmi-alternative topic, which is the honest comparison: this is the thing you reach for when the BMC is absent, broken, or costs more than the machine it manages. The README claims it costs a fraction of a commercial KVM-over-IP, and the bill of materials is a development board plus a Toshiba TC358743 HDMI-to-CSI bridge plus wiring.

## The capture path: HDMI into CSI, frames out over HTTPS

The hardware chain is stated plainly: an ESP32-P4 with a Toshiba TC358743 HDMI-to-CSI bridge. The TC358743 converts HDMI into MIPI CSI-2, the ESP32-P4 receives it, and the firmware streams it. The README credits jrowny/p4kvm for the hard part, bringing up the TC358743 and getting frames out of the P4's CSI receiver, which is a useful signal about where the risk in a build sits. If capture does not come up, that is the layer to suspect first.

On top of that sits the console, a web page. Nothing installs on the machine you drive from and nothing installs on the target. Video goes out as MJPEG or as H.264, and the H.264 path needs HTTPS in the browser, which the device can provide because it issues its own certificate and exposes the CA for download. The same CA download is what enables H.264, so those two features are coupled rather than independent.

Input goes the other way over USB: keyboard, absolute and relative pointer, media keys, and text pasting with a keyboard layout (US English, Russian, Czech, Ukrainian, Lithuanian). Around the video and input core the README lists a wide set of extras: multiple viewers with one in control at a time and takeover, user-defined key macros, runbooks that wait for words on the screen and run on the device itself, a cron-style scheduler, push notifications with a screenshot, settings export and import, firmware update over the network with rollback, virtual media, reading a text screen as text, Wake-on-LAN, ATX power control, an optional I2C OLED or GC9A01 status display, a viewing token for dashboards, and a Home Assistant integration over MQTT that is off by default. That is a lot of surface for one firmware image, and the README's own status table is the right place to check whether the piece you need is listed as working.

## Installing ESP-KVM and reaching the console

The README points at a browser flasher at espkvm.io/flash/ rather than at a local toolchain, which is the shortest path for a first board. The repository also carries a firmware workflow under .github/workflows/firmware.yml and targets ESP-IDF v6.1, so building from source is possible, but the README's quick start is the hosted flasher. Open it, connect the board over USB, and follow the prompts.

If you would rather build from source, the repository layout is the guide: CMakeLists.txt at the top level, sdkconfig.defaults, main/, components/, and partition tables for 16 MB and 32 MB flash. The README does not print a build command, so the exact idf.py invocation is not documented here; what the repository tells you is which files to expect. After flashing, the device comes up and the console is a web page. The README also offers a hosted demo at demo.espkvm.io if you want to see the interface before wiring anything.

Once the board is on the network, the first real task is getting a picture. Plug the target's HDMI into the capture input and the USB into the target, then open the console and confirm that the target's resolution is detected and that the video settings panel shows a live frame. If the target's output changes resolution, the README says capture follows it. For H.264 rather than MJPEG, download the device's CA so the browser trusts the certificate, then switch the codec. For headless use, the viewing token is off until you create one, and it opens the stream and the figures without exposing anything that can touch the target.

## Where ESP-KVM is the wrong tool

The capture input is HDMI into a TC358743. A target with only DisplayPort or USB-C video needs an adapter, and the README does not describe one. That is a hardware boundary, not a firmware gap.

Several features carry conditions that matter more than the feature list suggests. Waking a sleeping target from the keyboard works over USB only if the machine allows it; otherwise the README points at Wake-on-LAN or the ATX button. Reading a text screen as text works in character modes only, so a graphical boot loader is out. Noticing a screen that is one flat colour works precisely because there are no characters to read. Runbooks that wait for words on the screen are text-screen only as well, and the README notes they need the clock, set over the network, for the scheduler. WiFi, on boards with an ESP32-C6, allows one link at a time, plus a rescue hotspot and a captive portal. Virtual media needs a FAT32 card or a small image in the device's own flash, which caps how large an ISO you can boot from.

The other boundary is the build itself. This is a development board plus a bridge chip plus wiring, and the README's own credit line says the hard part was solved upstream in jrowny/p4kvm. If you want an appliance with a warranty and a support contract, this is not that, and the firmware update path with rollback does not change the fact that you assembled the hardware.

## ESP-KVM against JetKVM and against a BMC

JetKVM is the comparison people search for, and it is the closest one: a dedicated IP-KVM appliance that you buy rather than assemble. The difference in approach is where the work sits. With ESP-KVM you supply the ESP32-P4 board and the TC358743 bridge and the wiring, and in exchange you get a firmware image you can rebuild, an Apache-2.0 codebase, and a feature set that grows with the repository. With an appliance you supply money and get a finished unit. Neither is strictly better; they fail differently. A self-built board can be repaired and reflashed and its pins reassigned from the console, and it can also be the thing you debug at 2 a.m. because a ribbon cable is loose.

Against a server BMC the split is cleaner. A BMC is integrated, always present, and usually the first thing to break in ways you cannot see. ESP-KVM sits outside the target entirely, which is why it survives a machine with no operating system, and why it can be moved from one machine to another. The cost is that it sees only what comes out of HDMI and can send only what goes into USB, plus whatever you wire to the ATX header. No sensors, no fan control, no out-of-band firmware inventory. If you need those, you need a BMC. If your BMC is the problem, you need this.

## Licence, maintenance and what an upgrade costs you

ESP-KVM is Apache-2.0, and the repository carries a LICENSE and a NOTICE file. Apache-2.0 permits commercial use and modification and includes a patent grant, with the usual obligations around attribution and stating changes; the NOTICE file exists to carry attribution forward. Because the project builds on jrowny/p4kvm, and because third_party/ and .gitmodules are present in the tree, anyone redistributing a modified firmware should read the notices rather than assume the top-level licence is the whole story. That is a description of the files, not legal advice.

The maintenance picture is current. The last push was on 2026-09-16, and releases v.0.49.0, v.0.49.1 and v.0.50.0 all landed on 2026-09-15 and 2026-09-16, so the project is moving quickly and version numbers are advancing in small steps. Fast releases cut both ways: fixes arrive quickly, and a firmware you flashed last month is several versions behind. The upgrade path itself is documented as firmware update over the network, with rollback, which is the mechanism that makes frequent releases tolerable on a device you may not be able to reach physically. What the README does not document is what happens when the rollback path itself fails, so treat the first flash of any board as something to do with physical access. Settings export and import exists, and the README notes the file contains no secrets and leaves a device's own identity alone, which makes it usable for moving a configuration between boards.

## Conclusion

Adopt ESP-KVM if you already own or are willing to buy an ESP32-P4 board and a TC358743 bridge, and you need a BIOS screen, a boot menu, or a machine with no OS. Do not adopt it if you want a finished appliance with support, or if your target only exposes DisplayPort or USB-C video, since the capture path here is HDMI into a TC358743. Before buying anything, check the boards/ directory for a board whose wiring matches yours and read docs/wiring.md for the ATX and USB connections, because the README does not document rollback of a failed flash and the wiring is on you.

## FAQ

### What is ESP-KVM?

It is an IP-KVM built from an ESP32-P4 and a Toshiba TC358743 HDMI-to-CSI bridge. It captures the target's HDMI output and serves the screen, keyboard and mouse to a browser, so it works on a BIOS screen, a boot menu, or a machine with no operating system at all.

### How do I install ESP-KVM on a board?

The README points at a browser flasher at espkvm.io/flash/ as the quick start. Building from source uses ESP-IDF v6.1, with CMakeLists.txt and sdkconfig.defaults at the top level and partition tables for 16 MB and 32 MB flash.

### Does ESP-KVM need anything installed on the target machine?

No. The console is a web page, and the README states there is nothing to install on either end. The target only needs an HDMI output and a USB port, which is why it still works when remote desktop cannot run.

## Sources

- [espkvm/espkvm on GitHub](https://github.com/espkvm/espkvm)
- [License: Apache-2.0](https://github.com/espkvm/espkvm/blob/main/LICENSE)
- [Project website](https://espkvm.io)
- [README](https://github.com/espkvm/espkvm/blob/main/README.md)
- [Releases](https://github.com/espkvm/espkvm/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/espkvm-espkvm