Hitching Qt/Embedded to a framebuffer OpenGL ES (2) abstraction

Published Thursday August 5th, 2010
13 Comments on Hitching Qt/Embedded to a framebuffer OpenGL ES (2) abstraction
Posted in Embedded, Lighthouse, OpenGL

People (customers in my case) often find themselves in a situation where
they have OpenGL ES 2 libraries for their hardware and want to use their
hardware’s OpenGL capabilities in conjunction with Qt.

If they are using Qt/X11 the complexity is drastically reduced, and all
they basically need to do is establish what the required link lines are in
order to get the Qt ./config.tests/unix/(egl|opengles*) tests to pass and
add these to the appropriate variables in their targets mkspec. Qt
compiles and everything should simply work without further consideration.
Your Qt/X11 happens to be using EGL rather than GLX, but you are completely
abstracted away from this unless you chose to dig. (We will assume for
undoubtedly nefarious purposes)

The problem with using X11 is that framebuffer OpenGL ES (2) drivers for various
platforms are often orders of magnitude more performant than their X equivalents due
to the overhead of the X11 coupling. (This overhead is not universally apparent and
depends on the quality of the X11 integation, quality of (vendor) system developer, length
of beard on your driver, phase of the moon and other hard to pin down quantities).

X11 is also a little over endowed in circumstances when you are running a
single application on a local display, and one can’t help but feel that the
(network) abstractions it offers, regardless of how wondrous they are, should be trimmed
away, which leads to many customers turning to/insisting on Qt/Embedded.

If they are using Qt/Embedded and want OpenGL ES (2) support they are immediately
stumped for a QScreen driver for anything other than powervr hardware.

q) Why doesn’t Qt (Development Frameworks) provide a generic OpenGL ES (2)
driver which can be used against any Khronos compliant EGL libraries?

a) This is due to the unfortunate absence of a formal specification for
surface management, which results in every EGL vendor cooking up their own
proprietary surface management abstractions such as WSEGL for Powervr:

http://qt.gitorious.org/qt/qt/blobs/4.7/src/3rdparty/powervr/wsegl.h

Since Qt/Embedded’s driver and windowing system (QWS) are tightly coupled,
porting Qt to a new vendor’s EGL abstraction is complex and requires a
serious engagement. This complexity should be drastically reduced in the
future as part of the Lighthouse project:

http://labs.trolltech.com/blogs/2009/10/02/introducing-new-port-of-qt-to-your-favourite-platform/

(stale but informative link, if this piques your interest please read the
subsequent lighthouse posts to come up to date with the current state of
affairs)

which as one of its goals decouples QWS from the Qt/Embedded, allowing any
external entity to manage the surfaces/windows. (This assumes the vendor in
the future provides a civilized surface abstraction and associated window manager
which takes full responsibility for managing the surfaces/windows it provides to Qt.)

The hope is that people will be enabled to rapidly extend Qt to any
windowing abstraction/manager which the future throws at us, be it:

QWS, Wayland, OpenKODE, SurfaceFlinger, YourOwnSurfaceManagementScreed

In the meantime, if you absolutely have to use any driver in the:

./src/plugins/gfxdrivers

as a reference for full QWS integration on a platform, please do yourself a
favour and use the powervr driver as inspiration (we do). It is feature
complete, relatively well tested and used on shipping devices. It is also
exceedingly well documented. (I didn’t write it, so this is not me plugging
my own work) We have had (external) intrepid bright sparks in the past root
around in said directory, root up a driver which was relevant at the turn
of the 21st century and use it as a foundation for their new driver. No
point loading the dice (read gun) against yourself.

q) I don’t care about windowing, all I want is a single fullscreen QGLWidget
which I want to:

1) Use directly for OpenGL ES 2 content
2) Use as a viewport to a QGraphicsView

a) Well, good news:

http://qt.gitorious.org/qt-labs/simplegl

was designed to scratch this itch. It has worked on every platform it has
been tested on, which include but are not limited to:

TI Beagleboard (c3)
Broadcom BCM911107VP
Freescale i.MX51

Please read the documentation:

http://qt.gitorious.org/qt-labs/simplegl/blobs/77704a984b6819230d98445e0117fd24633624f0/README

prior to use, as it mentions important considerations your should bear in
mind when using this driver.

We are accepting merge requests, feedback and abuse in the comments
section. Let the good times roll.

q) Should I use this on Beagleboard?

a) No, I would strongly recommend using the powervr driver on Beagleboards, I
just included the Beagleboard as one of the validation platforms in order
to verify the driver is broadly usable.

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

Posted in Embedded, Lighthouse, OpenGL

13 comments

SABROG says:

It is a simple create fullscreen widget, but how we can change screen resolution from 10280×1024 to 640×480 for speedup drawing? OpenGL does support this?

Uwe says:

It’s one month ago, that we wrote a screen driver for the Carmine chip of Fujitsu. To my surprise I had to notice, that Qt Embedded is broken ( since a long time including 4.7 ), as soon as you enable OpenGL. The effect is that most translations of the regular widgets ( != OpenGL ) are wrong. The bugs depend on the Q_BACKINGSTORE_SUBSURFACES compiler switch, that is enabled by the configure script for QtEmbedded/OpenGL, and are part of the Qt core libraries.

In consequence Qt will work with no OpenGL screen driver ( including the powervr ) properly !

I could manage to patch Qt, so that all problems of our application were gone and uploaded it: http://qt.gitorious.org/qt/qt/merge_requests/714 ( or see Case: 00166696 ). Another problem I have seen ( Case: 00167255 ) has even been noted as comment in the Qt code (Qt 4.6.3: qpaintengine_opengl.cpp, line 1369) by the developer. The Qt support told me, that this comment has been made in 2007 (!) and that “OpenGL and Qt/Embedded is a not a very well supported combination” closing the case without initiating any further steps.

Obviously nobody seems to be willing to make QtEmbedded/OpenGL usable until a basic redesign has been made. So all I can recommend when you think about Qt/Embedded with OpenGL today: stay away – if possible !

Uwe

ezjd says:

I didn’t really get Qt/X11 build and running with a OpenGL lib for some embedded hw. Can you point me to some detailed instructions?

AlexBravo says:

Thank you Donanld for a very useful post.

I think it might help people who are trying to bolt Qt/Embedded to OpenGL driver if there was a readme file in each of qgfxdrivers that talked about how old it is, how outdated, should it be looked at or not, etc.

Also I remember having hard time finding any info on WSEGL, so I found it easier to use ahigl as an example (since there were docs for it), but then later I found out that ahigl is pretty outdated.

It would be nice to create a doc that uses powervr driver as an example instead of ahigl here:
http://doc.qt.nokia.com/4.3/qtopiacore-ahigl.html

Of course most of this is not going to be required once Lighthouse is done,
but Lighthouse was announces about a year ago and hopefully people are not holding their breath. ๐Ÿ™‚

Donald Carr says:

@SABROG

I believe I have principally adjusted this through setting the framebuffer resolution of the device in question. Again, the control mechanisms appear to change from device to device, busybox’s fbset is the devil incarnate, that is the only consistent landmark on the embedded landscape, and many targets require the framebuffer to be set as a kernel argument. This aside, the frame buffer resolution appears to be respected and used by the majority of EGL implementations I have encountered, although I have not a doubt in my mind there are EGL implementations that completely disregard your framebuffer’s assertions. (I have seen this on devices which couple their EGL implementations to DirectFB and which use DirectFB’s initialization which includes explicit mode setting)

@Uwe

Thanks for writing the Carmine driver and for feeding your patches back via merge request, we appreciate your contribution. We want to maximize information flow and simplify this kind of project as much as possible. There is a massive information vacuum surrounding this kind of endeavor and we want to make an already complex task as straight forwards as possible. Architecturally we are addressing this through Lighthouse, in the meantime we are trying to dissipate information and support anyone undertaking this kind of task.

I hope that the response you received from support was worded differently from the exact phrasing above, as that sentiment is entirely wrong and the powervr driver is extensively used by numerous customers on shipping devices. We have every intention/desire to make Qt/Embedded as appealing to people with GL support on their targets as humanly possible, either for directly use of raw OpenGL ES 2 in a QGLWidget, or through the OpenGL ES 2 graphics system.

I am blocked by the absence of a functional Beagleboard, but as soon as this obstacle is removed (hopefully within the next couple of weeks, there is a standing order) I will attempt to reproduce your bug report, validate and consequently integrate your merge request.

@ezjd:

The only trick with cross compiling Qt/X11 is meeting all its header/lib dependencies without host contamination of the cross compile. I use scratchbox2 to achieve this, as blogged about here:

http://labs.trolltech.com/blogs/2009/09/10/cross-compiling-qtx11

Scratchbox2 in Ubuntu 10.04 appeared borked when I last attempted to use it, as it did not permit me to use the external native tools (host-gcc, etc) as favored by our maemo dabbling denizens, so I use the packages from 9.10

Uwe says:

Hi Donald,

You don’t need a beagle board or any hardware to see the problems I’m talking about. They appear even in qvfb on your PC without any OpenGL screen driver, when you manually set the Q_BACKINGSTORE_SUBSURFACES precompiler define.

I’m talking about very basic stuff: f.e when you scroll in a QListWidget the scrollbar isn’t updated. With little debugging you can see, that there is something blitted from the backingstore to the surface, but the region misses the translation of its relative position of the scrollbar in the window.

All bugs I have found have to do with translations because of the title/frame of the window or the relative offset of a child widget, that are missing or added twice. All of these bad translations are done in the Qt core library – not in the OpenGL screen driver – but only the combination OpenGL/QWS enables the bad code, that depends on Q_BACKINGSTORE_SUBSURFACES.

In consequnce all OpenGL toplevel windows with frames and most of the non OpenGL windows suffer from these bad translations, when Qt has been configured in this combination.

Uwe

PS: The phrase was like this and to be honest – from what I have found I guess, that nobody is using OpenGL/QWS beside maybe for OpenGL only + frameless applications.

Uwe

Uwe says:

Hi Donald,

The bugs are completely OpenGL unrelated – beside, that the combination OpenGL/QWS enables the Q_BACKINGSTORE_SUBSURFACES precompiler define. When you manually enable the flag you can see the problems, even with qvfb on your PC without Beagleboard or any OpenGL hardware at all. So if you are intersted in this you can check it now.

All bugs are related to translations because of the window titlebar/frame or the relative offset of a child widget, that are missing or added twice. F.e if you scroll in a list widget you will see, that the scrollbar isn’t updated. With little debugging you find, that the region, that is blitted from the backing store to the surface misses the relative offset of the scrollbar in the toplevel window.

Uwe

PS: The phrase was like this and from what I have found my guess is, that nobody is using OpenGL/QWS beside maybe for frameless OpenGL only applications.

Uwe says:

Hi Donald,

The bugs are completely OpenGL unrelated – beside, that the combination OpenGL/Qt-Embedded enables the Q_BACKINGSTORE_SUBSURFACES precompiler define. When you manually enable the flag you can see the problems – even with qvfb on your PC – without Beagleboard or any OpenGL hardware at all. So if you are interested in this you could check it now.

All bugs are related to translations ( because of the window titlebar/frame or the relative offset of a child widget ) that are missing or added twice. F.e if you scroll in a list widget you will see, that the scrollbar isn’t updated.
With little debugging you find, that the region, that is blitted from the backing store to the surface misses the relative offset of the scrollbar in the toplevel window.

Uwe

PS: The phrase was like this and from what I have found my guess is, that nobody is using OpenGL/QWS beside maybe for frameless OpenGL only applications. But this is a pure OpenGL application, where you don’t need Qt at all.

Donald Carr says:

@AlexBravo:

I admit it would be nice to replace that exhaustive ahigl dissertation with one which was actually functional and currently maintained. Apropos lighthouse, some people took to holding their breath some people took to writing Qt ports based on it:

http://gitorious.org/~taipan/qt/android-lighthouse

beaucoup respect to the android port community

Donald Carr says:

@Uwe

http://qt.gitorious.org/qt/qt/merge_requests/714

has been merged, thank you for your contribution.

WRT to your P.S. about fullscreen Qt applications being “pure OpenGL application, where you donโ€™t need Qt at all”, the only Qt functionality you are missing when using frameless fullscreen windows is the QWS decorations and QWS window management, which is not normally one of the primary selling points of Qt.

Reapproaching your orginal caveat to Qt/Embedded users:

The pain point in using OpenGL ES in conjunction with Qt/Embedded is currently expected to be writing a fully integrated Qt/Embedded OpenGL driver for hardware we don’t provide a driver for. (LinuxFB/DirectFB should work flawlessly out of the box, simplegl should work on sane OpenGL ES implementations). Qt/Embedded currently offers a bare bones windowing system/manager (QWS) which is basically a functional minimum, and Lighthouse strives to make this component entirely pluggable so that people can drop in whatever surface management functionality/application they require/desire. Using OpenGL in conjunction with the QWS window manager exposes some difficult to resolve issues, which we are chosing to address at the architectural level rather than with scotch tape. So on the Xen diagram the only point of pain should be the intersection of OpenGL, Qt/Embedded and the use of the QWS windowing functionality, which can merrily be side stepped (as you pointed out) with fullscreen applications.

Thanks again for your contribution, it was great

IanFromAfrica says:

Thanks for this! I’ve been doing a QWS screen driver on and off (it’s a hobby) for an esoteric hardware platform (ZiiLabs ZMS-05), and was a bit overwhelmed trying to figure out how what I needed to port from the PowerVR QWS driver. The driver here works fine for fullscreen GL (unfortunately there are only ES1 drivers available for the hardware at present even though it’s ES2 compatible), and it looks like a marriage of this work and what I’ve done for 2D on this platform should get me doing windowed GL faster than you can say “lighthouse”! ๐Ÿ˜‰

books online says:

I found you entry interesting do I’ ve add a Trackback to it on our blog

Guillermo says:

The libido of men can be down due to various reasons.
Cholesterol clogs arteries and allows less blood flow to.
Then again, the tension he is sensing can shortly influence his confidence and might very
easily turn to stress with regards to his intimate sexual contact.

Commenting closed.

Get started today with Qt Download now