Using Qt on the Tinkerboard


I delayed getting a Tinkerboard until the base software stack was documented to be at a sufficiently functional state. This announcement never actually came, and rather than squandering time trying to get Arch working on this Rockchip based device, I caved and started using the TinkerOS image provided by ASUS.

Cross compiling Qt for the Tinkerboard is not novel, it largely involves setting up the base OS image so that your cross compiler can access it as a functional sysroot without falling over. After getting Qt working from first principles, I discovered that Laszlo Agocs has already provided an authoritative documentation on getting Qt functional on the Tinkberboard. This document hopes to flesh in gaps left in this original document.


The goal is to get Qt running well on the Tinkerboard, and to establish whether 4K rendering was readily plausible.

Conditioning the image

I like to cross compile for targets against an NFS mounted sysroot. This is greatly complicated by Debian’s multiarch bollocks that is front and center in TinkerOS. I am building using an Arch Linux host, and rather than being able to use a standard armv7 toolchain to target TinkerOS, I eventually had to cave in and download a Linaro toolchain. (After failure to link crt[1/0].o and friends for a couple hours)

  • use the symlinks tool to make all symlinks under [/usr/lib,/lib] absolute and not relative (prevent mistaken dereferencing of host libraries
  • use the latest Linaro armv7 toolchain
  • Install the build deps for Qt on TinkerOS
  • Install NFS server components if you want to develop against your rootfs mounted via NFS

Qt tailoring

Since I was unaware of Laszlo’s prior documentation, I started to customize a mkspec for the Tinkerboard from another Mali bearing muppet in the mkspec tree. After revising through this mkspec, it boiled down to this which you will note contains close to zero GPU centric tailoring, which is awesome. I settled on a slightly different set of compiler flags to Laszlo, but this is hardly grounds for scandal.

Since I already maintain SDKs for Qt use in conjunction with the Raspberry Pi, I simply added the Tinkerboard as a redheaded step child to my existing AUR recipe. It warrants mentioning that I was using Qt 5.10 (alpha/beta/beta2) so I am following the testing flow, and that I was indulging in static compilation, since this is increasingly appealing to me for “appliance” like purposes where I am running a single graphical application on a general purpose Linux box that runs a series of discrete applications that serve discrete purposes. (This involves touching static and testing if using the AUR recipe above)

One vaguely filthy thing about static compilation with Qt, is that it make installs the static libraries to the sysroot, which is braindead for a couple reasons

  • The presence of .a files on an embedded device is a war crime
  • I am using LTCG/LTO, so the static libraries are immense and cross compiling off an NFS mount would be a tedious nightmare. My solution to this (and it is filthy) is to have my NFS mounted sysroot symlink to a host directory. If you are not grimacing, you are clearly not registering the filthiness of it all.

Immediate dividends

Once the AUR recipe above had run to completion, I cross compiled my personal artwork displaying application which could immediately be launched successfully at 4K with the use of the “-platform eglfs” argument. The only issue manifested when my application crashed after apparently exhausting the default amount of memory afforded to the GPU within TinkerOS. (I set my defaults to pretty much exhausted 512 MB of GPU memory on a Raspberry Pi, which is what I normally target). After reducing the number of pixmaps to be displayed, my application was running reliably and with pretty damn solid performance.


  • Discover how to increase the amount of GPU memory on the Tinkerboard (CMA args?)
  • Blog about the impact of compiler flags on the size of the resulting binaries. I am using -Os + thumb instructions + ltcg to statically compile my (Qt Quick) application for use with the Tinkerboard. The complete static binary was ~8M before opting for LTCG/LTO, which further decreased this to 6M. I was an extremely happy camper to see a Qt Quick application punching at this size, and it provided feature parity with my old approach of shipping my application with an explicit dependency on a discrete shared Qt install which was over 100M in installed size.

The state of Qt on Arch Linux on the Raspberry Pi 3 aarch64

In Brief

The good news is you can grab the Arch aarch64 image, boot it, adjust the boot args by tagging on “cma=512M@256M” and then qpi will successfully be able to launch Open GL ES2 applications. (The stock Qt packaged for Arch sprays shit everywhere to the point where I dont even want to debug it).

The bad news is that applications which load a lot of graphical resources will barf pretty quickly as vc4 runs out of memory.

Sep 10 23:15:12 boombox kernel: [drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR* [CRTC:66:crtc-2] flip_done timed out
Sep 10 23:15:01 boombox kernel: alloc_contig_range: [18f00, 19f00) PFNs busy
Sep 10 23:14:55 boombox kernel: alloc_contig_range: [10120, 10121) PFNs busy
Sep 10 23:14:55 boombox kernel: alloc_contig_range: [1011d, 1011e) PFNs busy
Sep 10 23:14:55 boombox kernel: alloc_contig_range: [10120, 10121) PFNs busy
Sep 10 23:14:55 boombox kernel: alloc_contig_range: [1011d, 1011e) PFNs busy
Sep 10 23:14:55 boombox kernel: alloc_contig_range: [1011d, 1011e) PFNs busy
Sep 10 23:14:55 boombox kernel: alloc_contig_range: [1011d, 1011e) PFNs busy
Sep 10 23:14:55 boombox kernel: alloc_contig_range: 4 callbacks suppressed
Sep 10 23:14:40 boombox kernel: alloc_contig_range: [10120, 10121) PFNs busy
Sep 10 23:14:40 boombox kernel: alloc_contig_range: [1011d, 1011e) PFNs busy
Sep 10 23:14:40 boombox kernel: alloc_contig_range: [10120, 10121) PFNs busy
Sep 10 23:14:40 boombox kernel: alloc_contig_range: [1011d, 1011e) PFNs busy
Sep 10 23:14:40 boombox kernel: alloc_contig_range: [10120, 10121) PFNs busy
Sep 10 23:14:40 boombox kernel: alloc_contig_range: [1011d, 1011e) PFNs busy
Sep 10 23:14:40 boombox kernel: alloc_contig_range: [10120, 10121) PFNs busy
Sep 10 23:14:40 boombox kernel: alloc_contig_range: [1011d, 1011e) PFNs busy
Sep 10 23:14:40 boombox kernel: alloc_contig_range: [10120, 10121) PFNs busy
Sep 10 23:14:40 boombox kernel: alloc_contig_range: [1011d, 1011e) PFNs busy
Sep 10 23:14:40 boombox kernel: alloc_contig_range: 102 callbacks suppressed
Sep 10 23:14:34 boombox kernel: alloc_contig_range: [10120, 10121) PFNs busy
Sep 10 23:14:34 boombox kernel: alloc_contig_range: [1011d, 1011e) PFNs busy
Sep 10 23:14:34 boombox kernel: alloc_contig_range: [10120, 10121) PFNs busy
Sep 10 23:14:34 boombox kernel: alloc_contig_range: [1011d, 1011e) PFNs busy
Sep 10 23:14:34 boombox kernel: alloc_contig_range: [10120, 10121) PFNs busy
Sep 10 23:14:34 boombox kernel: alloc_contig_range: [1011d, 1011e) PFNs busy
Sep 10 23:14:34 boombox kernel: alloc_contig_range: [10120, 10121) PFNs busy
Sep 10 23:14:34 boombox kernel: alloc_contig_range: [1011d, 1011e) PFNs busy
Sep 10 23:14:34 boombox kernel: alloc_contig_range: [10120, 10121) PFNs busy
Sep 10 23:14:34 boombox kernel: alloc_contig_range: [1011d, 1011e) PFNs busy
Sep 10 23:14:32 boombox kernel: alloc_contig_range: [1011d, 1011e) PFNs busy
Sep 10 23:14:28 boombox kernel: alloc_contig_range: [10180, 10183) PFNs busy
Sep 10 23:14:28 boombox kernel: alloc_contig_range: [1017c, 1017f) PFNs busy
Sep 10 23:14:15 boombox kernel: alloc_contig_range: [1017c, 1017f) PFNs busy
Sep 10 23:13:57 boombox kernel: alloc_contig_range: [10181, 10182) PFNs busy
Sep 10 23:13:57 boombox kernel: alloc_contig_range: [10180, 10181) PFNs busy
Sep 10 23:13:57 boombox kernel: alloc_contig_range: [1017f, 10180) PFNs busy
Sep 10 23:13:55 boombox kernel: alloc_contig_range: [10181, 10182) PFNs busy
Sep 10 23:13:55 boombox kernel: alloc_contig_range: [10180, 10181) PFNs busy
Sep 10 23:13:55 boombox kernel: alloc_contig_range: [14800, 14b6a) PFNs busy
Sep 10 23:13:55 boombox kernel: alloc_contig_range: [14600, 14a6a) PFNs busy
Sep 10 23:13:55 boombox kernel: alloc_contig_range: [14600, 1496a) PFNs busy
Sep 10 23:13:54 boombox kernel: alloc_contig_range: [10181, 10182) PFNs busy
Sep 10 23:13:54 boombox kernel: alloc_contig_range: [10180, 10181) PFNs busy
Sep 10 23:13:54 boombox kernel: alloc_contig_range: 21 callbacks suppressed
Sep 10 23:12:06 boombox kernel: alloc_contig_range: [1017a, 1017b) PFNs busy
Sep 10 23:12:06 boombox kernel: alloc_contig_range: [10178, 10179) PFNs busy
Sep 10 23:12:06 boombox kernel: alloc_contig_range: [1017a, 1017b) PFNs busy

with this earlier in the stack preceding the volley of alloc_contig_range barfs by a minute.

Sep 10 22:49:09 boombox kernel: [drm:vc4_get_tiling_ioctl [vc4]] ERROR Failed to look up GEM BO 0

The next thing for me to do is attempt vc4 usage against the armv7 image and establish whether this is isolated to the aarch64 one or not.

Interesting bits

I hit this for the first time:

which warrants reading, along with all its ancillary links. It is a hoot; I am damn lucky Laszlo pulled my ass from the flames or I would have sunk more time into trying to make sense of a shit situation. The TL&DR is: “Qt <5.10 falls through the branches on surface allocation with GBM/KMS on platforms like Arch which have defaulted to compiling mesa with glvnd support. Export magic env var: EGL_PLATFORM=0x31D7 and you are fucking golden.”

Once I can run my art application without it falling over after 10 minutes due to failing memory allocations, I can start to recommend aarch64 bit usage to people.

Getting the Raspberry Pi 2/3 working as an audio/AirPlay/Pulse sink (using Arch)


The only thing worse than solving oddly trivial problems in Linux land is solving the same frigging problem multiple times. That is why this document exists. Also, the defaults of Arch on the Pi (possibly elsewhere) seem pretty nadiric.


Onboard audio: disabled and suboptimal by default

Arch wiki: audio disabled in device tree

The onboard audio device tree is disabled by default. Fucking awesome, and not something which comes up if you google blindly. Gotta be reading that wiki. Add:


to config.txt

Use the new fucking code path



to config.txt.

By the author:

“Available with rpi-update firmware is an experimental audio driver that should significantly increase the quality of sound produced by the 3.5mm audio jack.

I’ve reimplemented the original PWM-based 11-bit audio @48kHz as 7-bit 2nd-order Sigma-Delta modulated at 781.25kHz. The effective noise floor with this scheme approximates that of CD-quality audio DACs.”

Dude appears to know his shit as the link above indicates.



Status: Just Works (TM)

  • pacman -S shairport-sync
  • systemctl enable shairport-sync.service

Requires: Avahi

Pulseaudio sink

Status: Kinda Just Works (TM)

You can really chase you tail with Pulse. I have had it working as a sink in the past, but hit major buffering issues. Tonight I attempted to hoist a grender-resurrect (including install base-devel and attemping to build locally on a Pi, which is a cardinal sin but the kind of compromise one has to make when people show their autotools to you in 2017. I digress.) UPNP sink. Long story short, it was a ballache and went nowhere. So I attempted pulseaudio again using this blog and a little experimentation

The sequence of steps required to make this jive on Arch on the Pi is:

  • pacman -S pulseaudio-zeroconf pulseaudio-alsa
  • useradd pulse -G audio
  • /etc/pulse/ (clearly adjust for your own subnet)
    • load-module module-native-protocol-tcp auth-ip-acl=;
    • load-module module-zeroconf-publish
  • pulseaudio –system
  • watch out for the volume; I am using hifiberry-dacplus (w/SainSmart HIFI DAC Audio Sound Card) and analog playback boost nearly blew myself and every poor fucker out of my apartment block at 2am local time

Then on the host

  • pop open paprefs
  • Make discoverable PulseAudio network sound devices available locally

Then it all just bloody works. Great, now you need it daemonized. Just as well this turkey has this blogged to a t, like a boss.

Requires: Avahi, pulseaudio, systemd (This is why Poettering is my man crush along with the king penguin pimp(daddy?) himself)

Using Qt Creator inside of a hardware accelerated Virtualbox image


I recently had the joy of being handed a Mac laptop running QtCreator inside of a VM in order to demonstrate my 1337 QML skills. The VM was dog slow, and it was not hard to see why; GPU hardware acceleration was disabled. being a rocket scientist, one immediately enables video acceleration and is promptly rewarded with (a) black window(s) where Qt Creator’s aspecto is meant to present itself. Awesome.


Luckily there is a solution:

export QMLSCENE_DEVICE=softwarecontext

prior to running Qt Creator in your VM, and you are cooking with gas. (as documented here)

If it seems counter intuitive to you to enable hardware acceleration only to use software rasterization in the sole application you are running, then you are suffering from a sever case of over rationality. I suggest a beer and maybe ratifying it.

Using the AMD DC/DAL/WTFBBQ code on Arch, today


I don’t know of a single centralized source of information on how to consume the current AMD DAL/DC kernel module in the wild today; I might as well document this for myself and any other peanuts who want to jump on this train.


  • Grab current kernel code
  • Grab AMD upstream repo
  • Checkout specific files
  • Build
  • Profit

The Nitty Gritty

  • git clone git://
  • git remote add alex git://
  • git fetch alex
  • The kernel moves quickly, but dumping the source code into the right location is working for me, so what I would advocate. For 4.13, amd-staging-drm-next is the branch we want to be rummaging in. If you feel less like putting out fires, you might want to simply build one of Alex’s other existing branches
  • The full list of touched files. This resolves down to 3 paths
    • drivers/gpu/drm
    • include/drm
    • include/uapi/drm/amdgpu_drm.h
  • which can be:
    • deleted
    • then checked out of their WIP branch with: git checkout alex/amd-staging-drm-next drivers/gpu/drm (for each path)
    • then added
    • which leads to me birthing this script
  • You will notice I am checking out the whole gpu/drm path. This means I am grabbing all changes for all gpus from the AMD devs, which may or may not be a bright idea as I assume they have to fix shit when they introduce API breakage. Descending one more level to amdgpu did not suffice to resolve build issues, so apply a little common sense and prudence before advertising the fruits of your labour as something edible, especially for a non-AMD audience.

Groovy, that is it; Enable DC in $(make menuconfig), build your kernel and away you go. Freesync may or may not be enabled on my rig, at least it is theoretically possible to get it functioning.


You can bypass this crud, assume full responsibility and choke on the linux-spudd package in:

    SigLevel = Optional
    Server =$arch

Clearly I assume no responsibility for any negative impact running a pre-release kernel with a pre-release driver does to anyone in your family. Go with god; you are on your own.


drivers/gpu/drm/Kconfig drivers/gpu/drm/Makefile drivers/gpu/drm/amd/amdgpu/Makefile drivers/gpu/drm/amd/amdgpu/amdgpu.h drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c drivers/gpu/drm/amd/amdgpu/amdgpu_device.c drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c drivers/gpu/drm/amd/amdgpu/amdgpu_job.c drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h drivers/gpu/drm/amd/amdgpu/amdgpu_object.c drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h drivers/gpu/drm/amd/amdgpu/cik.c drivers/gpu/drm/amd/amdgpu/dce_v6_0.c drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.h drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c drivers/gpu/drm/amd/amdgpu/nbio_v7_0.c drivers/gpu/drm/amd/amdgpu/nbio_v7_0.h drivers/gpu/drm/amd/amdgpu/psp_v10_0.c drivers/gpu/drm/amd/amdgpu/psp_v10_0.h drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c drivers/gpu/drm/amd/amdgpu/si.c drivers/gpu/drm/amd/amdgpu/soc15.c drivers/gpu/drm/amd/amdgpu/soc15.h drivers/gpu/drm/amd/amdgpu/soc15d.h drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c drivers/gpu/drm/amd/amdgpu/vce_v4_0.c drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c drivers/gpu/drm/amd/amdgpu/vcn_v1_0.h drivers/gpu/drm/amd/amdgpu/vega10_ih.c drivers/gpu/drm/amd/amdgpu/vi.c drivers/gpu/drm/amd/amdgpu/vid.h drivers/gpu/drm/amd/include/amd_shared.h drivers/gpu/drm/amd/include/asic_reg/dce/dce_6_0_sh_mask.h drivers/gpu/drm/amd/include/asic_reg/raven1/DCN/dcn_1_0_default.h drivers/gpu/drm/amd/include/asic_reg/raven1/DCN/dcn_1_0_offset.h drivers/gpu/drm/amd/include/asic_reg/raven1/DCN/dcn_1_0_sh_mask.h drivers/gpu/drm/amd/include/asic_reg/raven1/GC/gc_9_1_default.h drivers/gpu/drm/amd/include/asic_reg/raven1/GC/gc_9_1_offset.h drivers/gpu/drm/amd/include/asic_reg/raven1/GC/gc_9_1_sh_mask.h drivers/gpu/drm/amd/include/asic_reg/raven1/MMHUB/mmhub_9_1_default.h drivers/gpu/drm/amd/include/asic_reg/raven1/MMHUB/mmhub_9_1_offset.h drivers/gpu/drm/amd/include/asic_reg/raven1/MMHUB/mmhub_9_1_sh_mask.h drivers/gpu/drm/amd/include/asic_reg/raven1/MP/mp_10_0_default.h drivers/gpu/drm/amd/include/asic_reg/raven1/MP/mp_10_0_offset.h drivers/gpu/drm/amd/include/asic_reg/raven1/MP/mp_10_0_sh_mask.h drivers/gpu/drm/amd/include/asic_reg/raven1/NBIO/nbio_7_0_default.h drivers/gpu/drm/amd/include/asic_reg/raven1/NBIO/nbio_7_0_offset.h drivers/gpu/drm/amd/include/asic_reg/raven1/NBIO/nbio_7_0_sh_mask.h drivers/gpu/drm/amd/include/asic_reg/raven1/SDMA0/sdma0_4_1_default.h drivers/gpu/drm/amd/include/asic_reg/raven1/SDMA0/sdma0_4_1_offset.h drivers/gpu/drm/amd/include/asic_reg/raven1/SDMA0/sdma0_4_1_sh_mask.h drivers/gpu/drm/amd/include/asic_reg/raven1/THM/thm_10_0_default.h drivers/gpu/drm/amd/include/asic_reg/raven1/THM/thm_10_0_offset.h drivers/gpu/drm/amd/include/asic_reg/raven1/THM/thm_10_0_sh_mask.h drivers/gpu/drm/amd/include/asic_reg/raven1/VCN/vcn_1_0_default.h drivers/gpu/drm/amd/include/asic_reg/raven1/VCN/vcn_1_0_offset.h drivers/gpu/drm/amd/include/asic_reg/raven1/VCN/vcn_1_0_sh_mask.h drivers/gpu/drm/amd/include/ivsrcid/irqsrcs_dcn_1_0.h drivers/gpu/drm/amd/include/pptable.h drivers/gpu/drm/amd/powerplay/eventmgr/eventmgr.c drivers/gpu/drm/amd/powerplay/hwmgr/Makefile drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c drivers/gpu/drm/amd/powerplay/hwmgr/pp_overdriver.c drivers/gpu/drm/amd/powerplay/hwmgr/pp_overdriver.h drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.h drivers/gpu/drm/amd/powerplay/hwmgr/rv_inc.h drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h drivers/gpu/drm/amd/powerplay/hwmgr/vega10_pptable.h drivers/gpu/drm/amd/powerplay/hwmgr/vega10_processpptables.c drivers/gpu/drm/amd/powerplay/hwmgr/vega10_thermal.c drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h drivers/gpu/drm/amd/powerplay/inc/hwmgr.h drivers/gpu/drm/amd/powerplay/inc/rv_ppsmc.h drivers/gpu/drm/amd/powerplay/inc/smu10.h drivers/gpu/drm/amd/powerplay/inc/smu10_driver_if.h drivers/gpu/drm/amd/powerplay/inc/smu9_driver_if.h drivers/gpu/drm/amd/powerplay/inc/smumgr.h drivers/gpu/drm/amd/powerplay/smumgr/Makefile drivers/gpu/drm/amd/powerplay/smumgr/rv_smumgr.c drivers/gpu/drm/amd/powerplay/smumgr/rv_smumgr.h drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c drivers/gpu/drm/amd/scheduler/gpu_scheduler.c drivers/gpu/drm/amd/scheduler/gpu_scheduler.h drivers/gpu/drm/arm/hdlcd_crtc.c drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c drivers/gpu/drm/bridge/sii902x.c drivers/gpu/drm/bridge/synopsys/dw-hdmi.c drivers/gpu/drm/drm_atomic.c drivers/gpu/drm/drm_atomic_helper.c drivers/gpu/drm/drm_color_mgmt.c drivers/gpu/drm/drm_connector.c drivers/gpu/drm/drm_dp_mst_topology.c drivers/gpu/drm/drm_fb_cma_helper.c drivers/gpu/drm/drm_file.c drivers/gpu/drm/drm_irq.c drivers/gpu/drm/drm_plane.c drivers/gpu/drm/drm_plane_helper.c drivers/gpu/drm/drm_prime.c drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c drivers/gpu/drm/gma500/mdfld_tpo_vid.c drivers/gpu/drm/gma500/psb_intel_lvds.c drivers/gpu/drm/i915/gvt/handlers.c drivers/gpu/drm/i915/gvt/render.c drivers/gpu/drm/i915/gvt/sched_policy.c drivers/gpu/drm/i915/i915_gem_gtt.c drivers/gpu/drm/i915/i915_irq.c drivers/gpu/drm/i915/i915_reg.h drivers/gpu/drm/i915/intel_cdclk.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_dp_mst.c drivers/gpu/drm/i915/intel_drv.h drivers/gpu/drm/i915/intel_dsi.c drivers/gpu/drm/i915/intel_hdmi.c drivers/gpu/drm/i915/intel_lpe_audio.c drivers/gpu/drm/i915/intel_sdvo.c drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c drivers/gpu/drm/nouveau/nouveau_display.c drivers/gpu/drm/nouveau/nouveau_display.h drivers/gpu/drm/nouveau/nouveau_drm.c drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c drivers/gpu/drm/nouveau/nvkm/subdev/secboot/ls_ucode_gr.c drivers/gpu/drm/pl111/Kconfig drivers/gpu/drm/pl111/Makefile drivers/gpu/drm/pl111/pl111_connector.c drivers/gpu/drm/pl111/pl111_display.c drivers/gpu/drm/pl111/pl111_drm.h drivers/gpu/drm/pl111/pl111_drv.c drivers/gpu/drm/qxl/qxl_display.c drivers/gpu/drm/radeon/evergreen.c drivers/gpu/drm/radeon/radeon.h drivers/gpu/drm/radeon/radeon_drv.c drivers/gpu/drm/radeon/radeon_irq_kms.c drivers/gpu/drm/radeon/radeon_kms.c drivers/gpu/drm/radeon/radeon_mode.h drivers/gpu/drm/radeon/si.c drivers/gpu/drm/rockchip/analogix_dp-rockchip.c drivers/gpu/drm/rockchip/rockchip_drm_drv.h drivers/gpu/drm/rockchip/rockchip_drm_vop.c drivers/gpu/drm/selftests/test-drm_mm.c drivers/gpu/drm/sti/sti_cursor.c drivers/gpu/drm/sti/sti_dvo.c drivers/gpu/drm/sti/sti_gdp.c drivers/gpu/drm/sti/sti_hda.c drivers/gpu/drm/sti/sti_hdmi.c drivers/gpu/drm/sti/sti_hqvdp.c drivers/gpu/drm/sti/sti_mixer.c drivers/gpu/drm/sti/sti_tvout.c drivers/gpu/drm/sti/sti_vid.c drivers/gpu/drm/stm/Kconfig drivers/gpu/drm/stm/Makefile drivers/gpu/drm/stm/drv.c drivers/gpu/drm/stm/ltdc.c drivers/gpu/drm/stm/ltdc.h drivers/gpu/drm/tegra/drm.c drivers/gpu/drm/vc4/Makefile drivers/gpu/drm/vc4/vc4_bo.c drivers/gpu/drm/vc4/vc4_crtc.c drivers/gpu/drm/vc4/vc4_drv.c drivers/gpu/drm/vc4/vc4_drv.h drivers/gpu/drm/vc4/vc4_fence.c drivers/gpu/drm/vc4/vc4_gem.c drivers/gpu/drm/vc4/vc4_hdmi.c drivers/gpu/drm/vc4/vc4_irq.c drivers/gpu/drm/vc4/vc4_kms.c drivers/gpu/drm/vc4/vc4_render_cl.c drivers/gpu/drm/vc4/vc4_v3d.c drivers/gpu/drm/vc4/vc4_validate.c drivers/gpu/drm/vgem/vgem_drv.c drivers/gpu/drm/vgem/vgem_drv.h drivers/gpu/drm/zte/Makefile drivers/gpu/drm/zte/zx_common_regs.h drivers/gpu/drm/zte/zx_drm_drv.c drivers/gpu/drm/zte/zx_drm_drv.h drivers/gpu/drm/zte/zx_plane.c drivers/gpu/drm/zte/zx_plane_regs.h drivers/gpu/drm/zte/zx_vga.c drivers/gpu/drm/zte/zx_vga_regs.h drivers/gpu/drm/zte/zx_vou.c drivers/gpu/drm/zte/zx_vou_regs.h drivers/gpu/host1x/Kconfig include/drm/drmP.h include/drm/drm_atomic.h include/drm/drm_blend.h include/drm/drm_color_mgmt.h include/drm/drm_connector.h include/drm/drm_crtc.h include/drm/drm_dp_helper.h include/drm/drm_dp_mst_helper.h include/drm/drm_drv.h include/drm/drm_fb_cma_helper.h include/drm/drm_gem_cma_helper.h include/drm/drm_irq.h include/drm/drm_prime.h include/uapi/drm/amdgpu_drm.h

Using Qt on Arch Linux aarch64 on the Raspberry Pi 3


The Arch Linux aarch64 image used to require some fiddling to hit functionality. Now that there is an official Arch pi image for aarch64, I decided to give it a bash.


If cross compiling against this root image, be aware of fully qualified symlinks:

[root@qpi3 ~]# ls -la /lib/ lrwxrwxrwx 1 root root 32 Jan 7 03:25 /lib/ -> /usr/lib/mesa/

which will contaminate your compile with host libs and make your Qt tests barf in a hard to debug fashion. I personally use the symlinks rather than hacking together my own bash scripts.

symlinks -c /lib (turns out symlinks creates broken symlinks when passed a dir which is itself a symlink) cd /usr/lib && symlinks -cr .

and you are done.


There is not a hell of a lot to relate.

pacman -S qt

qmlscene ~/moo.qml -platform eglfs

where moo.qml is a minimal example, quick qualified that everything was functioning with any effort on my part; Qt applications work out of the box on the framebuffer with full GLES2 acceleration. I grabbed the art application I tend to use my Pi’s for, and after compilation had immediate success. That is, I had complete success for a couple minutes, at which point my app seizes heavily. I am still actively debugging this.

The default Qt plugin is still xcb, so you have to explicitly pass the eglfs platform flag as documented above. Either that or export QT_QPA_PLATFORM=eglfs in your environment to override this default.


  • Verify state of Qt wayland on this image

Utilizing a Raspberry Pi 3 at 4K UHD

Stacked art application


The Pi can run framebuffer applications at 4K and very low refresh rates. (not that the rasterized animation is exactly hampered by the refresh rate)



I saw Dom involved in a forum where people were attempting to get the Pi functional at 4K; given the man has historically been pretty bloody technically solid, it lended sufficient credibility for me to attempt following said instructions.

Pi adjustment for 4K

Basically, you adjust /boot/config.txt and book to a 4K framebuffer. Go to the link above for the original suggests from Dom and co, mine follows and are a little aggressive.


[root@boombox ~]# cat /boot/config.txt  
# See /boot/overlays/README for all available options


hdmi_cvt 3840 2160 24



Demo Application selection and adjustment

Cool, so now we have a 4K framebuffer (verified by catting /dev/urandom to > /dev/fb0), what do we show.

I have an application that I personally use on my Pis along with the Qt (5.8.0 beta) packages I maintain for Arch on the Pi (0/1/2/3).

That app is a QML app, and normally the hardware accelerated aspect of things is awesome for an animated art application, but at 4K resolutions we can no longer allocated EGL surfaces without hitting:

EGL Error : Could not create the egl surface: error = 0x300b

I even verified this with the Pi reference applications to make sure Qt was not the stumbling point.

Cool, so no EGL surfaces. A trivial qwindow example ran perfectly on the framebuffer with -platform linuxfb.

Turns out Laszlo aint full of shit and getting your sweet QML application to run on a dumb frame buffer is a mofo-ing single API call away. Snake oil capable of driving a combustion engine. (Clearly this technology does not come out of the valley)

I coded up the changes and adjusted my application to launch with linuxfb

[root@boombox ~]# cat /usr/lib/systemd/system/pi-launcher\@.service | grep platform
ExecStart=-/usr/bin/artriculate -platform linuxfb

all that remains is adjusting ~/.config/Chaos\ Reins/Articulate.conf (generated on first launch)


is set (high columnCount because we got a lot of pixels to occupy) and I was immediately up and running. (adjust for your own art/photo path)

I am stoked it worked in such a straight forwards fashion, now I just need to think about how I am gonna code up an alternative view for low frequency refreshes.

Installing Arch on the Lenovo Yoga 910

Lenovo Yoga 910


What with the Yoga 900/710 debacle, it was fairly unclear for me whether or not I would be able to change between the notorious raid controller and ahci. Turns out on the 910 this is not an issue (as reflected by one Lenovo page I happened to stub my toe on, on one of the googling sessions). This blog deals with quirks in the i915 and wifi driver which can both be time sinks.


  • This blog entry was written 14/11/2016, the mainsteam Arch kernel is now fine, you just need 1 or 2 kernel parameters (disable rc6 at a minimum) in order to function. (If at all)
  • There have been updates to the firmware which seem suspiciously pertinent. (I am looking at “disable PCIE AER for Qualcomm wireless LAN report warning message in windows event log.” in particular). I dont have Windows, so I can’t consume them, and this is not the kind of Lenovo device where they suppoort BIOS updates outside of a living Windows install. Bear that in mind.
  • Everything can be trivially made to work but the Validity fingerprint sensor.
  • Wifi requires
    • ideapad_laptop to remove the hardware block (present in 4.9 tree (Note: Not required as of 4.9!!!)), blacklisting this module in 4.8 removes the hardware block, but might carry other costs
    • Firmware from this repo which replaces the crap in /usr/lib/firmware/ath10k/QCA6174/hw3.0. (Don’t worry, this muppet is the canonical source of firmware for these cards)
  • Video requires enable_rc6=0 to avoid booting to skittish artifacts (or no modesetting, but that is way more intrusive)
  • Machine runs well and looks good. Ain’t got shit on a Carbon X1.
  • Volume out of speakers is pitiful even at max. Watching movies outside of soundproof box is impossible.

Verbose instructions

  1. Get to the EFI/bios configuration. I got there via going to recovery options in Windows and rebooting to the EFI settings panel. I could not get there via any other mechanism. Once in the bios, enable AHCI support for the disk, disable secure boot and reset setup keys. (I had to do this in order for the Linux kernel to boot, or it would ceaselessly prompt me to add the kernel hash to the EFI array of trusted hashes.)
  2. After this, a standard Arch boot stick will get you to the command line (this assumes no mode setting, as mode setting on this hardware introduces artifacts unless you pass enable_rc6=0 on the kernel cmdline). Follow the install instructions as per usual.
  3. I used a wired network to do the initial provisioning as documented in the Arch install documentation. Interesting with one usb port, no hub and both a usb flashstick and a usb NIC. Awesome. I personally used an ArchBoot iso as it loads itself entirely into memory, freeing up the USB port for the NIC.
  4. I personally recommend systemd-bootd, here is my Arch boot entry:/boot/loader/entries/arch.conf:

     title arch
     linux /vmlinuz-linux
     initrd /intel-ucode.img
     initrd /initramfs-linux.img
     options root=PARTUUID=8457d2b8-ba4a-4f9b-9098-03241bdbd20f rw i915.enable_rc6=0 pci=noaer quiet splash
  5. Wifi is the only sticking point as noted above, and requires you to address both points articulated above. This is what healthy dmesg output for the ath10k module looks like:

     [    3.425555] ath10k_pci 0000:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
     [    3.688718] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:01:00.0.bin failed with error -2
     [    3.688727] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/cal-pci-0000:01:00.0.bin failed with error -2
     [    3.689533] ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/QCA6174/hw3.0/firmware-5.bin failed with error -2
     [    3.689536] ath10k_pci 0000:01:00.0: could not fetch firmware file 'ath10k/QCA6174/hw3.0/firmware-5.bin': -2
     [    3.691039] ath10k_pci 0000:01:00.0: qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 17aa:0827
     [    3.691041] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 0 testmode 0
     [    3.691439] ath10k_pci 0000:01:00.0: firmware ver WLAN.RM.2.0-00180-QCARMSWPZ-1 api 4 features wowlan,ignore-otp,no-4addr-pad crc32 75dee6c5
     [    3.755748] ath10k_pci 0000:01:00.0: board_file api 2 bmi_id N/A crc32 6fc88fe7
     [    5.921449] ath10k_pci 0000:01:00.0: htt-ver 3.26 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
     [    6.005216] ath10k_pci 0000:01:00.0 wlp1s0: renamed from wlan0
  6. I kept on chasing the firmware-5.bin dragon for a while, but wifi works, so who gives a flying fig. The output of rfkill is way more important, as the hardware lock ends all dialogue.
  7. Those complications aside, everything is working and functioning at peak performance.


  • My Backspace key arrived feeling slightly broken and lopsided. Anything other than a direct strike failed to register on the key, and pressing on the bottom makes the top rise up, which feels a little broken.
  • Touchpad feels good, screen looks good if a little glossy. Gnome looks really good at 1080p on a 13.9 inch screen
  • Function keys are inverted by default and I have not established how to flip that at a system wide level


  • Yoga 910 is pretty fucking nice. The hinge is quite spiffy, but is really kinda academic if you have zero intention of using the device for its 2-in-1 functionality. I am actually disabling the touchscreen with supreme prejudice since I have never seen a beneficial touch experience in Linux. (Outside of Android)
  • Carbon X1 gen 2 kicked the shit out of this device. Keyboard is incomparably good, and I don’t find the bezel difference on the screens enough of a perk to even tilt my head in that direction. The bezel on the X1 ain’t bad at all.

Raw dumps


00:00.0 Host bridge: Intel Corporation Device 5904 (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Device 5916 (rev 02)
00:04.0 Signal processing controller: Intel Corporation Skylake Processor Thermal Subsystem (rev 02)
00:08.0 System peripheral: Intel Corporation Skylake Gaussian Mixture Model
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21)
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21)
00:15.3 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #3 (rev 21)
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1)
00:1d.0 PCI bridge: Intel Corporation Device 9d18 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Device 9d58 (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
00:1f.3 Audio device: Intel Corporation Device 9d71 (rev 21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
01:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
02:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller (rev 01)


Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 0cf3:e300 Atheros Communications, Inc. 
Bus 001 Device 003: ID 138a:0094 Validity Sensors, Inc. 
Bus 001 Device 002: ID 04f2:b5a4 Chicony Electronics Co., Ltd 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


0: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no
1: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no

upower -i $(upower -e | grep ‘BAT’)

  native-path:          BAT1
  vendor:               Simplo
  model:                BASE-BAT
  serial:               123456789
  power supply:         yes
  updated:              Wed 16 Nov 2016 12:16:42 PM PST (33 seconds ago)
  has history:          yes
  has statistics:       yes
    present:             yes
    rechargeable:        yes
    state:               discharging
    warning-level:       none
    energy:              70 Wh
    energy-empty:        0 Wh
    energy-full:         82.11 Wh
    energy-full-design:  78 Wh
    energy-rate:         11.12 W
    voltage:             8.28 V
    time to empty:       6.3 hours
    percentage:          85%
    capacity:            100%
    technology:          lithium-polymer
    icon-name:          'battery-full-symbolic'
  History (rate):
    1479327402	11.120	discharging



* make localmodconfig
* make clean (git clean -xdff, with the .config preserved)
* time make

real    7m52.257s
user    28m7.763s
sys 1m35.333s

Lenovo also has a high performance mode (vs balanced) which I enabled in the bios before repeating this compile just to see the impact

real    7m49.803s
user    27m58.650s
sys 1m33.703s

Irony at zenith, if you compile the Linux firmware for ath10k yourself, it will not fucking work. I don’t know where the functional firmware harks from, but if you simply build the kernel and the intree firmware, you get QCA6174/hw3.0-original with all the right names, in the wrong location (looks in hw3.0) and with fuck all chance of actually functioning (even with the correct symlink in place). I don’t think I will be buying a laptop with Qualcomm Atheros QCA6174 ever again.

Standing mysteries

Graphical corruption when wifi firmware is present and i915.enable_rc6 is not explicitly disabled.

Evaluating hardware accelerated Qt on Arch Linux with Aarch64 on the Raspberry Pi 3


Having found the Fedora aarch64 image to work well, I wanted to establish the same baseline with Arch Linux, partly in the name of newer versions on just about everything, partly for tribal reasons and also to see and document what is currently required to make this work. The information contained in the Fedora entry is still gonna be of interest, since it deals with adjusting both config.txt and extlinux.conf as requires to boot the device.


As laid out in my last blog entry, I had to recompile the kernel with CONFIG_ARM64_VA_BITS_48 unset in favour of CONFIG_ARM64_VA_BITS_39 usage. There is still some complexity with the boot setup of the pi3 which I have not managed to nail down, so I simply opted to use the boot partition from the existing Fedora image with the Arch Linux aarch64 userspace as provided by the Arch Linux Arm people.

This actually worked flawless, and having deployed my kernel modules to the unpacked Arch Linux rootfs I managed to immediately boot the Arch install. The only standing issue was a multitude of issues arising from the Fedora kernel not having CONFIG_SECCOMP (=y) set. Once I rebuilt the kernel with that enabled (and deployed it), everything appeared to be in good standing.

That is up until I tried to actually use the system Qt and the Qt I had compiled for the pi, at which point it became clear that the vc4 driver was absent and it was falling back to llvmpipe/software rasterization. (Launching Qt apps from ssh alerted me to this, weston-launch simply obediently launched and ran abysmally)

Turns out this is entirely by intent where:

    [[ $CARCH == "armv7h" || $CARCH == "armv6h" ]] && VC4=',vc4'

clearly excludes our aarch64 buddy. This is a pity as the vc4 driver builds flawlessly, and runs gloriously and I was reduced to spending the next 4 hours recompiling mesa (autotools baby) on the target. At the end of it, I was back to the shipping state of Fedora 24, and Qt could suddenly run with full OpenGL ES 2 acceleration on my aarch64 Arch install.

Applications launched with

    -platform eglfs

performed at full speed (limited to single window applications, so no cool-retro-term) with both the distro packaged Qt 5.7 and the Qt 5.8 I explicitly built for the device. Qt based Wayland clients (launched with -platform wayland) continued to crash as they have everywhere I have tested them against the VC4 driver, and I have yet to establish how to resolve this issue.


There is a fair amount of work from Kraxel and Eric Anholt to get this aarch64 Fedora image working, and people from the Arch community can readily benefit from this. It requires an unnecessary amount of legwork at present, and I am frankly a little surprised to see VC4 arbitrarily excluded from the aarch64 bit builds when it is fully functional.


My personal QML based artwork project (which normally runs for days on a stock RPI2 Arch install) is barfing after 5 minutes on the aarch64 image. I am not sure whether it is the kernel snapshot I swiped from Kraxel’s aarch64 fedora image, or my own changes to the kernel configuration, but this is not exactly a painless experience right now and kinda hard to recommend.

Evaluating hardware accelerated Qt on Fedora Linux 24 Raspberry Pi 3 (Aarch64)


A CONFIG_ARM64_VA_BITS_48 enabled kernel => QtQuick segfault. Fix that, and the packaged Qt 5.6 works well with the VC4 stack on Aarch64 Fedora 24, except Qt’s wayland support.


I recently learnt of a nice functional aarch64 image provided for the Raspberry Pi 3. I am not overly familiar with Fedora, but I have been waiting for someone to do all the legwork and provide a nicely bootable, functional aarch64 image. (I am immensely grateful to this Kraxel dude.)


Grab the image above. Boot it. IO feels a little sluggish, but outside of that everything seems awesome.

Update the software:

dnf upgrade --refresh


dnf check-update
dnf upgrade

(I am not a Fedora dude so forgive my cluelessness)

As of right now 08/20/2016, you just rendered your system unbootable as it is booting a mainline kernel without the associated configuration. Minor adjustment required:

/boot/config.txt (Fixes device tree and hence boot)

    # workaround firmware issue for rpi3
    # u-boot doesn't work without this
    avoid_warnings=2     # VPU shouldn't smash our display setup.

/boot/extlinux/extlinux.conf (Fixes the running of GLES2 apps)

    Append "cma=256M@256M" to the append line.

(I have no clue where to source a 64 bit /opt/vc, so the vc4 stack in the mainline kernel is the path of least resistance. (This is implicit in the overlay adjustment above))

Cool. System boots. There is an error in PolicyKit, but this does not appear to be a deal breaker and I will rely on someone else addressing that. Interacting with systemd services like nfs is no fun, so I am forced to ferry mmy sd-card between computer and pi. Outside of that, we are awesome.

Install weston and the mesa-dri-drivers, and weston-launch immediately starts to work, proving that the system is sane and ready for further use. My goal was to build Qt since I like to control what is running, and how it is built, but establishing the state of the system provided Qt is increasingly of interest to me as desktop distros are starting to cover non-X11 centric usage in an increasingly capable fashion.

Turns out the shipped Qt 5.6 on the Pi is actually very sane. Copying across the cube example from qtbase, and compiling/running it on the target with:

./cube -platform eglfs

proves that Qt is running with full hardware acceleration. Again awesome. Attempting to run qmlscene:

qmlscene -platform eglfs foo.qml

with a minimal QML application however crashes. Building my own Qt (Using my Arch recipe) fares no better. (Remedied as mentioned in last edit; Kernel was configured with hostile VA_48 option)

Attempts at using Qt wayland as both server/client discharge with:

    [root@rpi3 ~]# ./host-cube -platform wayland
    QObject::connect: invalid null parameter
    QObject::connect: invalid null parameter
    QObject::connect: invalid null parameter
    Using Wayland-EGL
    QObject::connect: invalid null parameter
    QObject::connect: invalid null parameter
    QObject::connect: invalid null parameter
    QObject::connect: invalid null parameter
    QObject::connect: invalid null parameter
    QObject::connect: invalid null parameter
    QObject::connect: invalid null parameter
    QObject::connect: invalid null parameter
    QObject::connect: invalid null parameter
    QObject::connect: invalid null parameter
    QObject::connect: invalid null parameter
    QObject::connect: invalid null parameter
    Attempting to import 646x513 b8g8r8a8_unorm with unsupported stride 2592 instead of 164
    wl_drm@19: error 2: invalid name
    The Wayland connection experienced a fatal error (Protocol error)

The server appears to be healthy, but there is something rotten in the state of the client app.

EGLFS performance

Take aways

  • Qt on Fedora is nicely configured and actually supports eglfs usage out of the box (Qt wayland not so much: “wl_drm@15: error 2: invalid name”)
  • OpenGL ES 2/EGL work on aarch64, as does weston. Qt wayland, as pure client or server/client both barf.


  • Investigate qtdeclarative crash (DONE, CONFIG_ARM64_VA_BITS_48 baby)
  • Investigate wayland issues


  • The Fedora atomicity of packages is a bit of a mind fuck to arch users. I am used to installing a package installing the -devel package implicitly, and I am especially confounded by the granularity of packages, such as mesa, where I should just have installed the whole bloody cacophony, 22kb at a time.
  • I hope Qt 5.8 addresses what constitutes a functional/successful build. For instance, my latest build was popped out without wayland-egl support due to the absence of the associated devel package. This happened for gbm as well. This kind of debugging loop is very extended. (At least with gbm I can enforce its inclusion along with kms as of Qt 5.7)



Turns out I am almost certainly being eaten by this bug which explains why other people were also griping about Firefox bursting into flames. Turns out, someone enabled:


in the frigging:

Linux rpi3 4.7.0-1-main #1 SMP PREEMPT Wed Aug 10 15:47:35 UTC 2016 aarch64 aarch64 aarch64 GNU/Linux

running on this beast


I have verified that CONFIG_ARM64_VA_BITS_48 was causing my grief with the Qt V4 engine barfing like a champion. Adjusting this also fixed standing crashes in PolicyKit. In order to get a functional kernel, I had to do the following:

  • dnf download –source kernel-main (on Fedora image)
  • Copy this to a build machine
  • Extracted the rpm (using on Arch)
  • Unpacked the source
  • Copied the standing config from /proc/config.gz to .config
  • make ARCH=arm CROSS_COMPILE=/opt/arm-sirspuddarch-linux-gnueabihf/bin/arm-sirspuddarch-linux-gnueabihf- bcm2835_defconfig
  • make ARCH=arm64 CROSS_COMPILE=/opt/aarch64-rpi3-linux-gnueabi/bin/aarch64-rpi3-linux-gnueabi- menuconfig
  • Disabled CONFIG_ARM64_VA_BITS_48 and adjust kernel as necessary
  • make ARCH=arm64 CROSS_COMPILE=/opt/aarch64-rpi3-linux-gnueabi/bin/aarch64-rpi3-linux-gnueabi-
  • INSTALL_MOD_PATH=foobar make ARCH=arm64 CROSS_COMPILE=/opt/aarch64-rpi3-linux-gnueabi/bin/aarch64-rpi3-linux-gnueabi- modules_install
  • Copy across the module directory indicated above, and the generated kernel ./arch/arm64/boot/Image (aarch64 requires this new Image format which contains ARM64 magic)
  • Update extlinux.conf

And now Qt Quick applications are working splendidly out of the box using the Fedora packaged version of Qt 5.6. The only drawback I can see is that the QtWayland compositor functionality is not enabled, and our wayland clients are still barfing as noted above, which provides sufficient impetus to package Qt for this device (for further investigation)

Thus far packaging Qt 5.7/5.8 for this image (using my AUR PKGBUILD) has not yielded any functional advantage beyond the stock Fedora Qt install, beyond the advances in Qt itself. (Qt Wayland for instance still barfs)


And the Qt developers have provided a patch which resolves this against an aarch kernel with 48 bit address spacing

Evaluating hardware accelerated Qt on Arch Linux Raspberry Pi [0,1,2,3]


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.


  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.
  7. Adjust cmdline.txt by appending the following to the existing kernel command line:


(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:

which needs to be built from source. Easy enough:

    git clone
    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.


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