Hardware-Accelerated Display Streaming Decoder

Description

Low-power, low-latency display streaming in a tiny, hackable hardware stack for builders.

Turning small screens into network-capable display endpoints: the main computer renders elsewhere, while the hardware endpoint receives the stream, decodes it, and drives the display.

Optimizing the whole streaming path for this job: bypassing much of the usual desktop and display software stack, keeping the endpoint lightweight, compact, and efficient.

Staying GPU-vendor agnostic: encoding the video stream on common Intel integrated graphics, NVIDIA or AMD GPUs, or even Raspberry Pi 5 video hardware, without being tied to one GPU vendor or one desktop platform.

Built for dashboards, terminals, cyberdeck-style builds, gaming handhelds, lab tools, and custom embedded UIs.

Details

Gitzian Display Streaming Hardware

Gitzian streams desktop output to supported small displays.

The host machine renders the image. The Gitzian endpoint receives the stream, passes it through the decoder hardware, and drives the attached display.

This makes small screens useful as compact remote displays, dashboards, control surfaces, communicator panels, handheld experiments, lab tools, embedded UIs, and custom hardware projects.

For DIY builds, the decoder module, reference boards, KiCad files, and Python client give you a base you can modify instead of starting from a blank schematic.

What Makes It Special?

Gitzian is built around low-power, low-latency display streaming in a tiny, hackable hardware stack.

The main computer does the rendering. The endpoint stays small and focused: receive frames, decode them, and drive the panel.

The streaming path is optimized for this job. It avoids dragging a full desktop client stack into the display endpoint and keeps the hardware side compact, predictable, and easier to embed.

The host side is not locked to one GPU vendor. The stream can be encoded on common Intel integrated graphics, NVIDIA or AMD GPUs, or Raspberry Pi video hardware.

Example Setups

These two diagrams show the main hardware paths: a normal Windows / Linux host setup and an alternative local Raspberry Pi setup.

Windows / Linux host setup

A Windows or Linux machine renders the desktop, viewport, or application output. The stream goes over the network to the Gitzian endpoint.

On the endpoint side, a Raspberry Pi can run the Gitzian client. The Pi talks to the Gitzian decoder through the Pi HAT or a custom HAT. The decoder then drives one of the supported displays.

The same decoder path can also be used with custom hardware. Instead of the Raspberry Pi client, an Arduino / STM32 / ESP-style board or another embedded controller can feed the decoder over SPI.

This is the useful split: host and transport on one side, decoder and display output on the other side.

Alternative local Raspberry Pi setup

The Raspberry Pi can also act as the local host. In this setup, the stream does not need to come from another computer on the network.

The Pi renders locally and connects to its own Gitzian client through 127.0.0.1. The rest of the hardware path stays the same: Pi HAT or custom HAT, SPI link, Gitzian decoder hardware, then the supported display.

This setup is useful for compact standalone builds, demos, cyberdeck-style devices, local dashboards, and experiments where one Raspberry Pi should provide both the application side and the display endpoint side.

Gitzian Decoder / Open Hardware

The Gitzian decoder is the tiny 21×19 mm core hardware module.

The standard reference setup uses the decoder with a Raspberry Pi HAT on the input side and a display bridge on the output side.

Custom hardware is still built around this decoder. The boards around it are the part you can replace, merge, or redesign.

The Raspberry Pi HAT reference design and the display bridge reference design are open source KiCad designs. You can use them as-is, modify one side, or build your own board around the decoder for a different controller or display setup.

Some signals are routed from the input connector side to the output connector side. This helps if you want to reuse one existing side of the design and replace only the other side.

Some parts are already fully open source. If there is enough interest, I can make more and more of the project open source. Then we can go fully independent as a community, not bound to one specific vendor, manufacturer, or exact board layout.

DIY Hardware

Gitzian can become a highly customized DIY project around the 21×19 mm decoder module.

The decoder has two board-to-board connector sides. One side is the input/controller side. In the standard reference setup this is the Raspberry Pi HAT. The other side is the output/display side. For...

Files

tdo_display_bridge-01-rev08.zip

Display Bridge (Decoder->Display) KiCad files

Zip Archive - 181.51 kB - 06/26/2026 at 19:52

Download

tdo_rpi_header-01-rev09.zip

Raspi Hat KiCad files

Zip Archive - 126.23 kB - 06/26/2026 at 19:51

Download

gitzian_howto_rev02.pdf

How-To setup software, assembly reference designs, etc.

Adobe Portable Document Format - 707.99 kB - 06/26/2026 at 19:49

Preview

Project Logs

Collapse

Software Stack Hardware Accelerated

gitzi • 2 hours ago • 0 comments

The software side now has the hardware-accelerated streaming path in place through the Gitzian GPU Streamer.

The current setup has documented paths for Windows, Linux / KDE Plasma, Raspberry Pi clients, viewport streaming, virtual display setups, firmware updates, and recovery notes.

Gitzian is becoming a small-display platform: ready hardware, a documented host streamer, a Raspberry Pi client, downloads, open reference designs around the decoder, and clearer DIY entry points for people who want to build their own hardware around it.

The software side is hardware accelerated, the setup flow is documented, and the project is now structured as something people can use, hack, and extend.

This opens the door to compact remote desktops, control panels, handheld experiments, dashboards, communicator screens, multi-display setups, lab tools, embedded UIs, and other custom small-screen DIY projects.

Current focus:

more supported displays
multi-display experiments
simple hardware keyboard

Refined project and goals

gitzi • 02/20/2026 at 18:48 • 0 comments

The system is already running smoothly in real-time streaming conditions — and this is before any serious optimization work has even started.

Right now the pipeline is still using early-stage encoder logic and unoptimized paths, yet frame delivery is stable, interaction is responsive, and overall behavior is already well within usable territory. This confirms that the architecture itself is sound and has plenty of performance headroom left once tuning begins.

At this stage I’m not chasing speed yet. The focus is validating stability, timing behavior, and pipeline correctness first. Optimization comes later, once the baseline is fully characterized.

Check out the video to see current performance as-is.

I refined the goals and head over to a full device with battery and a case.

PCB Design completed

gitzi • 02/11/2026 at 18:32 • 0 comments

PCB designed for current roadmap.

Power consumption: Surprisingly low at full brightness ≤ 1.5W
Form factor: Board footprint significantly reduced vs previous revision
Architecture: Split into 3 modular parts for on-demand exchange
- Input: Network module (e.g., WiFi or RJ45)
- Processing: Decoder
- Output: Display driver (supports different display types)

Next steps:

Optimize network stream for full throughput
Perform latency testing
Implement touchscreen support
Publish results in the next few weeks

FPGA Decoder Milestone

gitzi • 10/11/2025 at 09:20 • 0 comments

Summary

Initial FPGA implementation complete for the decoder path.

Lattice STA and simulation confirm the pipeline meets the timing/perf budget for <20 ms/frame at 100 MHz.
This meets the near-term performance target on the roadmap.

Next

Start PCB design for field testing (bring-up + measurements).

Feedback welcome
If you have any questions, recommendations, or general feedback, don’t hesitate.

Discussions