The machine, in a browser tab.

IPMI, the BMC chip built into server motherboards, manages a machine from the inside: real power control, internal sensors, POST codes, over a standard protocol. But it lives only on server-class hardware, and the full remote console is often behind a license.

ESP-KVM is external. It clips onto any machine with an HDMI output and a USB port, captures the physical video, and acts as its keyboard and mouse — bringing the remote console, virtual media and wake-on-LAN part of what a BMC does to hardware that has no BMC and never will: a desktop, a laptop, a mini-PC, an SBC, for about $40. It can press the machine’s power and reset buttons and read its power LED through optocouplers (ATX power control), though it does not read the host’s internal sensors the way a BMC does. Think of it as closer to PiKVM than to IPMI: not a replacement for a BMC on a server, but the useful slice of one for everything that never had a BMC. How it compares with PiKVM, JetKVM, NanoKVM and GL.iNet Comet, honestly: the comparison.

They are Linux computers; this is firmware on a microcontroller. They win on video - 1080p at 60 fps and more, where this does about 20. It wins on having no operating system to maintain or break, VPN built into the firmware, and running on fifteen boards you can buy from several makers. JetKVM Mini, announced in September 2026, uses the same ESP32-P4 chip. The full side-by-side, with sources and the cases where you should buy one of the others: ESP-KVM compared.

The easiest: plug the board in and press Read the board on the tools page (Chrome or Edge). Without a browser that can, three ways to tell:

• The marking on the ESP32-P4 itself, or on the lid of the module it sits in. ESP32-P4NRW32X — an X at the end — is revision 3.x; ESP32-P4NRW32 without the X is revision 1.x. On the chip itself the second character of the manufacturing code is the revision: C for v1.0, E for v1.3, F, G, H for v3.0, v3.1, v3.2 (Espressif’s table).
• Ask the chip over USB with esptool: esptool --chip esp32p4 chip-id. It prints Chip type: ESP32-P4 (revision v3.1), changes nothing on the board and restarts it.
• The boot log of any ESP-IDF firmware says chip revision: v3.1 — the serial monitor here shows it.

The same board can come with either revision: the product code does not tell, so check the chip, or ask the seller.

The number in the part name is the PSRAM in megabytes. ESP-KVM is built for 32; an NRW16 or NRW16X chip has 16, and nobody has tried the firmware on one.

It matters for two reasons. An image built for one revision does not start on the other, so the flasher asks which one you have (a wrong pick damages nothing; flash the other one). And revision 3.x is much faster at H.264: about 22-24 fps at 1080p against 5-7.

ESP-KVM presents the keyboard and mouse to the target over the ESP32-P4’s high-speed USB OTG (OTG_HS). It has to be a proper USB data cable, not a charge-only one — the data lines are what carry the keyboard and mouse.

On the Waveshare ESP32-P4-ETH specifically, OTG_HS is not on a USB port at all — it is brought out on a small MX1.25 header (the board’s single USB-C is the CH343 flashing/console port). So you need an MX1.25-to-USB cable ending in a male Type-A plug — ESP-KVM is the USB device, so it plugs into the target’s USB port. A link to one that fits is in this discussion.

On other ESP32-P4 boards the OTG_HS may be routed to a USB-C port instead — check your board’s pinout.

Almost always because the target has more than one display. ESP-KVM presents itself as an absolute pointing device by default, the way a graphics tablet does: it sends “the pointer is at this position” rather than “move this far”. That is what lets the cursor land exactly where you aim it, with nothing to capture and nothing to run away.

The catch is that an absolute device addresses the target’s whole desktop, not the one output you are watching. With a second monitor attached, that desktop is wider than the screen ESP-KVM captures, so your side of the picture is stretched across both. With two equally wide screens the pointer travels twice as far as the mouse, and half of the picture aims at the display you cannot see — move into it and the cursor simply disappears onto the other monitor.

Two ways out. Unplug or disable the target’s second display while you are working through ESP-KVM — then the desktop and the captured screen are the same thing again. Or switch Settings → Input → mouse mode to relative, which sends movement instead of position and so does not depend on the desktop’s size or layout; click the picture to take control, and use Relative sensitivity if the speed does not suit you.

A pointer that drifts only near the edges while it is accurate in the middle is a different thing entirely, and one that affected macOS targets — that one is fixed.

No — this design needs two things that, across Espressif’s line-up, only the ESP32-P4 has together: a MIPI-CSI-2 receiver and a hardware H.264 encoder.

The capture board (a Toshiba TC358743) outputs MIPI-CSI-2, so the host chip needs a CSI-2 receiver to read it. The other ESP32 parts — including the newer ESP32-S31 — have a DVP (parallel) camera interface, not CSI-2, so they can’t take the bridge at all. And moving 1080p leans on the P4’s hardware H.264 encoder; the S-series has a JPEG codec but no H.264, so software encoding on the cores wouldn’t keep up.

The S31 does have things the P4 lacks (WiFi 6 on-die, no co-processor), so if Espressif ever ships a P-series successor with the radio built in, that would be the dream chip for this — but for now the P4 is the one with the CSI-2 + H.264 combination it needs.

From the console, over the network. Turn on Settings → System → Offer firmware updates — it is off by default — and the console tells you when a newer build is published and installs it in one click. Your browser does the checking and the download; the device itself never reaches the internet. An update that fails to start rolls back to the version that worked.

To go back to an older release, turn on Let the device fetch releases itself in the same place; that one does let the device talk to GitHub, which is why it is off too. Or download that release’s -merged.bin for your board from GitHub and flash it over USB: the web flasher takes a file under “Install another version from a file”.

Open Media (the disc button on the left) and press Download it to the rescue slot. The device fetches netboot.xyz from its site into a 4 MB partition in its own flash — no card needed. Pick Rescue image, turn on Expose virtual media, and boot the target from the USB drive it now sees. netboot.xyz shows a menu of installers and rescue systems (Debian, Ubuntu, Fedora, Clonezilla, memtest and more) and loads the one you pick over the network, so the target needs internet access, not the device.

For a full installer ISO, use a microSD card: upload the file from the browser, or paste a link under the card list and the device downloads it itself. On exFAT an image can be over 4 GB.

Three wires: the target's TX to the device's RX, the target's RX to the device's TX, and ground to ground. Then turn it on in Settings → Power → Serial console, pick the two pins and the speed (115200 for Linux, often 9600 or 115200 for a PC BIOS), and open it with the terminal button at the bottom left. Any two free GPIOs work; avoid 37 and 38, which many boards wire to their own USB-to-serial chip. On the Function EV board GPIO 5 and GPIO 4 are free.

• 3.3 V logic — a Raspberry Pi (GPIO 14 and 15, with enable_uart=1 in config.txt), a router's 4-pin header, most single-board computers: wire it straight in.
• RS-232 — the 9-pin COM port of a PC or a server: ±12 V, which destroys a 3.3 V pin. Put a MAX3232 module in between.
• 5 V TTL — a level shifter, or at least a divider on the device's RX.

Nothing comes through? Swap TX and RX first, then check the speed. To test the device alone, join its TX and RX pins with one wire: whatever you type comes straight back.

Being an ESP32-P4 board is not enough. Five things decide it, and a board that misses any one of them cannot run ESP-KVM as it is:

• 32 MB of PSRAM. The frame buffers are allocated once, for the largest mode the bridge can deliver: 12.5 MB at 1080p on rev 3.x silicon (three buffers of 1920×1088 YUV422), 11.9 MB on rev < 3.0 (two of 1920×1080 RGB888) — before the H.264 encoder asks for its reference frame. An 8 MB part cannot hold even the first of those, and video shuts itself off with an explanation.
• 16 MB of flash. Two OTA slots and the rescue image do not fit in 4 or 8 MB.
• A camera connector the bridge can reach. Two CSI-2 data lanes, and 3.3 V and I2C on the same connector or somewhere you can wire them from. Some boards bring only 1.8 / 2.8 V sensor rails to the FPC and level-shift the I2C down with it — then a ribbon alone is not enough.
• USB OTG-HS on something you can plug into the target. A USB port or a header. A board that only exposes D+/D− on an edge connector needs a carrier board first.
• A way onto the network — an Ethernet PHY on the board, or an onboard ESP32-C6.

Not sure about a board you already have? Plug it in and read it in the browser: it shows the chip revision, the flash size and the PSRAM.

A worked example: the LILYGO T-Halow P4 is an ESP32-P4 with a camera FPC, an ESP32-C6 and Wi-Fi HaLow, and it fails on four of the five. It has 8 MB of PSRAM; its Ethernet RMII and its USB OTG D+/D− are brought out only on the M.2 edge connector, so there is no PHY and nothing to plug the target into; and its 24-pin camera FPC carries no 3.3 V and a 1.8 V I2C. The C6 is wired exactly as on the Function EV board and would work — but the rest is a carrier board and a custom ribbon away, and the PSRAM still rules out 1080p.

One thing worth checking with the schematic rather than a product photo: which camera connector. The 15-pin, 1.0 mm one is the Raspberry Pi 4 camera connector; the 22-pin, 0.5 mm one (on the P4-ETH, for one) is the Pi 5 kind and carries the same signals. The C790 has both and comes with a ribbon for each; a capture board with only the 15-pin one needs an adapter ribbon for a 22-pin board. And on either, 3.3 V and a 3.3 V I2C have to be on the connector.

About a dozen ESP32-P4 boards have been read through this list, the ones that fail included — mostly on USB, not on memory. They are written up in docs/PORTING.md. If yours is not there, open an issue with a link to its schematic.

Wi-Fi HaLow, for what it is worth, is not a way around any of that: the modules on those boards use a vendor driver ESP-IDF does not carry, and 802.11ah’s narrow channels cannot hold a video stream anyway.