Laszlo Agocs

Embedded Linux news in Qt 5.6

Published Tuesday November 17th, 2015
7 Comments on Embedded Linux news in Qt 5.6
Posted in Dev Loop, Embedded, Graphics, News, OpenGL, QPA, Qt, Wayland

With Qt 5.6 approaching, it is time to look at some of the new exciting features for systems running an Embedded Linux variant, just like we did for Qt 5.5 a while ago.

Support for NVIDIA Jetson Pro boards

Boards like the Jetson TK1 Pro running a Yocto-generated Vibrante Linux image have support for X11, Wayland, and even running with plain EGL without a full windowing system. The latter is accomplished by doing modesetting via the well-known DRM/KMS path and combining it with the EGL device extensions. This is different than what the eglfs platform plugin’s existing KMS backend, relying on GBM, offers. Therefore Qt 5.5 is not functional in this environment. For more information on the details, check out this presentation.

Wayland presents a similar challenge: while Weston works fine due to having been patched by NVIDIA, Qt-based compositors built with the Qt Compositor framework cannot function out of the box since the compositor has to use the EGLStream APIs instead of Mesa’s traditional EGLImage-based path.

With Qt 5.6 this is all going to change. With the introduction of a new eglfs backed based on EGLDevice + EGLOutput + EGLStream, Qt applications will just work, similarly to other embedded boards:

eglfs on the Jetson K1 Pro

The well-known Qt Cinematic Experience demo running with Qt 5.6 and eglfs on a Jetson K1 Pro

Cross-compilation is facilitated by the new device makespec linux-jetson-tk1-pro-g++.

Wayland is going to be fully functional too, thanks to the patches that add support for EGL_KHR_stream, EGL_KHR_stream_cross_process_fd, and EGL_KHR_stream_consumer_gltexture in the existing wayland-egl backend of Qt Compositor.

Wayland on the Jetson with Qt

The qwindow-compositor example running on the Jetson with some Qt clients

All this is not the end of the story. There is room for future improvements, for example when it comes to supporting multiple outputs and direct rendering (i.e. skipping GL-based compositing and connecting the stream directly to an output layer à la eglfs to improve performance). These will be covered in future Qt releases.

Note that Wayland support on the Jetson should be treated as a technical preview for the time being. Compositors using the unofficial C++ APIs, like the qwindow-compositor example shown above, will work fine. However, QML and Qt Quick support is still work in progress at the time of writing.

Support for Intel NUC

Some of the Intel NUC devices make an excellent embedded platform too, thanks to the meta-intel and the included meta-nuc layers for Yocto. While these are ordinary x86-64 targets, they can be treated and used like ARM-based boards. When configuring Qt for cross-compilation, use the new linux-nuc-g++ device spec. Graphics-wise everything is expected to work like on an Intel GPU-based desktop system running Mesa. This includes both eglfs (using the DRM/KMS/GBM backend introduced in Qt 5.5) and Wayland.

Wayland on boards based on the i.MX6

Systems based on Freescale’s i.MX6 processors include a Vivante GC2000 GPU and driver support for Wayland. Qt applications have traditionally been working fine on the Weston reference compositor, see for example this previous post for Qt 5.4, but getting Qt-based compositors up and running is somewhat tricky due to some driver specifics that do not play well with QPA and eglfs. With Qt 5.6 this issue is eliminated as well: in addition to the regular Vivante-specific backend (eglfs_viv), eglfs now has an additional backend (eglfs_viv_wl) which transparently ensures proper functionality when running compositor applications built with the Qt Compositor framework. This backend will need to be requested explicitly, so for example to run the qwindow-compositor example, do QT_QPA_EGLFS_INTEGRATION=eglfs_viv_wl ./qwindow-compositor -platform eglfs (the -platform can likely be omitted since eglfs is typically the default).

OpenGL ES 3.0 and 3.1

As presented earlier, OpenGL ES 3 support is greatly enhanced in Qt 5.6. Using the new QOpenGLExtraFunctions class applications targeting embedded devices with GLES 3 capable drivers can now take the full API into use in a cross-platform manner.

libinput

Qt 5.5 introduced support for libinput when it comes to getting input events from keyboards, mice, touchpads, and touchscreens. Qt 5.6 takes this one step further: when libinput is available at build time, it will be set as the default choice in eglfs and linuxfb, replacing Qt’s own evdevkeyboard, mouse, and touch backends.

In some rare cases this will not be desirable (for example when using evdevkeyboard-specific keyboard layouts from the Qt 4 QWS times), and therefore the QT_QPA_EGLFS_NO_LIBINPUT environment variable is provided as a means to disable this and force the pre-5.6 behavior.

That’s it for now. Hope you will find the new Embedded Linux features useful. Happy hacking!

P.S. the Qt World Summit 2015 had a number of exciting talks regarding embedded development, for example Qt for Device Creation, Choosing the right Embedded Linux platform for your next project and many more. Browse the full session list here.

Do you like this? Share it
Print this pageEmail this to someoneShare on LinkedInShare on Google+Share on FacebookTweet about this on Twitter

Posted in Dev Loop, Embedded, Graphics, News, OpenGL, QPA, Qt, Wayland

7 comments

suvir says:

Is there any more details about “linux-nuc-g++ “. Its not really clear when you say can be treated and used like ARM-based boards. Why would you cross compile for a x86_64 based platform. Is it that the graphics libraries differ on nuc devices with the traditional desktop. Or there are much more difference among the two.

Laszlo Agocs Laszlo Agocs says:

If you are not interested in cross-compiling, then don’t do it – just like on the more powerful ARM boards, you can build everything directly on the NUC, if you wish.

However, in some cases you will not start from scratch but have some existing solution targeting an ARM-based board. Targeting an Intel based board in addition is then a matter of switching to the correct device-specific flags.

Take the Yocto-based reference image collection shipped with the Qt for Device Creation package for example: we can now easily add an image for the NUC built via Yocto. One can then simply flash the right image, with deploying and running Qt apps being no different with the NUC than any of the other devices.

When it comes to graphics, it’s Mesa, no different from the usual desktop setups.

suvir says:

Thanks for the reply.

Pau Garcia i Quiles says:

What about supporting Bay Trail and Cherry Trail devices?

There are a lot of mini PCs and tablets with Z3735 and Z8300 CPUs coming to the market, at a very low price (< 100 EUR), and some of them (e. g. Egreat i6) with a LTS plan.

Laszlo Agocs Laszlo Agocs says:

As long as there is a system image that uses Mesa, those will work as well. Qt’s own NUC device spec does not contain anything really device-specific atm.

Hyy says:

Good news. But why don’t you support Samsung or MTK or Qualcomm CPUs as official reference? Most people use their solutions in practice.

Laszlo Agocs says:

Some of these are well-supported, f.ex. ODROID-XU3 (Samsung Exynos with ARM Mali) support has been introduced in 5.5.

In general there is less focus on mobile phone/tablet oriented chips as these typically target Android with Linux being only a secondary citizen and are less interesting to the majority of Qt users working on (typically non-mobile focused) device creation.

Commenting closed.

Get started today with Qt Download now