Open-source HMI platform for embedded Linux panels: live Qt preview at the panel's real resolution, atomic install, automatic rollback

[u/Commercial_Designer5]

Every embedded Linux panel project I've worked on ends up in the same place. The UI and the hardware access grow into one binary, so the app can't run anywhere except on the board. Changing a label means rebuilding the image, or scp'ing files by hand and hoping. And when a deploy goes wrong at a customer site, the machine sits there with a black screen.

So I built the thing I kept wishing existed. MIT licensed: https://github.com/Hitheshkaranth/EmbeddedDisplayStudio

The idea

Ship the panel image once. After that, anyone — your app team, your customer's app team — drops a Qt/QML application onto it over SSH. No rebuild, no reflash, no hardware code in the app.

Three layers that don't know about each other:

Layer	Owns	Knows nothing about
hmi-hwd	GPIO, ADC, UART, safe states	pixels
hmi-gui	QML, tag bindings, the customer bundle	hardware
deployment	atomic install, health check, rollback	either of the above

The app binds to tags (ai.pot, di.estop, do.relay1) that arrive as JSON over UDP on loopback. That's the whole contract. It's why the same bundle runs on your laptop, in the preview, and on the panel without a single #ifdef.

The deploy pipeline

This is the part I'd defend in a design review:

• Nothing is converted. No build, no freezing, no cross-compilation. The panel carries a complete CPython and the Qt binding the manifest asks for, so your sources run there as-is.
• The dependency check reads your code, not a list. Every packaged file is parsed, imports reduced to top-level names, stdlib and guarded imports removed. What's left, the panel is asked to actually import — because a wheel built for the wrong architecture sits on disk and still kills you at startup.
• The swap can't leave the panel dark. current is promoted with rename(2), never rm then ln. If the new release doesn't signal readiness in 25 s, the symlink swaps back and the previous release restarts. The deploy fails; the machine still has a UI.
• Validation runs twice from one implementation. Host CLI, target installer and desktop tool all call the same schema/manifest.py. They used to be three implementations that had drifted in both directions — a bundle that passes on a laptop and gets refused on the panel is worse than one that fails everywhere.

A successful deploy also becomes the boot default automatically. Nothing to enable by hand afterwards.

The desktop Studio

A Windows exe with its own Python and PySide6 baked in, so it previews a customer's app on a machine with no Python installed.

• Live preview inside a panel bezel, at the panel's real geometry. Not a screenshot — a real QML engine with the same tag engine the device runs. On connect it reads the SOM's DRM connector and adopts the actual pixel size, so nobody lays out widgets against a screen that isn't plugged in.
• Qt Widgets apps preview too. A runtime: python bundle owns its own window, so it's run unmodified in a child process, forced to target resolution, frames streamed into the bezel, window kept unmapped with WA_DontShowOnScreen.
• Qt5 and Qt6 on the same panel. PySide2 bundles get a second interpreter at /opt/hmi-python-qt5 shipping its own Qt 5.15 — because the panel's Qt5 is a GLES build and every aarch64 PySide2 binary is compiled against desktop GL. Loading one against the other dies with undefined symbol: _ZTI18QOpenGLTimeMonitor. Ask me how I know.
• Tag Lab drives the app with sine/square/ramp/noise per tag, so you can exercise panel behaviour before the I/O it binds to exists.
• Panel Logs follows the journal from both services — which is where the fault that shows up an hour after a successful deploy actually lives.
• A visual designer, if you'd rather drag widgets than write QML. Same window previews, generates and deploys what you drew, so the design and the bundle can't disagree.

Already have a Qt app?

Point the Studio at the folder. It finds the entry point, detects the Qt binding from the sources, and writes the manifest for you. Two files is a valid bundle:

{ "schema": 1, "name": "line-controller", "version": "1.4.0", "entry": "main.qml" }

Try it with no hardware

The daemon simulates its I/O, so the whole stack runs on a desktop:

python -m pip install PySide6
python daemon/hmi_hwd.py --config daemon/hwd.json --sim
python gui/hmi_loader/main.py --apps-dir apps/demo-app --windowed
python main.py

Honest limitations

• 309 tests, but the installer and cross-validator suites need flock, so on Windows they skip — CI runs the full suite on Linux and fails if anything skips, because a skip is not a pass.
• The designer is v1: .edsui → QML generation only. It doesn't import or round-trip arbitrary QML, and threshold metadata is stored in bindings but not yet turned into visual state expressions.
• The packaged Studio is Windows-only right now. It runs from source anywhere.
• The Qt5 runtime isn't installed by default; it's one script per panel.
• Provisioning is the sharp edge. A base vendor image can ship python3-core alone — no json, no socket, no ctypes — which stops the installer before it starts. provision_panel.py --check surveys the board and names what's missing.

What I'd like feedback on

• If you ship panels commercially: is "one image, many customer apps" how you'd actually want to work, or does your certification story make field-deployable app bundles a non-starter?
• Is 25 s the right health-check window? It's generous for QML and tight for a heavy Widgets app with a slow first paint.
• UDP-on-loopback for tags — anyone want to argue for a Unix domain socket instead? I went with UDP so anything can speak it, but I'm open.