How I made a 60fps Eink monitor, the Modos Flow

TL;DR: After four years, the author built a custom 13.3-inch Eink display running at 60fps, breaking the traditional trade-off between refresh rate and contrast by updating each pixel independently. The entire design was open-sourced. ## From laptop secondary screen to a chance breakthrough at 60fps Initially, the author set out to build an Eink laptop, only to find that all Eink-compatible systems-on-chip were designed for low-power e-readers, with slow processors and limited interfaces that couldn't meet laptop needs. So they inserted an FPGA-based driver chip between the SoC and the screen — essentially building their own controller. The original aim was simply to give the secondary screen (similar to a large Touch Bar) a reasonable refresh rate, with no intention of high frame rates. But while designing the controller, the author suddenly had the idea of achieving 60fps on Eink. After a trial, it turned out to be possible. ## Why can't traditional Eink reach 60fps? Traditional Eink controllers use a global update timer. Each refresh takes about 100 milliseconds, meaning a new image might have to wait at least 100ms before processing begins. Speeding up the timer could yield higher frame rates, but the ink particles respond slowly — refreshing too fast would make the image fade. This forces a trade-off between refresh rate and contrast. Some controllers use multi-region updates (4–16 independent areas), but these require manual software management and still have limitations. The author's approach is radically different: **treat each pixel as its own independent update region**. When a pixel changes, it starts updating immediately, with no waiting. The result is high frame rate and high contrast simultaneously — the speed-vs-image-quality trade-off disappears. The price is memory bandwidth: a traditional controller handling a 13-inch monochrome image needs only 20 MB/s, while this solution requires 540 MB/s. That means using DDR3 instead of regular SRAM, and DisplayPort instead of USB — a costly affair, completely unnecessary for reading, but transformative for a monitor. ## Four years of iteration: from circuit board to product The goal shifted to making a truly good monitor. ### Dithering algorithms and grayscale display Eink itself cannot display grayscale without flicker. The author implemented three algorithms: - **Bayer dithering**: fast, but with visible texture. - **Blue noise dithering**: visually better. - **Error diffusion**: best quality, but hard to scale to high resolutions. Dithering is never as good as true grayscale. The author adopted a hybrid mode: when the image changes, switch to a fast binary mode, then re-render in grayscale once stable. Works well for reading, but not for other scenarios. Building your own controller means you can optimize for your own use case, unfettered by preset modes. ### Hardware iteration - First prototype used a full-size DisplayPort, later swapped to USB Type-C with DisplayPort alternate mode. - After the integrated power management chip was discontinued, switched to discrete DC-DC converters. - Added full voltage and current monitoring to protect the screen from accidental latch-up events. - Each change required at least one PCB respin; over 20 in total. ### Productization hurdles After receiving the first enclosure design, it finally looked like a real product. It was shown at Hack Day, Supercon, Latchup, and Crowd Supply teardown events — people were excited. The author quit their job to focus full-time. #### First blow: panel generation change Right after going full-time, Ink Corporation released a new panel — higher resolution, better specs, cheaper. But everything had to be redesigned for the new panel: higher bandwidth decoder IC, DDR memory, FPGA, power supply. Almost every component on the board had to be redone, delaying progress by at least six months. #### Second major change: design the enclosure first, then the circuit board Previously the board was designed first, then a case made to fit. The final product reversed that: determine the chassis dimensions and mounting points first, then make the board fit. The design became more optimized and unified, but took much longer. #### Chip supplier issues Fully assembled prototypes were unstable: random glitching, video signal loss, initialization failures. The video decoder chip supplier refused to help, wouldn't even provide driver code. The author paid extra under the table to get source code, but the code didn't work. The vendor demanded more money for working code. Meanwhile, sales kept pushing a more expensive chip. Months and thousands of dollars wasted. Eventually switched to another supplier, which was far easier to work with — but their chip wasn't available when the project started, so it wasn't an option before. ### Final feature integration - Touch support (new touch controller, drivers) - Flicker‑free front light - Frame rate limiter (lower frame rates are useful for sharpness) - Low‑power mode (saves power when unplugged) - On‑screen display menu to control all functions Each feature is described in a single sentence, but each one took weeks to implement. ## Current status and open‑sourcing Four years after the first prototype, the final product: - 13.3 inches, up to 60fps - Extremely low latency - Multiple display modes (algorithms controlled by the author) - Touchscreen, front light, color option - **Fully open source**: all hardware design, FPGA code, and firmware are public The project launched on Crowd Supply, and all designs are open source. ## Conclusion The author does not regret the journey. “When I make a decision, I follow through. When I solve a problem, it’s solved completely. I don’t need to convince anyone to add a feature. It’s exhausting, but there’s a sense of accomplishment — which isn’t always the same as happiness.” This is only the beginning. Source: https://youtu.be/nHbA2-_qzH4