What This Actually Is

This project is a modular display decoder. The idea is simple: the display becomes a terminal, and the computing happens elsewhere.

Instead of running an OS locally, the device receives rendered frames from a host machine and drives a display directly. The endpoint is not a computer. It is a deterministic hardware display pipeline.

The system is split into three independent layers:

Input — how frames arrive
Wi-Fi, LAN, serial, or custom links. The transport is abstracted so the display pipeline does not depend on a specific interface.

Decoder — core platform
An FPGA translates incoming frame data into panel timing and signaling. Display support is defined in firmware bitstreams rather than fixed hardware.

Output — display layer
Panels connect through small interface modules that handle voltage levels, backlight, touch lines, and panel-specific electrical requirements.

This separation means displays, interfaces, and host systems can all change independently.

Why This Exists

Because I have fun doing this and I want a communicator I can tinker with and can run a nice OS as well- Also most devices tightly couple compute + OS + display. That makes them hard to reuse, hard to repair, and obsolete as soon as software support disappears.

This project takes the opposite approach: the display endpoint stays minimal and stable, while performance scales on the host. Upgrading compute does not require replacing the device.

The focus is not building another handheld computer. The focus is building a reusable display endpoint that can be embedded into anything.

Current State

The architecture is implemented and running.

Frames are rendered on a host machine, encoded, transmitted, decoded in hardware, and scanned out directly to the panel. The endpoint does no high-level rendering and runs no desktop stack.

Measured full system consumption while actively streaming and driving a 720×720 panel at full brightness is ≤1.5 W total.

That includes decoding, display driving, and network operation.

Why Not Just Use VNC, RDP or X2GO?

Remote desktop stacks assume a full client system with a GPU, window manager, and large software footprint.

This platform is different:

• hardware decode instead of software client

• fixed pipeline timing instead of variable scheduling

• minimal RAM and code footprint

• deterministic scanout

• predictable power usage

It is not a replacement for desktop remoting. It targets a different class of problem: ultra-low-power display endpoints.

What Makes It Different

The hardest part of custom hardware is always the display. Panels differ in signaling, timing, voltage, initialization, and documentation quality. Traditional designs lock support to one specific panel.

Here, one decoder platform can drive many displays. Supporting a new panel means adding a firmware configuration rather than redesigning hardware.

The goal is not one device. The goal is a reusable display ecosystem.

Roadmap Direction

Development is now focused on strengthening the platform rather than adding random features.

Current priorities:

• expand verified display compatibility list

• add GPU-accelerated encoder path (OpenGL-capable hosts)

• refine PCB for reproducible assembly

• package system into a clean demo device

• design a simple hardware keyboard module

The existing software encoder already works reliably. Hardware acceleration is about efficiency headroom, not basic functionality.

Modular Design Philosophy

Everything is structured so parts can be swapped independently:

• change display → update bitstream or swap bridge

• change input link → swap module

• change host → no device change required

The endpoint is intentionally simple so it stays stable while everything around it evolves.

Target Audience

This is for people who want control over their hardware:

• embedded developers

• FPGA users

• system integrators

• hardware hackers

• anyone building custom devices with...