Qt embedded Linux platform plugins and build paths compared
Why the choice matters
Qt embedded Linux is a good fit when a device needs a responsive graphical interface, hardware-accelerated rendering, touch input, and a maintainable application framework on Linux. The main decision is not just whether to use Qt. Engineering teams also need to decide how Qt will reach the display, how the system image will be built, and how the software stack will be maintained after launch. For a single full-screen HMI, EGLFS may be simpler than a compositor-based stack. For multi-application devices, Wayland is usually easier to scale. For production images, Yocto with meta-qt6 gives tighter control than a general-purpose Linux distribution, while Boot to Qt can shorten early evaluation.
This comparison focuses on practical design choices for teams building industrial panels, medical interfaces, kiosk systems, smart appliances, and edge devices. It follows publicly documented behavior from Qt and Yocto sources, but does not treat documentation defaults as universal rules. Graphics drivers, board support packages, licensing, memory budgets, and update policy can all change the right answer for a specific product.
Where Qt sits in an embedded Linux device
A Qt-based embedded Linux system usually has four visible layers. At the bottom are the bootloader, Linux kernel, device tree, GPU driver, display controller driver, input drivers, and storage layout. Above that is the root file system, built with Yocto, Buildroot, a vendor SDK, or a distribution-derived image. Qt then provides the application framework, QML or Widgets UI layer, graphics scene graph, input abstraction, networking, multimedia, and other modules. The final layer is the product application, including its update, logging, recovery, and factory-test logic.
Qt remains common in device UI projects because it covers more than drawing controls. A typical product team needs consistent rendering across hardware variants, touch and keyboard input, internationalization, font handling, animation, display scaling, and a development model where UI code and the C++ backend can evolve together. Qt Quick and QML are widely used for modern animated interfaces. Qt Widgets still appears in tools, configuration screens, and legacy industrial HMIs.
Embedded Linux changes the constraints. Unlike desktop Linux, an appliance may not have X11, a full desktop session, or a user-managed package system. The application may be the only visible interface. Boot time, read-only file systems, watchdogs, limited GPU memory, thermal limits, secure updates, and long-term kernel maintenance matter as much as visual design. That is why the platform plugin and build path should be decided early, not added at the end of a prototype.
Display plugins compared
Qt documentation for embedded Linux describes several platform plugins: EGLFS, VkKhrDisplay, LinuxFB, and Wayland. Their availability depends on how Qt is configured and what the target hardware supports. EGLFS, LinuxFB, and VkKhrDisplay can operate without a conventional windowing system. Wayland requires a compositor and provides a windowing model. In practice, most product decisions come down to EGLFS versus Wayland, with LinuxFB used for simpler or software-rendered cases.
| Plugin or stack | Typical use | Strengths | Limits to check |
|---|---|---|---|
| EGLFS | Single full-screen Qt UI on GPU-equipped boards | Direct path to EGL and OpenGL ES; often simple for appliance-style HMIs | Usually designed around one full-screen Qt window per screen; multi-application behavior is limited compared with Wayland |
| LinuxFB | Simple framebuffer output or systems without GPU acceleration | Useful for basic displays and controlled environments | Does not provide the same accelerated graphics path as EGLFS; advanced Qt Quick interfaces may be constrained |
| Wayland | Systems with multiple graphical processes, compositor needs, or richer session control | Supports a windowing system model and separation between compositor and clients | Adds compositor complexity and another component to configure, test, secure, and update |
| VkKhrDisplay | Specialized Vulkan display paths where supported | Can suit Vulkan-focused graphics stacks | Hardware, driver, and Qt configuration support must be verified carefully |
EGLFS is often the first candidate for a single-purpose device where one Qt application controls the screen. Qt documentation identifies EGLFS as the recommended plugin for modern embedded Linux devices that include a GPU. That does not make it the safest production choice in every case. If the product needs an on-screen keyboard from a separate process, a diagnostic overlay, a browser component in another process, or independent vendor applications, Wayland may reduce long-term architectural friction.
LinuxFB should be considered with clear expectations. It can be helpful for simple interfaces, fallback modes, or boards where GPU integration is not mature. However, if the UI depends on smooth transitions, complex QML scenes, high-resolution display effects, or OpenGL-based components, the team should validate performance early instead of assuming desktop results will transfer to the target panel.
Yocto, meta-qt6, Boot to Qt, and distribution builds
The build path determines how repeatable the product image will be. For early experiments, engineers may install Qt packages on a vendor-provided Linux image and run the application over SSH. That is fast, but it often hides issues that later become production problems: missing runtime dependencies, incompatible GPU libraries, uncontrolled package versions, writable root file systems, and unclear security update responsibility.
Yocto is the common production route for teams that need a custom embedded Linux distribution. The Qt documentation for meta-qt6 describes it as an OpenEmbedded and Yocto layer that provides recipes for Qt modules and supports building Qt applications. It also documents common application recipe classes such as qt6-cmake and qt6-qmake. This matters because many embedded teams still maintain qmake applications, while newer Qt 6 projects increasingly use CMake.
With Yocto and meta-qt6, engineers can select Qt modules, tune PACKAGECONFIG options, align Qt with the board support package, generate SDKs, and produce repeatable images for CI. The trade-off is operational complexity. Yocto has a learning curve, builds are resource-intensive, and layer compatibility must be managed whenever the board vendor, Qt version, or Yocto release changes.
Boot to Qt can be useful when a team wants to evaluate Qt on supported hardware quickly, integrate with Qt Creator, or demonstrate a device UI before the full production Linux platform is settled. It should not replace architecture review. Teams still need to understand kernel support, display configuration, update strategy, licensing terms, storage layout, security policy, and whether the reference image matches the product’s long-term maintenance model.
A distribution-based image can work for gateways, development tools, or devices with PC-like hardware and larger storage. It is less attractive for tightly controlled appliances because package drift and unnecessary services can increase attack surface and make field support harder. The decision is less about ideology and more about who owns the image over the product lifetime.
Maintenance realities in 2026
Version planning is now a first-order design concern for Qt embedded Linux projects. As of early September 2026, The Qt Company’s release blog lists Qt 6.11.2, published on August 18, 2026, as a patch release with bug fixes, security improvements, and quality enhancements on top of Qt 6.11.1. That does not automatically make it the correct version for every product. Teams shipping long-life hardware often prefer a supported LTS branch, a vendor-qualified Qt build, or a version already integrated into the board support package.
Yocto planning has similar implications. The Yocto Project release table in 2026 lists Wrynose 6.0 as an LTS series originally released in April 2026 and supported until April 2030, while Scarthgap 5.0 remains an LTS series supported until April 2028. The same table shows Kirkstone 4.0 as end of life after its April 2026 update. For a new product started in late 2026, basing the image on an EOL Yocto series would need a strong vendor-support reason, because upstream maintenance expectations are different from those of an active LTS branch.
The most common maintenance mistake is choosing Qt, Yocto, the kernel, and GPU libraries independently. In embedded systems, they are connected. A Qt upgrade can expose driver bugs. A Yocto migration can change compiler behavior, Mesa versions, EGL integration, Python tooling, or systemd defaults. A vendor kernel may lag behind upstream security fixes but still contain board-specific display patches. A stable product strategy therefore starts with a compatibility matrix covering board revision, BSP version, kernel branch, Yocto series, Qt version, GPU userspace driver, compositor if used, and update mechanism.
Security should also be defined before field deployment. Qt applications may use networking, WebEngine or WebView components, Bluetooth, USB storage, update clients, or local IPC. Each added module has maintenance implications. A minimal Qt image is not automatically secure. A well-scoped image with known packages, a read-only root file system where appropriate, signed updates, and a tested rollback path is easier to support than an uncontrolled general-purpose image.
Runtime design checks before committing
Before locking the architecture, the team should test the actual target display, touch controller, GPU driver, and boot flow. Desktop simulation is useful for UI iteration, but it cannot prove that the final stack will handle display timing, suspend and resume, input calibration, rotated panels, GPU memory pressure, or unexpected power loss.
- Display path: Confirm whether the board supports DRM/KMS, EGL, OpenGL ES, Vulkan, framebuffer output, or a vendor-specific graphics stack.
- Windowing model: Decide whether the product is one full-screen application or a multi-process graphical system that benefits from Wayland.
- Input: Validate touch mapping, multi-touch behavior, keyboard or encoder input, hotplug behavior, and factory calibration workflows.
- Fonts and localization: Ensure the image contains the required fonts, fallback fonts, fontconfig behavior, and language assets. Qt documentation notes that modern Qt does not ship fonts in the embedded lib/fonts directory, so the platform image must provide them.
- Memory and graphics budget: Test full-resolution scenes, animations, video playback, and worst-case screens on the real panel. Qt documentation recommends extra care with fixed dedicated video memory and notes that high-resolution Qt Quick or OpenGL-based applications may need sufficient GPU memory.
- Startup: Measure time from power-on to usable UI, not only application launch time after Linux is already running.
- Failure handling: Define what happens if the UI process crashes, the compositor fails, settings are corrupted, or an update is interrupted.
These checks are not optional polish. They determine whether the UI behaves like integrated device firmware or like a fragile desktop program forced into an appliance. A robust Qt embedded Linux product normally includes service supervision, deterministic logging, a crash collection strategy, and a safe mode or recovery path for field technicians.
A practical decision matrix
For a single-screen industrial controller with one main application, EGLFS with a Yocto-built image is often a clean baseline. It keeps the stack small and avoids a compositor if no other graphical processes are required. The main validation points are GPU driver stability, display configuration, input mapping, and the application’s ability to own the entire screen.
For a device with multiple applications, vendor UI modules, overlays, or future extensibility requirements, Wayland deserves serious consideration. It introduces more moving parts, but it can create cleaner boundaries between the compositor, system UI, and application processes. This is especially useful when teams need process isolation or want to restart an application without taking down the entire graphical session.
For a cost-sensitive device with a simple status screen, LinuxFB may be enough. The risk is future scope creep. If product management later adds animated dashboards, maps, video, or high-DPI themes, the original lightweight path may become a constraint. Choosing LinuxFB is safest when the UI requirement is stable and performance targets are modest.
For rapid prototypes, Boot to Qt or a vendor image can accelerate learning. For production, the team should still converge on a controlled image strategy, documented build inputs, reproducible SDKs, and a maintenance branch plan. The earlier that transition happens, the less rework appears during certification, factory testing, and pilot deployment.
Frequently asked questions
Is Qt embedded Linux only for high-end hardware?
No. Qt can run on a range of embedded Linux devices, but the right UI technology and platform plugin depend on CPU, GPU, memory, display resolution, and animation requirements. A simple Widgets or QML interface has very different resource needs from a 3D, video-heavy, high-resolution HMI.
Should a new Qt embedded Linux project use Qt 6?
For a new design, Qt 6 is usually the natural starting point because current Qt development, tooling, and meta-qt6 workflows are centered there. However, the final choice should be aligned with the board vendor’s BSP, required Qt modules, licensing model, and support window. Existing Qt 5 products may need a staged migration rather than an immediate rewrite.
Is Wayland always better than EGLFS?
No. Wayland is better when the product needs a compositor, multiple graphical clients, or stronger separation between UI processes. EGLFS can be simpler and more direct for a single full-screen application. The wrong choice is the one made without testing the actual display stack and future product requirements.
Can Yocto be avoided?
Yes, especially for prototypes, low-volume devices, or PC-like hardware. But for controlled production images, Yocto gives teams stronger control over packages, versions, build reproducibility, SDK generation, and long-term maintenance. Avoiding Yocto shifts those responsibilities elsewhere; it does not remove them.
What is the most important early test?
Run the real application, or a realistic UI load, on the final display path as early as possible. Measure boot time, touch behavior, rendering smoothness, GPU memory use, crash recovery, and update behavior on the target board. That test reveals more architectural risk than a desktop demo or a screenshot review.
