Qt on Embedded LinuxQtCS2015

Laszlo is having a session on Qt on Embedded.

We will not be discussing QtWayland in this session.

Laszlo introduces himself.

What have we been working on lately?

LinuxFB is a done deal. Widgets working on top of it. We don't expect it to change any in the future.

EGLFS is the thing to use when you need OpenGLES2. In Qt5.5 we'r modularizing all the backends. The backends are plugins. This allows you to have a better build setup, and you will build the backends based on what is available on configure time.

EGLFS also has KMS support now. Laszlo suggests that the KMS plugin should not be used anymore and, EGLFS is the way forward.

Inputhandling: In Qt 5.0 we had plugins for reading inputs directly from the evdev interfaces. In Qt 5.5 we now have a plugin which uses the libinput. This is the library that is being used by weston and new xservers.

The evdev plugins are the default input handler, and it hasn't been really consider if the default input handler should change.

GStreamer support 1.0 is supported in QtMultimedia. This allows you do get HW accelerated video on the RPI. GStreamer v.1.0 support is a configure switch (instead of using GStreamer 0.10.

Building Environment

Buildroot an Yocto have recipes for building Qt. There is some work to simplify how to build Qt in a Yocto environment. There is a demand to build Qt as it is supported by the "Qt/Embedded" setup. There is also an additional Yocto layer which will add VirtualKeyboard and other Boot2Qt addon.

Properly configured Qt, means that you get a EGLFS which is configured for the device your running on. There can also be other switches which can be added as configure flags.

Are anyone in The Qt Company working on supporting BuildRoot. BuildRoot is apparently slightly behind Yocto.

What about QA for the Yocto layers. Can we integrate the Yocto layer into the CI, so that we know early when stuff breaks.

We should not make the Yocto layers a source for release blockers. Laszlo and Eirik is not too worry about this.

If Yocto builds are in the CI, can we then run autotests on devices? There is some work being done on this.

At the moment Qt in CI is not built using Yocto. "We" hope Qt is built in a similar way in Yocto...

Yocto Yocto Yocto... Release scheduling.

A few words on 5.6

EGLFS not too many plans. On Mobile on Embedded GLES3.1 support is coming to devices. Support for the new subset of functions for GLES3.1 will be supported in a QGLFunctions "subclass or something" in 5.6.

What about SW rendering?

QtQuick2d renderer is commercial only.

OpenVG?

There is a need for OpenVG? Maybe we can use the same approach with the QtQuick2d renderer and use OpenVG as a blitter.

What do we do when we have HW Blitters/Compositors?

We don't have an interface for this.

How do we make sure we have performance? How do we identify the performance.

Tukka wants a performance benchmark suite. And we need the test benchmarks to run on actual devices. Robin and Gunnar has been working on a set of "benchmark tests" for declarative. Should talk to Eskil.

It would be nice if the benchmark tests where easily accessible for developers so they can run it on their own devices.

How are reference boards picked?

Reference boards are dynamic. It will change, depending on:

1. What will generate most revenue
2. ????
3. What is available

Yocto again: Those that have used Meta-Qt5 know its awkward when using qmake because the use of environment variable. This will be fixed in the future. Ie. it's already fixed in The Boot2Qt metalayer.