Laszlo Agocs

Qt from git on the Tinkerboard (with Wayland)

Published Wednesday May 3rd, 2017
6 Comments on Qt from git on the Tinkerboard (with Wayland)
Posted in Dev Loop, Embedded, Graphics, OpenGL, QPA, Qt Quick

The Asus Tinkerboard is a nice little board for Embedded Linux (or Android, for that matter), based on the Rockchip RK3288 SoC including a quad-core ARM Cortex-A17 CPU and a Mali-T760 MP4 (T764) GPU. Besides being quite powerful, it has the advantage of being available locally in many countries, avoiding the need to import the boards from somewhere else. It has its own spin of Debian, TinkerOS, which is what we are going to use here. This is not the only available OS/distro choice, check for example the forums for other options.

We are going to set up the latest qtbase and qtdeclarative from the dev branch, and, to make things more interesting, we are going to ignore X11 and focus on running Qt applications via eglfs with the DRM/KMS backend. This is fairly new for Qt on Mali-based systems: in the past (for example, on the ODROID-XU3) we have been using the fbdev-based EGL implementation. Additionally, Wayland, including Qt-based compositors, is functional as well.

Update 07/2017: It is worth noting that generating an image and SDK via Yocto is fully possible as well, and this can also be configured to bring in support for eglfs on DRM/KMS and Wayland, if needed. See the Rockchip wiki pages for more information.


First Things First

qtbase/dev recently received a patch with a simple device spec for the Tinkerboard. Make sure this is part of the checkout of the qtbase tree you are going to build.

As usual, we are going to cross-compile. The steps are pretty similar to the Raspbian guide in the Wiki. I have been using this TinkerOS 1.8 image as the rootfs. To get a suitable ARM (32-bit) cross-compiler for x64, try this Linaro toolchain.

When it comes to the userspace graphics drivers, I have been using the latest “wayland” variant from the Firefly RK3288 section at the Mali driver page. Now, the TinkerOS image does actually come with some version/variant of the binary drivers in it so this step may or may not be necessary. In any case, to upgrade to this latest release, get malit76xr12p004rel0linux1waylandtar.gz and copy the EGL/GLES/GBM/wayland-egl libraries to /usr/lib/arm-linux-gnueabihf. Watch out to have all symlinks adjusted.

As the final preparation step, let’s disable auto-starting X: systemctl set-default

Sysroot, Configure, Build

From this point on, the steps to create a sysroot on the host machine and to build qtbase against it are almost completely the same as in the earlier Wiki guides for the RPi. Feel free to skip reading this section if it all looks familiar already.

  • Install some development headers and libraries on the target: sudo apt-get build-dep qt4-x11 libqt5gui5 wayland weston.
  • Create a sysroot on the host:
    mkdir -p ~/tinker/sysroot/usr
    rsync -e ssh avz linaro@...:/lib ~/tinker/sysroot
    rsync -e ssh avz linaro@...:/usr/include ~/tinker/sysroot/usr
    rsync -e ssh avz linaro@...:/usr/lib ~/tinker/sysroot/usr

    (NB. this is a massive overkill due to copying plenty of unnecessary stuff from /usr/lib, but will do for now)

  • Make all symlinks relative:
    cd ~/tinker
    chmod +x
    ./ sysroot
  • Configure with -device linux-tinkerboard-g++:
    ./configure -release -opengl es2 -nomake examples -nomake tests -opensource -confirm-license -v \
    -device tinkerboard -device-option CROSS_COMPILE=~/tinker/toolchain/bin/arm-linux-gnueabihf- \
    -sysroot ~/tinker/sysroot -prefix /usr/local/qt5 -extprefix ~/tinker/qt5 -hostprefix ~/tinker/qt5-host

    Adjust the paths as necessary. Here the destination on the target device will be /usr/local/qt5, the local installation will happen to ~/tinker/qt5 while the host tools (qmake, moc, etc.) go to ~/tinker/qt5-host.

  • Then do make and make install as usual.
  • Then rsync qt5 to /usr/local on the device.

Watch out for the output of configure. The expectation is something like the following, especially when it comes to EGLFS GBM:

EGL .................................... yes
    Desktop OpenGL ....................... no
    OpenGL ES 2.0 ........................ yes
    OpenGL ES 3.0 ........................ yes
Features used by QPA backends:
  evdev .................................. yes
  libinput ............................... yes
QPA backends:
  EGLFS .................................. yes
  EGLFS details:
    EGLFS GBM ............................ yes
  LinuxFB ................................ yes
  VNC .................................... yes


Build and deploy additional Qt modules as necessary. At this point QWindow, QWidget and Qt Quick (QML) applications should all be able to run on the device.

Few notes:

  • Set LD_LIBRARY_PATH, if needed. If the Qt build that comes with the system is still there in /usr/lib/arm-linux-gnueabihf, this is pretty much required.
  • When using a mouse, keyboard or touchscreen, make sure the input devices have sufficient permissions.
  • Enable logging by doing export QT_LOGGING_RULES=qt.qpa.*=true.

As proven by the logs shown on startup, applications will use the eglfs_kms backend which is good since it gives us additional configurability as described in docs. The OpenGL ES implementation seems to provide version 3.2 which is excellent as well.

One thing to note is that the performance may suffer by default due to not running at high enough frequency. So if for instance the qopenglwidget example seems to get stuck at 20 FPS after startup, check this forum thread for examples on how to change this.


Yes, QtWayland just works. Here is the minimal-qml compositor example with some clients:


One thing to note is that the default egl_platform.h leads to a build failure in qtwayland. To circumvent this, add a cast to EGLNativeWindowType in the problematic eglCreateWindowSurface call.

That’s all for now, have fun with the Tinkerboard!

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Dev Loop, Embedded, Graphics, OpenGL, QPA, Qt Quick


boulabiar says:

Good post ! I have 2 questions:
1. Would QtWebkit work with WebGL enabled without a lot of tweeking?
2. Compared to RaspberryPi 3, is the same thing possible (Wayland+Chromium/QtWebkit) ?


Laszlo Agocs Laszlo Agocs says:

Cannot comment on QtWebKit and its level of WebGL support unfortunately. When it comes to QtWebEngine, the assumption is that it should just work but AFAIK it has not yet been tested in practice on this particular SoC.

Max says:

I thinking about buying Tinkerboard just wonder: Is it 2x faster than Raspberry Pi 3 ? can you feel more speed and power ?

Laszlo Agocs Laszlo Agocs says:

Yes, although haven’t done any benchmarks or similar.

Ariel G. Moreno says:

HI Laszlo,
really very interesting post!

I would want to build the same stuff for my Firefly RK3288 board, and run the Qt OpenGL examples.
Do you think it should be possible build Qt with the platform plugin “eglfs_kms” for the Firefly? I have Ubuntu 16.04 with 4.4 Kernel.

Also, what is your opinion about pros and cons of running a Qt application using Wayland vs X11 vs Fbdev, on this Firefly board?

Thank you very much in advance!

Laszlo Agocs Laszlo Agocs says:

That’s the same SoC, so everything described here should apply there too. If you have DRM-capable drivers, go for it. A good pre-verification step is to try starting Weston – if it comes up, then eglfs via eglfs_kms should be working too.

If X11 works and you get proper OpenGL support, then there’s nothing preventing you from going with it. However, in most typical device creation projects eglfs (for simple to moderately complex systems) or Wayland (for complex systems that really need multiple gui processes) are the standard choice.

Commenting closed.

Get started today with Qt Download now