kiosks, panels, signage

One stackThe whole fleetNo royalties

You write the interface once — on a regular computer. Then you flash the board. Same app on screen, updates over the network, nothing to pay per device for the engine.

60 fps on a Raspberry Pi 4. Image around 150 MB. One product instead of a GUI toolkit, an image builder and an OTA vendor.


60 fps
on a Raspberry Pi 4 GPU
~150 MB
system image with GPU
~250 MB
RAM in use
~20 s
from power-on to a usable screen

Runs on
Raspberry Pi 4 aarch64 · V3DVRadxa Zero 3E aarch64 · PanVKRadxa Rock 5C aarch64 · PanVKQEMU aarch64 · softwarePi 5 · RISC-V coming later

the usual mess

Four vendors. Four invoices. One kiosk.

A typical kiosk stack is glued together. Each piece costs money and can fail on its own.

Too many products

GUI toolkit, Yocto image, OTA vendor, device console — four contracts, four support lines, and often a royalty on every unit you ship.

Licenses get in the way

Commercial UI stacks bill per device. Closed kiosks struggle with LGPL rules. If you need a stack you can actually audit, that combination falls apart.

Heavy and slow

A Chromium kiosk sits on about a gigabyte of RAM and crawls on Pi-class boards. Android needs gigabytes and half a minute to boot. A compositor eats a third of the frame before your UI draws.


from desk to board

Write. Flash. Run. Update.

One path from a desktop app to a fleet of boards. No extra embedded toolchain. No Docker on the device.

Write.

Build and debug the same app on Windows, Linux or macOS with the Xenolith SDK.

Flash.

Get a bootable image: system, kernel, your program. No six-month Yocto project.

Run.

One native binary draws straight on the screen. No window manager, no browser, no container.

Update.

Push a new app without rebooting the board. Push a new system image with a spare slot and automatic rollback.

Write Flash Run Update

What you ran on the computer is what runs on the board. Not a port.


the image

A small kiosk image

The board boots a locked-down system: only what it needs, a check that nothing was tampered with, and the picture goes straight to the panel. About 150 MB. Cheap flash is enough.

Straight to the panel

Vulkan draws on the display itself. No X11, no Wayland, no extra compositor between your UI and the glass.

Locked system partition

The system is read-only and checked on boot. Your app and fleet data live on a separate volume.

GPU when you have one

Hardware graphics on Pi 4, Zero 3E and Rock 5C. If the GPU driver is missing, we draw on the CPU.

One file is the app

The kiosk is a single Xenolith program, not a browser or a container. Replacing it is copying a file.


kernels

Same app. Kernel of your choice.

The interface does not change when you change the kernel. Linux with a GPU is what we use in production. Embox and NuttX are there when you need a real-time kernel.

shipping

Linux

Picture goes to the screen. Hardware graphics on Raspberry Pi 4, Radxa Zero 3E and Rock 5C. Software render if there is no GPU driver.

shipping

Embox

The same kiosk on HDMI — Raspberry Pi 4, Zero 3E and Rock 5C — on a real-time kernel.

partial

NuttX

The kiosk already runs in QEMU and on a Raspberry Pi 4. We are still finishing this path.

For shipping devices today, use Linux with a GPU.


boards

What it runs on

Where the GPU driver is ready, we use it. Where it is not, we draw on the CPU. One image per board.

runs today
Board GPU CPU draw
Raspberry Pi 4 (VideoCore VI)
Radxa Zero 3E (Mali-G52)
Radxa Rock 5C (Mali-G610)
in the works
Board GPU CPU draw
Raspberry Pi 5 (VideoCore VII)
VisionFive 2 Lite (PowerVR BXE-4-32)
can run on CPU
Board GPU CPU draw
Rockchip RK3399 (Mali-T860)
NXP i.MX 8 QuadMax (Vivante)
Other 64-bit ARM boards

GPU means hardware graphics. CPU draw means software rendering. Pi 4, Zero 3E and Rock 5C are tested on real hardware.


the fleet

See the devices. Update them. Fix them.

An agent on each board and a console in the browser: bring a device online, watch it, update it, open a terminal if something breaks.

Update the app

Put a new program on the data partition and restart the kiosk. The board does not reboot. You do not rebuild the image.

Update the system

Write the new image to a spare slot, reboot, check. If boot fails, the board rolls back by itself.

Who is online

Devices report in. The console shows what is alive, stale or broken.

Operator console

A web page with the device list, update actions and a remote terminal for diagnosis.


for developers

Flash once. Change the app in seconds.

Desktop is the device

The program you debug on a PC is the program on the board. You do not rewrite it for the kiosk.

Replace the app

After the first flash, copy a new file over SSH or from a USB stick. Rebuild the whole image only when the system itself changes.

No months of Yocto

System, kernel and app become a bootable SD or USB image in minutes.

Works with coding agents

Build and flash instructions ship with the stack, so an agent can follow them without a separate briefing.


thin client

The screen draws. Data stays on the server.

Optional: the terminal only shows pixels. Logic and sensitive data never leave the server — for payments, ATMs, medical kiosks.

The picture can already stream over a secure link. Rolling this out to a fleet is available on request.


compare

Next to the usual options

UI, image and updates in one product. The picture goes to the display. You can change the kernel.

Xenolith OriginQt / Boot to QtChromium kioskAndroid + MDMbalena / Torizon
UINative Vulkan on the panelQt + compositorBrowserAndroid UIApp in a container
Image size~120–150 MBGigabytes, YoctoGigabytes2–4 GB+Container layers
Engine royalty$0Per device / seat$0$0n/a
Fleet / OTABuilt inAdd Mender and friendsDIY / MDMMDM subscriptionStrong
Desktop = deviceYesNoNoNoPartly
KernelLinux, Embox, NuttXLinux onlyLinuxAndroidLinux + containers

where it fits

Unattended screens, all day

Self-checkout and POS

Kiosks and municipal machines that need a snappy screen on a cheap ARM board.

Operator panels

HMI and SCADA where the picture and a stack you can trust matter more than a desktop OS.

Digital signage

Playback that does not leak memory and need a nightly restart.

Charging, parking, tickets

Outdoor machines where board cost, flash size and time-to-screen are tight.

Payments and medical

The thin client keeps user data off the terminal entirely.

Your own toolchain

Own compiler, GOST cryptography in the SDK, no Qt license and no extra platform SDKs.


status

What works now

On real boards today — and what we are still building.

shipping

Linux on three boards

Raspberry Pi 4 at 60 fps, Radxa Zero 3E and Rock 5C. Bootable images, HDMI kiosk, tested on hardware.

shipping

App updates without reflashing

A new program from the console, or over SSH while you develop. The system image stays put.

shipping

Embox kiosk

The same three boards, a real-time kernel, software rendering on HDMI.

partial

Fleet console

Device list, status, app and system updates, a web console. Several devices in QEMU. Still being hardened for production.

partial

NuttX kiosk

Runs in QEMU and on a Raspberry Pi 4. Same app, different kernel.

in development

More boards, faster boot

Raspberry Pi 5, VisionFive 2, staged updates, a quicker start from power-on.


next step

Try it on a fleet.Ship the device.

If you build kiosks, operator panels or signage and you are tired of paying four vendors — write to us. The engine is open. Origin is the image, the updates and the console.

Request a pilot Xenolith Engine GitHub