A Flexible Display Decoder Ecosystem
"The display becomes a terminal. The computing happens elsewhere."
Table of Contents
Core Architecture
The system is split into three independent layers:
Input — how data arrives
Any interface can be used: Wi-Fi, cellular, LAN, serial, or custom links.
Decoder — the core platform
An FPGA-based decoder translates incoming frames into display signals. Instead of building separate hardware for each display, firmware bitstreams define how the FPGA drives a panel.
Output — the display layer
Any panel can be used as long as the electrical interface is matched. Output modules or small bridge boards can handle voltage levels, touch wiring, brightness buttons, or other panel-specific requirements.
This separation allows builders to reuse displays, mix components, and adapt the system without redesigning everything.
Why FPGA
Displays are the hardest part of custom hardware. Most panels use undocumented protocols, proprietary timing, or unusual electrical requirements. Traditional designs hard-code support for one specific panel.
This project takes the opposite approach:
One decoder platform → many displays
Because the decoder runs on an FPGA, support for a new panel is just firmware. You update the bitstream instead of redesigning hardware. The goal is an ecosystem where display support grows over time rather than being fixed at manufacture.
Prototype History
Earlier iterations used a microcontroller-based design with Wi-Fi streaming and framebuffer decoding. That phase proved the concept: low power, low latency remote display devices are practical — you can see the original goals on the archived project page.
At 720×720 resolution, however, the software decoder running on the MCU reaches its performance ceiling. The system remains usable, but decoding load scales directly with frame complexity, leaving little headroom for higher frame rates, more complex compression, or larger displays. This limitation is architectural: a general-purpose microcontroller executing a software decoder must spend CPU cycles per pixel, per frame. Once those cycles are exhausted, scaling further requires a different class of hardware.
The current generation therefore moves beyond that prototype toward a dedicated decoder architecture designed specifically for flexibility, modularity, and reuse, shifting decoding into programmable logic to sustain higher throughput while keeping power use low and freeing the control processor for coordination instead of pixel processing.
Power Use and Performance
Efficiency is a core design constraint.
The current prototype, driving a 720×720 display at full brightness while actively streaming, consumes:
That includes decoding, display driving, and network operation.
- battery-powered handheld use
- always-on embedded displays
- silent passive cooling
- long runtime with small cells
The architecture scales: performance improvements mainly happen on the host system, not the handheld unit. That means upgrading compute power does not require replacing the display device.
Why Not Just Use VNC, RDP or X2Go?
Standard remote desktop protocols were not designed for ultra-low-power embedded display terminals. They assume a full operating system, a GPU-driven desktop environment, and relatively heavy client software.
This system is different by design:
- The decoder is hardware-driven, not a software client
- Rendering is optimized for deterministic frame delivery
- The display pipeline is purpose-built, not generic desktop streaming
- Resource usage is predictable and minimal
Traditional remote desktop stacks prioritize compatibility and features. This project prioritizes efficiency, determinism, and hardware simplicity.
It is not trying to replace those protocols. It targets a different problem: building minimal display endpoints that can run for long periods on extremely low power while remaining flexible and hackable.
Who This Is For
This platform is designed for people who want control over their hardware:
- embedded developers
- FPGA users
- hardware modders
- system integrators
- DIY builders
Anyone who wants to integrate their own display, input hardware, or interface into a custom system can use the decoder as a foundation.
Availability Model
The hardware will be available in multiple forms:
- Full demo device — ready to use
- Individual modules — decoder board, bridges, adapters
- Integration components — for custom builds
Buying hardware supports continued development and refinement of the platform. It is both a usable device and a way to fund progress.
Open Source Approach
Not everything will be open immediately. The release strategy is staged:
- software → always free
- mature firmware → open source
- stable hardware revisions → open schematics
Some components remain closed temporarily while still evolving to avoid locking unstable designs into public releases. Once stable, they are published.
Long-Term Vision
The long-term goal is not just a device, but an ecosystem:
- reusable display hardware
- firmware-defined display support
- modular I/O expansion
- community-driven modules
Instead of replacing hardware when requirements change, you update firmware or swap modules.
Interested?
If this idea resonates with you — whether as a builder, developer, or hardware experimenter — you can get involved.
You’ll be able to:
- buy a complete device
- buy individual modules
- integrate parts into your own hardware
- contribute improvements or extensions
This project grows through people who want more control over their tools.
This is a real project. Boards are running. Displays are rendering. Frames are streaming. If you wanna support me, follow me and get updates. If I find enough like-minded people I'm gonna sell these boards.
Want to give feedback? Find the discussion thread on Hackaday or write me a PM via Reddit or BlueSky.
— Gitzi