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

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.