Chasing the raspberry pi dragon: OpenGL ES2 accelerated Qt PI

Published Monday October 3rd, 2011
18 Comments on Chasing the raspberry pi dragon: OpenGL ES2 accelerated Qt PI
Posted in C++, Embedded, Kinetic, Lighthouse, OpenGL, Performance, Qt Quick

The raspberry pi initiative is very compelling and (forgive me for the hype) just got even more compelling now that we have Qt 5 running with full acceleration on the target. A tagline of “An ARM Linux box for $25. Take a byte!” sums it up rather nicely and should get many a geeks pulse racing. The Mer community have been good about getting Qt up and running on the Raspberry PI and we appreciate their drive and rapid work. We will now proceed to document how to build Qt in order to have full OpenGL ES 2 (tested) and OpenVG support (untested)

The mkspecs are here with associated patch(es).
The modified simplegl driver (required for QWS support in Qt 4.8) is here.

I have tested Qt 4.8 QWS with the simplegl driver, Qt 4.8 QPA (lighthouse) trunk with the EGLFS driver and Qt 5 trunk with the EGLFS driver. We are looking great on all fronts. (Videos to follow, but the performance is great at 1360×768) The required changes were a couple lines of Broadcom specific initialization code which is added to the simplegl connect method and the QEglFSScreen constructor respectively for QWS/QPA.

We clearly can’t distribute the libraries/headers the above mkspecs reference. (Qt Embedded/QPA are both largely self contained and only require external headers/libs for EGL/GLES2/OpenVG support)

I am using the Code Sourcery 2010q1 compiler.
I am using a sd-card (read snapshot) with all the required libraries (and the EGL/GLES2/VG headers required to compile Qt)

I was happy to see how easy it was to get Qt 5 cross compiled and running on the device. I restricted my build efforts to qtbase and qtdeclarative, but this built rapidly and without fault.

Caveat!: Before proceeding, my instructions are home brewed, pragmatic and get the job done. If you have better/functional instructions on getting the Qt 5 repo to a buildable state, then please don’t walk off a cliff with me.

Checking out Qt 5:

git clone git://
./qtrepotools/bin/qt5_tool -p

The implications of this are covered in the README

Proceeding with the build

Having symlinked in the appropriate mkspec from the git repo above and abstracting away my personal path arrangements, my configure line follows:

/opt/dev/src/qt5/qtbase/configure -prefix /opt/dev/qt-qpa-5-rasp-pi -release -no-phonon -no-qt3support -no-webkit -make libs -armfpa -arch armv6 -xplatform linux-rasp-pi-g++ -opengl es2 -confirm-license

Once this was built and you have your trusty qt 5 relevant qmake, creating a qtdeclarative directory within your shadow built qt, and running:

qmake /opt/dev/src/qt5/qtdeclarative/
make install

Gets you Qt Quick 2 (Scenegraph) enriched and merrily on your road to riches.

What remains to be done:

1) The device has OpenMax support which we could use for Audio/Video/Image decoding. It would be nice to see whether we can utilize this in Qt’s image loading plugin mechanism.
2) Get qtwebkit compiled, deployed and running on the target (Python related hijinxs stemming from the build-webkit script postponed inclusion in the done list above)
3) Turtles the whole way down (There is no shortage of board specific customization we could potentially indulge in)

I look forward to the deluge of videos showing the capabilities of accelerated Qt (4 or 5) on this fine hardware. We will be demoing this device in the demo pavilion at this year’s Qt Developer Day event in Munich and San Francisco and I will personally be on hand to answer any posting/cross compilation questions you may happen to have.

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

Posted in C++, Embedded, Kinetic, Lighthouse, OpenGL, Performance, Qt Quick


fan says:

I love you, QT!

dcarr says:

@fan: We love you too! And our code (read actions!) show it!

Hi , thanks for the kind words

I’m looking at tonight as it happens on the Pi

This will help with Mer integration


dcarr says:

@vgrade: Great to meet you, I have been party to your Trimslice work and appreciate the solid dev effort.

If you investigate you will find the link line and initialization code I have already integrated in our simplegl driver and supplied as a stand alone patch to Qt 5/4.8 in the mkspecs directory, namely:

0x4e84 says:

Wow, nice feat!

I’ll have to give a closer look to this great project!
Looking forward to see this running irl in Munich!


XiaMiaoren says:

Well done!

Q says:

As I know, recently, thousands of staff are transfering from Nokia to Accenture, including many Symbian developers. Does that mean Nokia is droping off Symbian? And how about the plan of Qt?? Thank you.

Qter says:

Great work!! I’m waiting for the demo on Galaxy S2 with full acceleration…

Donald says:

@0x4e84 @XiaMiaoren

It was a nice little platform with a Debian based minimalist Linux flavor and a relatively sane EGL/GLES2 implementation so it was relatively straight forwards to get Qt built, deployed and running. (3 hours) I should really stress that hellogles2 should no longer be used as the de facto benchmark (bring up test) in Qt5! since it behaves incredibly erratically. (Semi-catatonic). I went straight to scenegraph and was much happier for it

@Q and @Qter

No comment (Nokia have explicitly stated their stance towards Symbian and I will not champion it, I am a Linux dude) and no relevance (It already works, just build the Lighthouse android port (4.8) from source (trunk) and you are there) respectively

vladest says:

wow! cool to have Qt on such small beasty!
wonna couple of such things

Donald says:

If you follow my instructions above and get:

“error: ‘NativeMode’ is not a member of ‘v8::Script”

you have managed to fall between the cracks (of one of our scripts) and have to get your v8 repo to a known state as documented here:



git checkout 2eaa4b29586fdbd5d41f7b7d9e72ecca6d53dbd2 in ./qtbase/src/3rdparty/v8

and do something like:

for i in `ls ../../v8/*.patch`; do echo “Applying $i”; patch -p1 < $i; done


Rsh says:

I have TI OMAP3530 board with PowerVR graphics accelerator. Is there any place I can read how to cross compile Qt5 for that? – here it shows some complicated description on compiling Qt 4.6. If I have a filesystem root dir with old Qt + OpenGL + other libs, shouldn’t it be straightforward? I would appreciate any advice.

Donald says:


The instructions are identical, you just need to construct your own mkspec. That involves:

1) Establishing which toolchain can build/link against your rootfs libs
2) Establishing the GL link line

There is basically a one to one mapping from the entries in the rasp pi mkspec to what you would need/require in the OMAP3530 mkspec. (These QMAKE variables are a bit of a pain to establish so I would recommend modifying the rasp pi mkspec I supply above)

The blog you reference is for cross compiling for X11 which is infinitely more complex since the dependency tree goes through the roof. QPA is largely self contained and hence a doddle to cross compile for.

Rsh says:

@Donald: Thx to you and also to Thiago on IRC I am making progress with compiling Qt5 for my platform. I am still fighting with my toolchains and various issues but basic Qt’s configure is going through. One question though. Qt < 5.0 has a graphics driver for PowerVR chip that is in the OMAP based boards (such as Beagleboard). How Qt5 looks on this front? Will it work with the PowerVR? On one hand I see that maybe EGL is enough .. but on the other I read that is a complete mess (

Donald says:

A couple of things:

1) configure now needs to have -no-xcb -no-wayland passed to it (opt-out) due to hardcoded assumptions (read bugs) in the configure script (optimizing for ignorance)
2) ICS:

have siezed the torch, are running with it, and have already improved the standard keyboard handler well beyond the point of the stock implementation in Qt < 5.

@Rsh: I have run the simplegl driver on pvr hardware before and hence expect the eglfs platform to simply work out of the box (once you fix powervr.ini to use the standard surface plugins, not the Qt one required for the Qt pvr driver. My blog you reference above is indeed the correct blog to cite, although eglfs is the focal point in Qt 4.8 and 5. This driver is great for single process usage. For multi-process systems/devices we would need IMGTech to provide an implementation of the Wayland EGL platform as documented here:

Rsh says:

I have just compiled Qt5. All OpenGL ES2 examples from PVR do work for me. Qt shaders simply refuse to work – they compile fine in the shader-demo.qml, but they do not affect what is displayed
I had also problems with samegame.qml but fixing the shaders in QtDeclarative to use explicitly floating point “0.” instead of “0” fixed the shader compilation. Still, no “balls” visible at all in the samegame.

Donald says:


I fear this is gonna be the nature of Qt 5; shader level debugging.
The vertex shader specific demos did not work on the Rasp PI. This was the first deliverable from Broadcom, I was not certain if this was a Qt issue or an issue with their driver. We are all learning the ropes on this kind of debugging, first thing I need is to get a range of devices running Qt 5; then I will get a better idea of what works everywhere/nowhere/ever

Commenting closed.

Get started today with Qt Download now