Paul Olav Tvete

Introducing New Port of Qt to <Your Favourite Platform>

Published Friday October 2nd, 2009
16 Comments on Introducing New Port of Qt to <Your Favourite Platform>
Posted in Embedded, Lighthouse, Qt

Even if this is my first blog post, some of you may have seen my name before. I have been with Trolltech and Nokia since 1996 (which makes me senior surviving Troll), and I am here to introduce a little research project we are starting up.

As you all know, our motto is “Qt Everywhere”, and we would love to see Qt run on all the cool devices that are coming out these days, but the problem is that making a port from scratch is hard work: Qt ports generally contain tens of thousands of lines of code, and require intimate knowledge of Qt internals.

One way to port with less effort is to use Qt for Embedded Linux, which provides functionality for adapting to different graphical devices. Unfortunately, doing this is not always trivial. Today I will talk about something that might make things easier, but first a little historical background information:

Qt for Embedded Linux (or Qt/E for short) has been with us now for about 10 years (the Qt/FB project started around 15 October 1999), and it’s still going strong, powering everything from small hand-held devices to large industrial machinery. However, times move on, and we are seeing new types of hardware that are very different from what we envisioned 10 years ago.

While Qt/E still remains amazingly flexible, sometimes it starts to feel like a little too much work to port it to some systems. Qt/E
includes its own Q Windowing System (QWS), and this is not always relevant, especially for systems that already includes window system functionality, or features that make it possible to implement windowing in ways we didn’t foresee 10 years ago.

We have been looking at ways to refactor Qt/E so it no longer depends on QWS, but there is a lot of legacy there, and over the years knowledge of QWS has infiltrated large portions of the Qt/E codebase. Getting QWS out of Qt/E was starting to look like a major project.

Then, one day, Rhys came up with the idea of starting from the other direction. How difficult would it be to just stub out all the
platform-specific parts of Qt and get a completely new port to compile? Given that most of the infrastructure is already in place
thanks to the raster paint engine and Alien, it should then be fairly easy to get a single process to show a full-screen window on the framebuffer. After talking it over with Rhys, I was starting to hope that this could help with the QWS problem as well, but of course we needed to try it out to see if it was actually feasible.

Rhys had something compiling in less than a week, and we had pixels on screen the next day.

We then played around with it for a couple of weeks, getting most of the crashes out of the system, as well as adding a few more back-ends that showed that we could support slightly more complex behavior.

Then we had to start concentrating on the upcoming 4.6.0 release for a while. However, word started spreading around, and people from all over were asking questions and found out that this could be the perfect thing for their pet project. Therefore, we realized that it’s about time to show off the results of our little feasibility study.

The most important thing for a project is of course a code name, and we decided on Lighthouse [not to be confused with a very early preview of Qt for S60 that was used by about 5 people outside Nokia…] since this meant we didn’t have to change the Q_WS_LITE platform define.

And of course, the obligatory screenshot. This one’s made using the “testlite” back-end:


Boring, right? It looks just like Qt… The point about Lighthouse is how easy it is to write a backend for new hardware. A more interesting picture would be to see how much code is needed to do that. Let’s look at the “minimal” backend, which is a complete example showing how to use a QImage as a display device:

~/git/qt-lighthouse/src/plugins/graphicssystems/minimal$ wc -l *
71 main.cpp
70 qgraphicssystem_minimal.cpp
85 qgraphicssystem_minimal.h
101 qwindowsurface_minimal.cpp
73 qwindowsurface_minimal.h
410 total

410 lines of code is not too bad, but, wait a minute! That includes 40 lines of copyright header per file. Sloccount gives us a better impression:

Total Physical Source Lines of Code (SLOC) = 147

Now for something with a bit more meat to it: The OpenVG back-end clocks in at a SLOCcount of 288 lines, and it took about a day to write.

This is still early days, and very little is set in stone (or even properly documented), but you can check out the code, and see some very basic getting-started documentation at:

Just to make it very clear: this is a research project that is just starting out. Don’t assume that anything will work, or that any APIs
will stay the same for long. Count yourself lucky if it does not crash horribly and lock up your machine, or worse.

If you want to join in the fun, we can use the mailing list for development
discussions. I also hang around on #qt-labs as paulot from time to time.

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

Posted in Embedded, Lighthouse, Qt


This is very interesting. I was looking to see if it were possible to embed Qt into the OGRE rendering engine (basically having QWidgets as textures with full mouse and keyboard interactions, like in Quake IV) but previously having to write a complete back-end was far too daunting. Once this has progressed/stabilised a tad I’ll have a look.

e8johan says:

How do you plan to handle dialogs and such, for instance, the “About Qt” dialog in the screenshot, without a window manager. (And yes, I’m too lazy, so I’m asking here instead of downloading, compiling and clicking the damn thing :-P)

espenr says:

Bah, there were at least 7 people who tried that preview! ;D

Scorp1us says:

iPhone has .NET now… When will it get Qt?

Qtuser says:

iPhone port , at least in some form. Even it requires some compile in a lab at QT HQ would be so so helpful to me and I would be many others.

Reed Hedges says:

Thanks, this makes me excited about using Qt, the more platforms and devices the better!

“How do you plan to handle dialogs and such, for instance, the “About Qt” dialog in the screenshot, without a window manager.”

The idea is to do it in the graphics system plug-in, which is responsible for managing the window surfaces and how pixels actually get onto the screen. If that involves talking to a system-provided window manager … or even writing your own … then you do it there.

Embedded systems are more likely to have a window manager already these days (e.g. embedded X11 on Maemo devices) or the nature of the application doesn’t require it. e.g. applications written with Qt Declarative UI often run full-screen on an embedded device and provide their own methods of interaction that are more immersive than window borders and close buttons. Then all the Lighthouse graphics system has to do is pump the pixels to the one full-screen window as fast as possible.

AlexBravo says:

Qt on S60 doesn’t use QWS, it Uses Symbian’s window manager, right? Would this project be a way of bypassing Symbian’s window manager and making graphics much faster on devices such as N97?

Fabio Fx says:

What about PSP or NDS :D? No no I’m not joking, a support to game devices may help to improve 3d graphics subsystem of Qt (suck as kinetc integration or other unforseeable things).
May worth a port Xbox, PS series and Nintendo Wii for the same reasons

Strahlex says:

IPhone and Android port would be very nice. So nearly the whole mobile market could be reached with only one programming framework.

Marius says:

@iPhone dudes: There is some community effort, started by greybird, for porting Qt to iPhone already. I’m sure he’d love the help:

Anon says:

@Fabio Fx:

The NDS only has 4MB RAM, IIRC, so a port of Qt would be of limited use 😉 Qt for the other platforms would be good, though.

rix says:

+1 for iPhone support ! 🙂 I understand porting QtGui is not an easy task (and might not even adapt very well to the iPhone UI guidelines), but a port of all others modules (QtCore, QtNetwork, QtScript, …) would be an invaluable help to all cross-plateform developers.

Cool! Great job!
There are some discussions about porting Qt to Minix 3 and probably to GNU Hurd. The thing you’re doing will be really helpful.

shamaz says:

This really looks like the Caciocavallo project on the openjdk !!! ( )
For example, they used it to port swing/awt to SDL in just one day.
By the way, you might work with them to make a swing on Qt port :)))

shamaz says:

For more information, you could check the blog mario torre

Commenting closed.

Get started today with Qt Download now