[QtonPi] QtonPi SW stack

andy.nichols at nokia.com andy.nichols at nokia.com
Tue Feb 7 20:55:22 CET 2012


Hi d3fault,

I'll try to answer inline below what I think is meant by some of the quotes.

On Feb 7, 2012, at 7:54 AM, ext d3fault wrote:

- QtonPi platform image (Fedora based for now, see below!)

- Documentation on how to get toolchain + sysroot + Qt Creator working to develop apps

As I understand it, we're talking about two different Fedora-based installations? One for the desktop with a cross-compiler targeting ARM/RaspberryPi... and the other being the actual Fedora distribution running on the Raspberry Pi... which uses a native compiler of course.


Right now it looks like what is(or will be) provided is a simple Fedora (arm) based sysroot (that is an image of the system your are compiling for containing your build dependancies), an ARM cross-compiler toolchain, and some helpers/plugins for Qt Creator to make it dead simple to get Creator to deploy to the RaspberryPi.

Since Fedora/etc will run on Raspberry Pi, won't the Qt libraries pretty much work right out of the box?

Technically speaking Qt 4 probably already works on Raspberry Pi, as its fairly easy to get unaccelerated raster graphics working in both QWS and X11 on arm devices.  Since the QtonPi project is about Qt 5, though we need to be able to use OpenGL ES2.  To use OpenGL ES2 on the Raspberry Pi you need to use whatever methods Broadcom has made available, and if there isn't support for GLX (or some other way to get a GL surface in X11) then we can't target X11.  I've not seen any OpenGL demos yet that are using X11, so I suspect that this is not available.

So in the sense you probably mean (Fedora + X11) Qt 5 does not work "out of the box"

I recall reading about Qt5 + Raspberry Pi + Wayland. Is this a separate effort? Is it even related? Sorry I'm just not sure how Wayland fits into all this.

- Qt 5 running on full-screen EGFS mode. We'll probably include the code-freeze version of Qt 5 and update it as we move along.

I'm confused. Why full-screen? Wouldn't each app just be a separate window like in desktop Fedora? Am I missing something? Is this full-screen EGFS for running Qt5 on the raspberry pi without a window manager?

So that brings me the solution to the above lack of X11 OpenGL problem.  One thing that is definitely possible to use EGL to get a fullscreen EGL surface.  Once we have that it's trivial to use OpenGL ES2 and thus Qt 5.  This has the unfortunate side affect of leaving us with the lack of a window manager.  We can still do some really great things with just a single fullscreen window surface, and that's where Wayland comes into the picture.

Once (if) we get support for shared video memory surfaces in the Raspberry Pi video driver, then we can use that single fullscreen surface as a Wayland compositor (QtWayland module makes this super simple).  This will be the replacement for X11, as each process will be run in a separate process, and shown on the screen via the Wayland compositor.

Until then though, its only possible to display a one Qt 5 application at a time.


- Support for Multi-Process Qt/Qt Quick Apps

Does that mean one process at a time... iOS style? Why wouldn't Multi-Process apps work right out of the box with Fedora installed? Is this only a Quick/3d related problem (you mention texture sharing later on)?


See Above




As for multimedia, I'm sure this has already been mentioned: wouldn't we just need an OpenMax back-end plugin for Phonon? Said plugin is used whenever the video is H.264... otherwise we fall back to software decoding.


This is another interesting problem that will need to be addressed.  I think that the OpenMax backend would need to be done for the QtMultimedia module (I may be wrong here).


That being said I'm actually really happy to see what's in the proposed plan, and can't wait to get some hardware so I can help out.


Andy Nichols
IRC: nezticle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qtonpi/attachments/20120207/53450d4d/attachment.html 


More information about the QtonPi mailing list