The eight boards

What runs on each of the eight, and how a screen reaches each panel. Each board's numbers — its panel, key row, refresh time and body — are in the vendors reference; this page is what the numbers cannot say.

The simulator and a real firmware read the same Board, which is what makes "develop in a window, then flash it" true rather than aspirational. A board also carries its bezel — the body around the panel in tenths of a millimetre, every key placed — so the simulator can draw a device rather than a rectangle.

Used by xpui-simulator, xpui-gallery, xpui-rp2040 and xpui-esp32 — every one of them a caller, never a library below one.

Pimoroni: Badger 2040, Tufty 2040, Inky Frame

The keys are not decoration. xpui-rp2040's src/buttons.rs resolves a real GPIO pin by looking a key up by its label in the bezel described here, so a label changed here changes which switch does what on the hardware. Bezel::button_labelled is that lookup.

Two of the three run. The Badger 2040 and the Tufty 2040 have firmware in xpui-rp2040 and have been run over a debug probe. The Inky Frame is described but not built: it exists so a screen can be laid out and looked at for its seven-colour panel in the simulator.

Xteink: X3, X4, X4 Classic, X4 Pro

How a screen reaches one of these panels. They are driven by the firmware that ships on them, so the route is that firmware hosting xpui over the C ABI — xpui-cpp is that boundary — rather than a second driver for the same glass.

xpui-esp32 carries a bare-metal image for the X3 that builds and links, with Panel::present marked where a panel driver would go. There is no published Rust or C++ driver for these panels, so what reaches the glass on that route is not yet proven; the geometry is, in the simulator and in the firmware's own board configuration, and it is what lays a screen out correctly for all four.

The X4 Classic has no image either. It is the X4 Xteink sell today, and it moved from the X4's ESP32-C3 to an ESP32-S3, as the X4 Pro did, so the X3's image is not one it can run. Its route is the same as the others': the firmware that ships on it, hosting xpui over the C ABI.

Seeed: Sticky

What the crate is for. The Sticky's panel is driven by the firmware that ships on it, and a screen reaches it by that firmware hosting xpui over the C ABI — see xpui-cpp. Its measurements are what lays a screen out for it, in the simulator and in that firmware alike.

Nothing has been run on it. xpui-esp32 carries a bare-metal image for the Sticky that builds and links and stops at Panel::present, where a driver would go; what reaches the glass on either route is not yet proven. The geometry is, in the simulator.

No list of all eight

There is no crate here that knows all eight, because there is no such thing as "every board" — a list is something an application assembles from the vendors it ships against, each vendor's ALL concatenated. xpui-gallery's is one: eight entries, and a const assertion that a vendor cannot gain a board without it noticing.

A board that is not one of these eight is adding-a-board.md; why the vocabulary is a crate of its own is design.md.