Introducing FreeInkUI, a UI framework built for e-paper
Published on June 10, 2026 by jmitch
Building a user interface on e-paper is its own kind of hard. Most firmware ends up with hand-rolled layout code for every screen, and a rewrite for every new board.
This release changes that.
FreeInkUI is a new, optional UI layer in the SDK, designed from the ground up for e-paper firmware.
What it is
FreeInkUI is a memory-bounded, immediate-mode UI system. Think "Tailwind for e-ink" without a web-style runtime. You describe your screen each frame; it lays out fixed slots, draws the components, and routes input.
A few things we're especially excited about:
- Actions, not hardware. Components register semantic actions. The same button can be driven by touch, focus navigation, a side key, or a swipe, and the component never references a physical pin. Port the UI once; it works across every input style.
- Virtualized lists. Long menus and book libraries lay out and hit-test only the rows that fit on screen. The app keeps the data; the UI keeps it cheap.
- One-call dark mode. InvertedDrawTarget flips every color (component defaults, theme styles, and your own chrome) in a single wrapper. No per-draw dark-mode flags anywhere.
- A real component set: status bars, pill tab bars, keyboards with glyph art, dialogs, metric cards, bar charts, battery glyphs, and a cover carousel for library screens, all themeable through a compact token system.
- Host-testable. It's freestanding C++17 with no Arduino or ESP-IDF dependency, so the layout, routing, and virtualization logic runs in plain unit tests on your laptop.
Bring-your-own everything
FreeInkUI stays deliberately small. It never reads files, parses JSON, or decodes images. Your firmware keeps its existing fonts, localization, theme loader, and page rendering, and plugs them in through tiny adapters. There are header-only bridges for the SDK's own GfxRenderer and InputManager, so adopting it can be as small as porting a single screen and deleting the layout code it replaces.
Why it matters for FreeInk
Until now, FreeInk freed you from device-specific drivers. FreeInkUI extends that same idea up the stack: one UI codebase that renders across an Xteink, a Murphy M3, a LilyGo T5, or an M5Paper, regardless of panel size, orientation, or input hardware.
It's MIT-licensed and free to use, commercially or otherwise, like the rest of the SDK.
📖 Full guide: docs/freeink-ui.md (https://github.com/Free-Ink/freeink-sdk/blob/main/docs/freeink-ui.md)
This release changes that.
FreeInkUI is a new, optional UI layer in the SDK, designed from the ground up for e-paper firmware.
What it is
FreeInkUI is a memory-bounded, immediate-mode UI system. Think "Tailwind for e-ink" without a web-style runtime. You describe your screen each frame; it lays out fixed slots, draws the components, and routes input.
A few things we're especially excited about:
- Actions, not hardware. Components register semantic actions. The same button can be driven by touch, focus navigation, a side key, or a swipe, and the component never references a physical pin. Port the UI once; it works across every input style.
- Virtualized lists. Long menus and book libraries lay out and hit-test only the rows that fit on screen. The app keeps the data; the UI keeps it cheap.
- One-call dark mode. InvertedDrawTarget flips every color (component defaults, theme styles, and your own chrome) in a single wrapper. No per-draw dark-mode flags anywhere.
- A real component set: status bars, pill tab bars, keyboards with glyph art, dialogs, metric cards, bar charts, battery glyphs, and a cover carousel for library screens, all themeable through a compact token system.
- Host-testable. It's freestanding C++17 with no Arduino or ESP-IDF dependency, so the layout, routing, and virtualization logic runs in plain unit tests on your laptop.
Bring-your-own everything
FreeInkUI stays deliberately small. It never reads files, parses JSON, or decodes images. Your firmware keeps its existing fonts, localization, theme loader, and page rendering, and plugs them in through tiny adapters. There are header-only bridges for the SDK's own GfxRenderer and InputManager, so adopting it can be as small as porting a single screen and deleting the layout code it replaces.
Why it matters for FreeInk
Until now, FreeInk freed you from device-specific drivers. FreeInkUI extends that same idea up the stack: one UI codebase that renders across an Xteink, a Murphy M3, a LilyGo T5, or an M5Paper, regardless of panel size, orientation, or input hardware.
It's MIT-licensed and free to use, commercially or otherwise, like the rest of the SDK.
📖 Full guide: docs/freeink-ui.md (https://github.com/Free-Ink/freeink-sdk/blob/main/docs/freeink-ui.md)