Glider: an open-source E Ink monitor built around low refresh latency

Two repositories, one monitor, and a mirror to keep straight

The first line of business is a scope clarification that saves a lot of confusion. The README states that this repository contains the hardware design only, and that the gateware running on the FPGA is the author's separate open-source Caster design, hosted on GitLab. The repository description records that this GitHub project is a mirror of the glider repository on GitLab, which means the canonical history is elsewhere and this copy tracks it.

So there are three artifacts in total. The KiCad board design and the STM32 firmware are here, the RTL is in Caster, and this repository also carries a `Caster` entry in its own file tree alongside a `.gitmodules` file, which is how a submodule arrangement for a project split across two hosts would look. The tree also holds `fw/`, `pcb/`, `case/`, `scripts/`, `tools/`, `utils/`, a `CHANGES.txt` and an `assets/` directory of photographs.

The last two trees worth naming are `pcb/` and `case/`. Publishing the enclosure alongside the board means someone can build a complete physical object rather than a bare board, which is rarer than it should be in open hardware.

The latency claim, stated as a number rather than a promise

The positioning of the project is low latency, and the feature list gives that a concrete figure: extremely low processing delay of under 20 microseconds. It also names the panel families it will drive, namely electrophoretic display panels with a parallel interface, listing Eink, OED and DES, and says it supports both monochrome and colour filter array panels such as Kaleido. Output modes cover binary, 4-level grayscale and 16-level grayscale, with the binary and 4-level modes described as latency-optimised and a hybrid mode that switches between binary and 16-level automatically.

The other half of the low-latency story is that latency is treated as a controllable property rather than a fixed cost. Regional update and mode switching are runtime-controllable from host software, which is what lets a fast partial refresh be used where a full one would be visible. Dithering is done in hardware, with Bayer, blue-noise and error-diffusion options, and the README states these add no additional latency.

Colour support here means a colour filter array over a monochrome panel rather than a full colour electrophoretic stack, and the distinction is made explicitly in the feature list.

Reading the hardware specification

The hardware section is a short, dense list, and each line tells you something about the design compromises:

Xilinx(R) Spartan-6 LX16 FPGA running Caster
DDR3-800 framebuffer memory
Type-C DisplayPort Alt-Mode video input with onboard PTN3460 DP-LVDS bridge
DVI (via microHDMI connector) video input with onboard ADV7611 decoder
Epaper power supply with up to 1A peak current on +/-15V rail supporting large panels
On-board STM32H750 microcontroller for USB communication and firmware upgrade

Three decisions stand out. Video input is handled by the FPGA taking a standard HVsync signal, per the feature list, which keeps the host side conventional: whatever produces the video does not need to know what an E Ink waveform is. Two input paths are provided, DisplayPort Alt Mode over USB-C and DVI over micro-HDMI, which is redundant for most users and practical for others.

The power rail is the part that surprises people. Electrophoretic panels need high voltage and they draw current in bursts, so a 1A peak on a plus or minus 15V rail with VCOM kick-back voltage measurement support is not generosity, it is the minimum for driving a large panel. The STM32H750 handles USB communication and firmware upgrade, which means you can reflash the board over USB rather than needing a separate programmer.

The throughput figures follow the same honesty: up to 133 megapixels per second with error-diffusion dithering enabled, and more than 200 megapixels per second when it is disabled.

Why the README teaches E Ink theory before describing the board

The table of contents explains the structure better than any summary could. Before the project gets to hardware there are sections on basic theory of operation, advantages and disadvantages, the role of the E Ink controller, screen panel types, using a screen with and without an integrated controller, understanding waveform, greyscale display, colour display, dithering and screen generations. Then come the design sections: low latency drive, hybrid greyscale mode, limitations, hardware design decisions, gateware architecture, firmware functions and resources utilization.

The author says outright why: information about E Ink is hard to gather online, so the README becomes a long document containing not just this project but most of what the author knows about the technology. It also carries a disclaimer that the contents are based on publicly available information and original research, are not endorsed by E Ink, and may contain errors.

That ordering is deliberate and it is the most useful thing here for a newcomer. Waveform selection is the concept you need before you can judge whether a regional update is fast or slow, so it is explained before the gateware architecture section that implements it. For anyone deciding whether to build one, the appendix on using screens without a datasheet and the screen list are where the practical compromises live.

Buying a board, and the split between product and design

Two Crowd Supply products are named for people who want hardware rather than a schematic. The Modos Paper Dev Kit is the board for people who will assemble it, and the Modos Flow is described as a complete monitor usable out of the box. If you already have a Glider board or kit, the README sends you straight to `USAGE.md` for board setup, flashing, development build loops and display configuration, and says nothing more about getting started in the main document.

That division is a reasonable editorial choice. `USAGE.md` is the manual, the README is the explanation, and the table of contents is effectively the index of a textbook that happens to describe one board. The tree supports the same reading: a `scripts/` directory and a `tools/` directory sit next to the design files, which is what you would expect for bitstream and firmware build helpers.

The project is not archived and the last push was on 2026-07-11, with 2,655 stars, 106 forks and 11 open issues. The low issue count relative to the star count fits a project whose community arrives to read the documentation rather than to file problems.

Editorial conclusion

Glider is unusual among open hardware projects because the effort is split honestly in two: the board and firmware live here, while the FPGA gateware that does the actual panel driving is Caster, a separate design by the same author. That means you can read the hardware decisions, the waveform strategy and the regional update behaviour in one place, and you cannot read the RTL that executes them without pulling a second repository. The specification to quote when judging the design is the under 20 microsecond processing delay and the regional update control from host software, both of which come from the feature list rather than from a benchmark. Start with `USAGE.md` if you have a board, then work through the theory of operation section before deciding whether your panel family is supported.

Frequently asked questions

Official sources

1. Issues
2. Modos-Labs/Glider on GitHub
3. README