qt5 xcb gles2

qt5 xcb gles2

[Juha Vuolle]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

Hi all,

I was wondering if it is possible to build and use Qt5 with XCB plugin
additionally with OpenGL ES 2.0 support?
I'm using the nitrogen6x board.

Couple days ago I built Qt 5 against the Dylan branch and got the EGLFS
working (quite impressive performance).
Now I left the master branch baking overnight (fsl-image-gui) and was
thinking on trying to compile the Qt 5
with XCB (I took master just in case to get the latest things).

I don't mind cross-compiling qt myself i.e. not use the meta-qt5 but so far
I haven't found any reference that will it be even
possible to do (with XCB), does it have any chance to work/made to work?
I'd be very grateful for any experiences, hints, tips, thoughts.

For my somewhat unorthodox use-case it would not necessarily have to be
even really HW accelerated, for instance Mesa SW rasterizer could do the
trick as well.

cheers,
Juha

[-- Attachment #2: Type: text/html, Size: 1113 bytes --]

Re: qt5 xcb gles2

[Eric Bénard]

Hi Juha,

Le Mon, 26 Aug 2013 20:55:25 +0300,
Juha Vuolle <juvuolle@gmail.com> a écrit :
> I was wondering if it is possible to build and use Qt5 with XCB plugin
> additionally with OpenGL ES 2.0 support?
> I'm using the nitrogen6x board.
> 
> Couple days ago I built Qt 5 against the Dylan branch and got the EGLFS
> working (quite impressive performance).

Are you using the bbappend of meta-fsl-arm ?

> Now I left the master branch baking overnight (fsl-image-gui) and was
> thinking on trying to compile the Qt 5
> with XCB (I took master just in case to get the latest things).
> 
> I don't mind cross-compiling qt myself i.e. not use the meta-qt5 but so far
> I haven't found any reference that will it be even
> possible to do (with XCB), does it have any chance to work/made to work?
> I'd be very grateful for any experiences, hints, tips, thoughts.
> 
I'm sending you a patch which was only compile tested and still need
some polish
If you can try it and provide feedback that would help to get xcb into
master.

Thanks,
Eric

Re: qt5 xcb gles2

[Juha Vuolle]

Hi Eric,

2013/8/26 Eric Bénard <eric@eukrea.com>:
> Hi Juha,
>
> Le Mon, 26 Aug 2013 20:55:25 +0300,
> Juha Vuolle <juvuolle@gmail.com> a écrit :
>> I was wondering if it is possible to build and use Qt5 with XCB plugin
>> additionally with OpenGL ES 2.0 support?
>> I'm using the nitrogen6x board.
>>
>> Couple days ago I built Qt 5 against the Dylan branch and got the EGLFS
>> working (quite impressive performance).
>
> Are you using the bbappend of meta-fsl-arm ?

No just the dylan stock stuff. I'm brand new to yocto and I compiled
Qt by hand. I had to do some "dirty" GPU trick to get the right libEGL
built
(actually I think it was a thought inspired by some of your email May
this year, setting the USE_[X11|DFB] to "no").

>> Now I left the master branch baking overnight (fsl-image-gui) and was
>> thinking on trying to compile the Qt 5
>> with XCB (I took master just in case to get the latest things).
>>
>> I don't mind cross-compiling qt myself i.e. not use the meta-qt5 but so far
>> I haven't found any reference that will it be even
>> possible to do (with XCB), does it have any chance to work/made to work?
>> I'd be very grateful for any experiences, hints, tips, thoughts.
>>
> I'm sending you a patch which was only compile tested and still need
> some polish
> If you can try it and provide feedback that would help to get xcb into
> master.

Thanks appreciated.

> Thanks,
> Eric

Re: qt5 xcb gles2

[Juha Vuolle]

> > some polish
> > If you can try it and provide feedback that would help to get xcb into
> > master.
>
> Thanks appreciated.

Can't yet comment on the real XCB patch as it's still baking, have to
get back to that later.

In the meanwhile I thought I'd mention I managed to manually compile
qt5 with xcb support against the master.
There were some hurdles on the way but I got at least the Qt widget
applications running on the X (run in the default matchbox window
manager of my image).

The QtQuick2 and consequently EGL/gles2 didn't at least yet work so great:

root@nitrogen6x:~/helloworld# DISPLAY=:0 ./helloworld
Qt Warning: Could not find a location of the system's Compose files.
Consider setting the QTCOMPOSE environment variable.
Warning: EGL suggested using X Visual ID 33 (RGB565) for EGL config 28
(RGB444), but this is incompatable
Unable to find an X11 visual which matches EGL config 28
Could not initialize EGL
Aborted

cheers,
Juha

> > Thanks,
> > Eric

Re: qt5 xcb gles2

[Juha Vuolle]

After a small hiatus I returned to this and got the qt5 + gles2 + xcb
combination working.
Just to let people know that it is possible. I can now run QtQuick2
apps QGLWidgets etc. hellogl_es2 seems to go closer to 300 FPS.
As an additional cherry on top the x11vnc works with them too.

I took the latest master-nexts of everything, compiled Qt myself and
put a small bruteforce hack into Qt relating to the "incompatable
color depths".
Note: you may have to force the hard floats on in the Qt compilation,
I added "DISTRO_OPTS += hard-float" to the "linux-imx6-g++/qmake.conf
". If you don't do this the likely first symptom is that all Qt's
configure tests fail.

Juha


2013/8/27 Juha Vuolle <juvuolle@gmail.com>:
>> > some polish
>> > If you can try it and provide feedback that would help to get xcb into
>> > master.
>>
>> Thanks appreciated.
>
> Can't yet comment on the real XCB patch as it's still baking, have to
> get back to that later.
>
> In the meanwhile I thought I'd mention I managed to manually compile
> qt5 with xcb support against the master.
> There were some hurdles on the way but I got at least the Qt widget
> applications running on the X (run in the default matchbox window
> manager of my image).
>
> The QtQuick2 and consequently EGL/gles2 didn't at least yet work so great:
>
> root@nitrogen6x:~/helloworld# DISPLAY=:0 ./helloworld
> Qt Warning: Could not find a location of the system's Compose files.
> Consider setting the QTCOMPOSE environment variable.
> Warning: EGL suggested using X Visual ID 33 (RGB565) for EGL config 28
> (RGB444), but this is incompatable
> Unable to find an X11 visual which matches EGL config 28
> Could not initialize EGL
> Aborted
>
> cheers,
> Juha
>
>> > Thanks,
>> > Eric

Re: qt5 xcb gles2

[Ahmed Ammar]

That sounds great.

Any chance you can give a complete write up on how to reproduce this?

Regards,
Ahmed.

On Sep 11, 2013, at 5:29 AM, Juha Vuolle <juvuolle@gmail.com> wrote:

> After a small hiatus I returned to this and got the qt5 + gles2 + xcb
> combination working.
> Just to let people know that it is possible. I can now run QtQuick2
> apps QGLWidgets etc. hellogl_es2 seems to go closer to 300 FPS.
> As an additional cherry on top the x11vnc works with them too.
> 
> I took the latest master-nexts of everything, compiled Qt myself and
> put a small bruteforce hack into Qt relating to the "incompatable
> color depths".
> Note: you may have to force the hard floats on in the Qt compilation,
> I added "DISTRO_OPTS += hard-float" to the "linux-imx6-g++/qmake.conf
> ". If you don't do this the likely first symptom is that all Qt's
> configure tests fail.
> 
> Juha
> 
> 
> 2013/8/27 Juha Vuolle <juvuolle@gmail.com>:
>>>> some polish
>>>> If you can try it and provide feedback that would help to get xcb into
>>>> master.
>>> 
>>> Thanks appreciated.
>> 
>> Can't yet comment on the real XCB patch as it's still baking, have to
>> get back to that later.
>> 
>> In the meanwhile I thought I'd mention I managed to manually compile
>> qt5 with xcb support against the master.
>> There were some hurdles on the way but I got at least the Qt widget
>> applications running on the X (run in the default matchbox window
>> manager of my image).
>> 
>> The QtQuick2 and consequently EGL/gles2 didn't at least yet work so great:
>> 
>> root@nitrogen6x:~/helloworld# DISPLAY=:0 ./helloworld
>> Qt Warning: Could not find a location of the system's Compose files.
>> Consider setting the QTCOMPOSE environment variable.
>> Warning: EGL suggested using X Visual ID 33 (RGB565) for EGL config 28
>> (RGB444), but this is incompatable
>> Unable to find an X11 visual which matches EGL config 28
>> Could not initialize EGL
>> Aborted
>> 
>> cheers,
>> Juha
>> 
>>>> Thanks,
>>>> Eric
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: qt5 xcb gles2

[Juha Vuolle]

Hi,

sure. But please be aware this was the tinker/hack'n'slash way that I did
just to gain understanding if or not it is possible in the first
place. Aka The fun way ;-)

(I think more proper way would be getting the meta-qt5 up and running
with XCB + understanding
the "x11 visual" <--> "EGL" color depth incompatibility issue. With
Eric's patch the Qt built for XCB but then there is still
the color depth issue and lack of qmake to compile Qt things. And also
with the patch I think the
Qt was configured slightly "wrong" in a sense that XCB QPA uses GLX
instead of EGL).

1) downloaded the fsl community yocto project and checked out
master-next branches of "meta-fsl-arm", "meta-fsl-arm-extra", and
"poky"

2) to be on the safe side I modified the poky.conf under the poky to
rid the wayland. Not sure if this was necessary:
-POKY_DEFAULT_DISTRO_FEATURES = "largefile opengl multiarch wayland"
+POKY_DEFAULT_DISTRO_FEATURES = "largefile opengl multiarch x11"

3) bitbaked the project. I baked the fsl-image-gui (next time I would
try/check the core-image-x11). So the usual
MACHINE=nitrogen6x source setup-environment build
bitbake fsl-image-gui

4.1) once built I ripped the "eglvivante.h" file found under
sysroots/nitrogen6x/usr/include/EGL
In essence the file has a main level #ifdef logic to see which EGL
definitions to use.
Because we are building the Qt "outside" the defines are not correct
and you will end up with wrong
EGL definitions. So delete all other except the X11 #ifdef branches
(starting below /* X11 platform */ -comment).
Alternatively I guess you could add appropriate defines to your Qt's
.pro files somewhere.
The resulting file is quite small (< 70 lines). If you don't do this
the first likely symptom is something like
error: cannot convert 'Display* {aka _XDisplay*}' to
'EGLNativeDisplayType {aka _FBDisplay*}' and now you know roughly why.

4) downloaded Qt 5 pretty much as in the instructions:
https://community.freescale.com/docs/DOC-94066
But don't do the configure just yet.

5) modified the Qt a bit

5.1) Turned on the hard floats by adding
DISTRO_OPTS += hard-float
to
/qtbase/mkspecs/devices/linux-imx6-g++/qmake.conf
To know this was effective later when configuring Qt you should see
"-mfloat-abi=hard" in the g++ command. If you don't see it _AND_ the
all of Qt configure tests fail this is a likely cause.
This may work the other way around too, really depends if your sysroot
abi is hard / soft float.

5.2) Brute-forced the egl - x visual compatibility issue by tweaking
the file under qtbase:

src/platformsupport/eglconvenience/qxlibeglintegration.cpp
the function
VisualID QXlibEglIntegration::getCompatibleVisualId(Display *display, EGLDisplay
to return
-    return (VisualID)0;
+    return (VisualID)33;

6) Configured Qt

This of course comes in many flavors but this was my line:
./configure  -v -opensource -confirm-license -no-pch -qpa xcb -qt-xcb -no-eglfs
             -no-kms -no-linuxfb -no-directfb  -opengl es2 -make libs
-make examples
             -device imx6 -device-option
CROSS_COMPILE=/home/tummeli/yocto/fsl-master-next/build/tmp/sysroots/i686-linux/usr/bin/cortexa9hf-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-
             -sysroot
/home/tummeli/yocto/fsl-master-next/build/tmp/sysroots/nitrogen6x
             -prefix /home/tummeli/nx6-xcb-inst

7) make, make installed Qt

8) deployed Qt on the device

There are many ways to do this but I used simple "scp" as I don't
currently have TFTP sysroot nor use rootfs as build sysroot.
You need to copy three things and set environment variables
accordingly on the device. If you copy stuff to Qt default
locations then the environment variables are not needed. You will find
the below stuff under sysroot whereever you set the "-prefix".

- Qt libs (libQt5*so.5) at lib/* --> LD_LIBRARY_PATH
- Qt plugins (QPAs, bearer management, ...) at plugins/* --> QT_PLUGIN_PATH
- Qml plugins (if needed) at qml/* --> QML2_IMPORT_PATH


9) Run the apps!

scp your app on the device and run, for example
DISPLAY=:0 ./analogclock

Note: on first time after boot none of the Qt apps show anything and
there is an XCB error:
QXcbConnection: XCB error: 146 (Unknown), sequence: 156, resource id:
0, major code: 139 (Unknown), minor code: 20
Kill the app and all subsequent runs for all Qt apps will work.  Any
thoughts / help in this area would be highly
appreciated!

cheers,
Juha

2013/9/11 Ahmed Ammar <aammar@genesi-usa.com>:
> That sounds great.
>
> Any chance you can give a complete write up on how to reproduce this?
>
> Regards,
> Ahmed.
>
> On Sep 11, 2013, at 5:29 AM, Juha Vuolle <juvuolle@gmail.com> wrote:
>
>> After a small hiatus I returned to this and got the qt5 + gles2 + xcb
>> combination working.
>> Just to let people know that it is possible. I can now run QtQuick2
>> apps QGLWidgets etc. hellogl_es2 seems to go closer to 300 FPS.
>> As an additional cherry on top the x11vnc works with them too.
>>
>> I took the latest master-nexts of everything, compiled Qt myself and
>> put a small bruteforce hack into Qt relating to the "incompatable
>> color depths".
>> Note: you may have to force the hard floats on in the Qt compilation,
>> I added "DISTRO_OPTS += hard-float" to the "linux-imx6-g++/qmake.conf
>> ". If you don't do this the likely first symptom is that all Qt's
>> configure tests fail.
>>
>> Juha
>>
>>
>> 2013/8/27 Juha Vuolle <juvuolle@gmail.com>:
>>>>> some polish
>>>>> If you can try it and provide feedback that would help to get xcb into
>>>>> master.
>>>>
>>>> Thanks appreciated.
>>>
>>> Can't yet comment on the real XCB patch as it's still baking, have to
>>> get back to that later.
>>>
>>> In the meanwhile I thought I'd mention I managed to manually compile
>>> qt5 with xcb support against the master.
>>> There were some hurdles on the way but I got at least the Qt widget
>>> applications running on the X (run in the default matchbox window
>>> manager of my image).
>>>
>>> The QtQuick2 and consequently EGL/gles2 didn't at least yet work so great:
>>>
>>> root@nitrogen6x:~/helloworld# DISPLAY=:0 ./helloworld
>>> Qt Warning: Could not find a location of the system's Compose files.
>>> Consider setting the QTCOMPOSE environment variable.
>>> Warning: EGL suggested using X Visual ID 33 (RGB565) for EGL config 28
>>> (RGB444), but this is incompatable
>>> Unable to find an X11 visual which matches EGL config 28
>>> Could not initialize EGL
>>> Aborted
>>>
>>> cheers,
>>> Juha
>>>
>>>>> Thanks,
>>>>> Eric
>> _______________________________________________
>> meta-freescale mailing list
>> meta-freescale@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-freescale
>

Re: qt5 xcb gles2

[Eric Bénard]

Hi Juha,

Le Fri, 13 Sep 2013 10:27:09 +0300,
Juha Vuolle <juvuolle@gmail.com> a écrit :
> sure. But please be aware this was the tinker/hack'n'slash way that I did
> just to gain understanding if or not it is possible in the first
> place. Aka The fun way ;-)
> 
> (I think more proper way would be getting the meta-qt5 up and running
> with XCB + understanding
> the "x11 visual" <--> "EGL" color depth incompatibility issue. With
> Eric's patch the Qt built for XCB but then there is still
> the color depth issue and lack of qmake to compile Qt things. And also
> with the patch I think the
> Qt was configured slightly "wrong" in a sense that XCB QPA uses GLX
> instead of EGL).
> 
I have plans to work again on this by the end of september thanks for
your instructions that's helpful.

Eric

Re: qt5 xcb gles2

[Juha Vuolle]

A comment / workaround for this one:

> Note: on first time after boot none of the Qt apps show anything and
> there is an XCB error:
> QXcbConnection: XCB error: 146 (Unknown), sequence: 156, resource id:
> 0, major code: 139 (Unknown), minor code: 20
> Kill the app and all subsequent runs for all Qt apps will work.  Any

The major code is X runtime instance specific, and in my case the 139 is RandR.
Calling "xrandr" once on the command line causes randr to load and
workaround the issue.
Maybe will file a bug for Qt, perhaps there is a randr initialization
timing issue. Anyway the workaround is easy enough; ensuring that the
xrandr is called somewhere once during the boot (for instance at
matchbox init if you use such thing).

Re: qt5 xcb gles2

[Benjamin Federau]

Hello,

I followed your discussion about qt5, xcb and gles2 on an i.MX6 board.

Finally the workaround/hack by setting the VisualId hard to "33" helped me a lot
to get Qt5.1.1 running on my SabreLite SD board. Thanks for that. :)

First, I have to say that I use Ubuntu 12.04 instead of Yocto on my board. But I
use the same graphic libs and dev headers version (3.5.7-1.0.0) as in the next
branch of the meta-fsl-layer.

I found out that I could not compile Qt5.1.1 with the
/usr/include/EGL/eglplatform.h header from the Freescale graphic libs package.
When I use this header I run into the following problem.

QT5 make fails on QUrl  - http://qt-project.org/forums/viewthread/25896

If I replace the eglplatform.h with the one from the Ubuntu standard mesa
package the compilation runs through. The issue must be related to the
MESA_EGL_NO_X11_HEADERS macro which is not used inside the Freescale
eglplatform.h file.

My qmake.conf
....
QMAKE_INCDIR           += /usr/include
QMAKE_LIBDIR           += /usr/lib

QMAKE_LIBS_EGL         += -lEGL
QMAKE_LIBS_OPENGL_ES2  += -lGLESv2 -lEGL -lGAL
QMAKE_LIBS_OPENVG      += -lOpenVG -lEGL -lGAL

IMX6_CFLAGS             = -march=armv7-a -mfpu=neon -mfloat-abi=hard -DLINUX=1
IMX6_CFLAGS_RELEASE     = -O2 $$IMX6_CFLAGS
QMAKE_CFLAGS_RELEASE   += $$IMX6_CFLAGS_RELEASE
QMAKE_CXXFLAGS_RELEASE += $$IMX6_CFLAGS_RELEASE
QMAKE_CFLAGS_DEBUG     += $$IMX6_CFLAGS
QMAKE_CXXFLAGS_DEBUG   += $$IMX6_CFLAGS
....

and my configure command

./configure -v -opensource -confirm-license -no-pch -opengl es2 -qpa xcb -nomake
examples -nomake tests -platform linux-imx6-g++ -prefix /opt/qt5.1.1


So I wonder how you could build qt5.1.1 with the Freescale eglplatform.h.


Any hints are welcome where I could start digging to solve that issue.


Regards
-
Benjamin Federau

Re: qt5 xcb gles2

[Andy Voltz]

Hi Benjamin,

> I followed your discussion about qt5, xcb and gles2 on an i.MX6 board.
> 
> Finally the workaround/hack by setting the VisualId hard to "33" helped me a lot
> to get Qt5.1.1 running on my SabreLite SD board. Thanks for that. :)
> 
> First, I have to say that I use Ubuntu 12.04 instead of Yocto on my board. But I
> use the same graphic libs and dev headers version (3.5.7-1.0.0) as in the next
> branch of the meta-fsl-layer.
> 
> I found out that I could not compile Qt5.1.1 with the
> /usr/include/EGL/eglplatform.h header from the Freescale graphic libs package.
> When I use this header I run into the following problem.
> 
> QT5 make fails on QUrl  - http://qt-project.org/forums/viewthread/25896
> 
> If I replace the eglplatform.h with the one from the Ubuntu standard mesa
> package the compilation runs through. The issue must be related to the
> MESA_EGL_NO_X11_HEADERS macro which is not used inside the Freescale
> eglplatform.h file.
> 
> My qmake.conf
> ....
> QMAKE_INCDIR           += /usr/include
> QMAKE_LIBDIR           += /usr/lib
> 
> QMAKE_LIBS_EGL         += -lEGL
> QMAKE_LIBS_OPENGL_ES2  += -lGLESv2 -lEGL -lGAL
> QMAKE_LIBS_OPENVG      += -lOpenVG -lEGL -lGAL
> 
> IMX6_CFLAGS             = -march=armv7-a -mfpu=neon -mfloat-abi=hard -DLINUX=1
> IMX6_CFLAGS_RELEASE     = -O2 $$IMX6_CFLAGS
> QMAKE_CFLAGS_RELEASE   += $$IMX6_CFLAGS_RELEASE
> QMAKE_CXXFLAGS_RELEASE += $$IMX6_CFLAGS_RELEASE
> QMAKE_CFLAGS_DEBUG     += $$IMX6_CFLAGS
> QMAKE_CXXFLAGS_DEBUG   += $$IMX6_CFLAGS
> ....
> 
> and my configure command
> 
> ./configure -v -opensource -confirm-license -no-pch -opengl es2 -qpa xcb -nomake
> examples -nomake tests -platform linux-imx6-g++ -prefix /opt/qt5.1.1
> 
> So I wonder how you could build qt5.1.1 with the Freescale eglplatform.h.
> 
> Any hints are welcome where I could start digging to solve that issue.
> 

The vivante EGL headers don't honor MESA_EGL_NO_X11_HEADERS, and generally seem to assume X if no other defines are specified. Defining EGL_API_FB for the affected platform plugins gets around the X11 defines--I had to patch qt sources (shown below). I ran into more issues after getting around this error, but this should get you moving: 

diff -Nuar qt-everywhere-opensource-src-5.1.1-orig/qtbase/src/plugins/platforms/eglfs/eglfs.pri qt-everywhere-opensource-src-5.1.1/qtbase/src/plugins/platforms/eglfs/eglfs.pri
--- qt-everywhere-opensource-src-5.1.1-orig/qtbase/src/plugins/platforms/eglfs/eglfs.pri	2013-09-25 15:36:24.263942856 -0400
+++ qt-everywhere-opensource-src-5.1.1/qtbase/src/plugins/platforms/eglfs/eglfs.pri	2013-09-25 15:37:17.399941690 -0400
@@ -3,7 +3,7 @@
 #DEFINES += QEGL_EXTRA_DEBUG
 
 #Avoid X11 header collision
-DEFINES += MESA_EGL_NO_X11_HEADERS
+DEFINES += MESA_EGL_NO_X11_HEADERS EGL_API_FB
 
 #To test the hooks on x11 (xlib), comment the above define too
 #EGLFS_PLATFORM_HOOKS_SOURCES += qeglfshooks_x11.cpp
diff -Nuar qt-everywhere-opensource-src-5.1.1-orig/qtbase/src/plugins/platforms/linuxfb/linuxfb.pro qt-everywhere-opensource-src-5.1.1/qtbase/src/plugins/platforms/linuxfb/linuxfb.pro
--- qt-everywhere-opensource-src-5.1.1-orig/qtbase/src/plugins/platforms/linuxfb/linuxfb.pro	2013-09-25 15:36:24.195942859 -0400
+++ qt-everywhere-opensource-src-5.1.1/qtbase/src/plugins/platforms/linuxfb/linuxfb.pro	2013-09-25 15:38:04.951940646 -0400
@@ -4,6 +4,8 @@
 PLUGIN_CLASS_NAME = QLinuxFbIntegrationPlugin
 load(qt_plugin)
 
+DEFINES += EGL_API_FB
+
 QT += core-private gui-private platformsupport-private
 
 SOURCES = main.cpp qlinuxfbintegration.cpp qlinuxfbscreen.cpp
diff -Nuar qt-everywhere-opensource-src-5.1.1-orig/qtbase/src/plugins/platforms/minimalegl/minimalegl.pro qt-everywhere-opensource-src-5.1.1/qtbase/src/plugins/platforms/minimalegl/minimalegl.pro
--- qt-everywhere-opensource-src-5.1.1-orig/qtbase/src/plugins/platforms/minimalegl/minimalegl.pro	2013-09-25 15:36:24.199942859 -0400
+++ qt-everywhere-opensource-src-5.1.1/qtbase/src/plugins/platforms/minimalegl/minimalegl.pro	2013-09-25 15:37:28.759941440 -0400
@@ -11,7 +11,7 @@
 #DEFINES += Q_OPENKODE
 
 #Avoid X11 header collision
-DEFINES += MESA_EGL_NO_X11_HEADERS
+DEFINES += MESA_EGL_NO_X11_HEADERS EGL_API_FB
 
 SOURCES =   main.cpp \
             qminimaleglintegration.cpp \

</snip>

Perhaps it would be best to patch the vivante headers to define EGL_API_FB if MESA_EGL_NO_X11_HEADERS is defined.

Hope that helps.

Regards
-- 
Andy Voltz
Timesys Corporation