Background

I have been packaging Qt for the Raspberry Pi for some months now as documented here. The motivation behind packaging it is that the distro provided Qt versions tend to use software based OpenGL (Mesa) rather than benefiting from the hardware acceleration provided by the platform (and proprietary drivers). This resulted in abysmal performance, especially on the Raspberry Pi 1/0, and especially at relatively high resolutions like 1080p.

This stands to change (hence the blog) with the broad adoption of the opensource VC4 driver which offers hardware acceleration inside of the official reference implementation (Mesa) by way of DRM. We can suddenly harness the distro packaged Qt versions, which on Arch Linux tend to be 1-2 weeks behind official Qt releases, and get full GLES2 hardware acceleration (not the media stuff, that is still tied to the proprietary stack). The Arch provided Mesa (12 at the time of this writing) is also awfully current, which is valuable since we want the latest VC4 changes.

Process

  1. Set up Arch for your respective Pi 0,1 2,3
  2. Boot your system
  3. Set up networking (wired is trivial; wifi-menu makes wpa_supplicant idiot proof but requires dialog to be installed: pacman -S dialog (with a wired connection))
  4. Update it using: pacman -Syu
  5. pacman -S base-devel qt5 git (Required for building)

  6. Adjust your system to boot use the VC4 driver by adjusting config.txt to contain:

     avoid_warnings=2     # VPU shouldn't smash our display setup.
 dtoverlay=vc4-kms-v3d

  7. Adjust cmdline.txt by appending the following to the existing kernel command line:

     cma=256M@256M

(If anyone knows superior instructions to the above, please enlighten me in the comments; this info was accrued via bush diving in various forums and the associated trial and error)

  1. Reboot your device

  2. Qt applications can now be run with the EGLFS plugin provided at runtime. So what can we use/see in order to see the performance of Qt? I personally favour:

     https://github.com/qml-box2d/qml-box2d

which needs to be built from source. Easy enough:

    git clone https://github.com/qml-box2d/qml-box2d.git
    qmake
    make
    make install

change into ./examples in the code and you can now run all the examples:

    qmlscene -platform eglfs cannon/main.qml

As you will see, things run swimmingly at 1080p and your attached mouse/keyboard simply works by virtue of libinput. No Xorg/X11, no worries, and this is peak performance. It can’t get any better than EGLFS, so if all you need is one surface, even the move to wayland will hamper you. (There is not meant to be much overhead, but I saw a marked degradation on the Pi both against the proprietary stack and my own Qt compiled against Mesa)

Be warned, EGLFS will break if your application, like cool-retro-term need multiple surfaces. In such circumstances, we are better off using Wayland and hence the next step is logically to see how Wayland performs.

  1. Both Qt compositors and weston barf when Qt clients are run with -platform wayland

    [root@alarmpi ~]# qmlscene ~/moo.qml -platform wayland
Using Wayland-EGL
Attempting to import 506x533 b8g8r8a8_unorm with unsupported stride 2032 instead of 128
wl_drm@17: error 2: invalid name

This problem did not exist in the Qt 5.7 builds I produced against Mesa. (Although as of the Qt 5.7 final release, the proprietary wayland backend is exploding rather spectacularly. (But did not do so as of the Qt 5.7 alpha)) weston-terminal launches correctly, so the point of failure is localized to the packaged Qt. Rebuilding qtwayland does not resolve anything, and I suspect this boils down to the surface management helper functionality built into Qt.

This actually constitutes a deal breaker for me. Without wayland, we have something which is good for dedicated applications whose code base we control, but we can’t simply point hobbyists and other people who consume other peoples code (the vast majority of Linux users) at this and have them go to town doing cool stuff with Qt on the Pi. I am gonna focus on getting the QPi packages back up to spec against the proprietary drivers.

TL&DR

Flavour OpenGL ES 2 EGLFS Wayland QCEC*
Arch Packaged y y n n
QPi y y n y

* Require’s Dispmanx support as per libcec