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.

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.

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.

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 camera connector, and the ribbon that comes with a C790 plugs into it as it is. The 22-pin, 0.5 mm one carries the same signals but needs an adapter ribbon. 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.