The next steps are about making the decoder ecosystem more flexible in real builds:

• Improve multi-display setups, including experiments with several small displays acting as one larger screen
• Extend the supported display list (more sizes, timings, and panel types)
• Create a simple, stupid hardware keyboard

From my own experience, display integration is always the hardest part when trying to keep hardware flexible. Every panel behaves differently — signaling, timings, voltage levels, initialization sequences — and that’s usually where otherwise modular designs suddenly become rigid. A big focus of this roadmap is making that problem easier, both for me and for anyone building on top of this system.

• Expand the supported display catalog with verified timings and wiring notes
• Keep the decoder firmware update flow simple so builders can switch panels without redesigning the whole device

The current setup supports multiple display configurations, and multi-display output is a separate software target. A big next step is better support for setups with more than one display.

One direction is treating several small displays as one larger virtual screen. Another direction is splitting content across multiple display endpoints. This is useful for dashboards, terminals, control panels, handheld layouts, and other custom builds where one normal monitor layout is not the point.

• Experiment with several small displays acting as one larger screen
• Support layouts where different endpoints show different parts of the same setup
• Keep the software flexible enough for dashboards, terminals, and custom control panels

Touchscreens are fine for demos, but the demo device needs real keys. The plan is not a fancy keyboard. It’s a simple, reliable input module that makes the device usable without staring at a glass slab.

• Basic layout optimized for terminal and navigation
• Low part count, easy to build
• Designed as a module that others can replace or redesign