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).

[meta-fsl-arm][RFC] qtbase: add xcb support for i.MX6

[Eric Bénard]

Signed-off-by: Eric Bénard <eric@eukrea.com>
---
 qt5-layer/recipes-qt/qt5/qtbase_5.0.2.bbappend |   24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/qt5-layer/recipes-qt/qt5/qtbase_5.0.2.bbappend b/qt5-layer/recipes-qt/qt5/qtbase_5.0.2.bbappend
index 33f0e8b..5553e27 100644
--- a/qt5-layer/recipes-qt/qt5/qtbase_5.0.2.bbappend
+++ b/qt5-layer/recipes-qt/qt5/qtbase_5.0.2.bbappend
@@ -1,11 +1,14 @@
+@@ -2,10 +2,12 @@
 # Copyright (C) 2013 Eric Bénard - Eukréa Electromatique
 
 HAS_X11 = "${@base_contains('DISTRO_FEATURES', 'x11', 1, 0, d)}"
 
-GL_DEPENDS_mx6 = "${@base_contains('DISTRO_FEATURES', 'x11', '', 'virtual/libgles2 virtual/egl', d)}"
-QT_GLFLAGS_mx6 = "${@base_contains('DISTRO_FEATURES', 'x11', '', '-opengl es2 -eglfs', d)}"
+GL_DEPENDS_mx6 = "virtual/libgles2 virtual/egl"
+QT_GLFLAGS_mx6 = "-opengl es2 -eglfs"
 QT_EXAMPLES_mx6 = "-make examples"
 QT_DEMOS_mx6 = "-make demos"
+XCB_DEPENDS_mx6 += "${@base_contains('DISTRO_FEATURES', 'x11', 'xcb-util-wm xcb-util-image xcb-util-keysyms dbus', '', d)}"
+QT_XCB_mx6 = "${@base_contains('DISTRO_FEATURES', 'x11', '-qt-xcb', '', d)}"
 
 GL_DEPENDS_mx5 = "${@base_contains('DISTRO_FEATURES', 'x11', '', 'virtual/libgles2 virtual/egl', d)}"
 QT_GLFLAGS_mx5 = "${@base_contains('DISTRO_FEATURES', 'x11', '', '-opengl es2 -eglfs', d)}"
@@ -47,6 +50,23 @@ EOF
 
 # copy the hook in the mkspecs directory OE is using
 cp ${S}/mkspecs/devices/linux-imx6-g++/qeglfshooks_imx6.cpp ${S}/mkspecs/linux-oe-g++/
+
+    else
+# adapt qmake.conf to our needs
+sed -i 's!load(qt_config)!!' ${S}/mkspecs/linux-oe-g++/qmake.conf
+cat >> ${S}/mkspecs/linux-oe-g++/qmake.conf <<EOF
+IMX6_CFLAGS             = -DLINUX=1
+QMAKE_LIBS_EGL         += -lEGL
+QMAKE_LIBS_OPENGL_ES2  += -lGLESv2 -lEGL -lGAL
+QMAKE_LIBS_OPENVG      += -lOpenVG -lEGL -lGAL
+QMAKE_CFLAGS_RELEASE   += \$\$IMX6_CFLAGS
+QMAKE_CXXFLAGS_RELEASE += \$\$IMX6_CFLAGS
+QMAKE_CFLAGS_DEBUG   += \$\$IMX6_CFLAGS
+QMAKE_CXXFLAGS_DEBUG += \$\$IMX6_CFLAGS
+QMAKE_CFLAGS_EGL += \$\$IMX6_CFLAGS
+load(qt_config)
+
+EOF
     fi
 }
 
-- 
1.7.10.4

Re: [meta-fsl-arm][RFC] qtbase: add xcb support for i.MX6

[Juha Vuolle]

Built fine on master. Can't say if it works as there is no example
apps or qmake to build my own (and I ended up applying the patch on
5.1.0 instead of the 5.0.2). But I did get out an image with the Qt
libs in place so I'll try tomorrow with my hand-built apps and cross
fingers for binary compatibility. The resulting libEGL.so.1 on the
sysroot/rootfs seems to be libEGL-wl.so i.e. wayland, is this OK?

On master-next there is some (maybe unrelated) error:
libEGL.so: undefined reference to `gcoOS_CreateDrawable'
when it is building
nitrogen6x-poky-linux-gnueabi/qt4-x11-free/4.8.5-r0/qt-everywhere-opensource-src-4.8.5


2013/8/26 Eric Bénard <eric@eukrea.com>:
> Signed-off-by: Eric Bénard <eric@eukrea.com>
> ---
>  qt5-layer/recipes-qt/qt5/qtbase_5.0.2.bbappend |   24 ++++++++++++++++++++++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/qt5-layer/recipes-qt/qt5/qtbase_5.0.2.bbappend b/qt5-layer/recipes-qt/qt5/qtbase_5.0.2.bbappend
> index 33f0e8b..5553e27 100644
> --- a/qt5-layer/recipes-qt/qt5/qtbase_5.0.2.bbappend
> +++ b/qt5-layer/recipes-qt/qt5/qtbase_5.0.2.bbappend
> @@ -1,11 +1,14 @@
> +@@ -2,10 +2,12 @@
>  # Copyright (C) 2013 Eric Bénard - Eukréa Electromatique
>
>  HAS_X11 = "${@base_contains('DISTRO_FEATURES', 'x11', 1, 0, d)}"
>
> -GL_DEPENDS_mx6 = "${@base_contains('DISTRO_FEATURES', 'x11', '', 'virtual/libgles2 virtual/egl', d)}"
> -QT_GLFLAGS_mx6 = "${@base_contains('DISTRO_FEATURES', 'x11', '', '-opengl es2 -eglfs', d)}"
> +GL_DEPENDS_mx6 = "virtual/libgles2 virtual/egl"
> +QT_GLFLAGS_mx6 = "-opengl es2 -eglfs"
>  QT_EXAMPLES_mx6 = "-make examples"
>  QT_DEMOS_mx6 = "-make demos"
> +XCB_DEPENDS_mx6 += "${@base_contains('DISTRO_FEATURES', 'x11', 'xcb-util-wm xcb-util-image xcb-util-keysyms dbus', '', d)}"
> +QT_XCB_mx6 = "${@base_contains('DISTRO_FEATURES', 'x11', '-qt-xcb', '', d)}"
>
>  GL_DEPENDS_mx5 = "${@base_contains('DISTRO_FEATURES', 'x11', '', 'virtual/libgles2 virtual/egl', d)}"
>  QT_GLFLAGS_mx5 = "${@base_contains('DISTRO_FEATURES', 'x11', '', '-opengl es2 -eglfs', d)}"
> @@ -47,6 +50,23 @@ EOF
>
>  # copy the hook in the mkspecs directory OE is using
>  cp ${S}/mkspecs/devices/linux-imx6-g++/qeglfshooks_imx6.cpp ${S}/mkspecs/linux-oe-g++/
> +
> +    else
> +# adapt qmake.conf to our needs
> +sed -i 's!load(qt_config)!!' ${S}/mkspecs/linux-oe-g++/qmake.conf
> +cat >> ${S}/mkspecs/linux-oe-g++/qmake.conf <<EOF
> +IMX6_CFLAGS             = -DLINUX=1
> +QMAKE_LIBS_EGL         += -lEGL
> +QMAKE_LIBS_OPENGL_ES2  += -lGLESv2 -lEGL -lGAL
> +QMAKE_LIBS_OPENVG      += -lOpenVG -lEGL -lGAL
> +QMAKE_CFLAGS_RELEASE   += \$\$IMX6_CFLAGS
> +QMAKE_CXXFLAGS_RELEASE += \$\$IMX6_CFLAGS
> +QMAKE_CFLAGS_DEBUG   += \$\$IMX6_CFLAGS
> +QMAKE_CXXFLAGS_DEBUG += \$\$IMX6_CFLAGS
> +QMAKE_CFLAGS_EGL += \$\$IMX6_CFLAGS
> +load(qt_config)
> +
> +EOF
>      fi
>  }
>
> --
> 1.7.10.4
>

Re: [meta-fsl-arm][RFC] qtbase: add xcb support for i.MX6

[Daiane Angolini]

On 08/28/2013 09:35 AM, Juha Vuolle wrote:
> Built fine on master. Can't say if it works as there is no example
> apps or qmake to build my own (and I ended up applying the patch on
> 5.1.0 instead of the 5.0.2). But I did get out an image with the Qt
> libs in place so I'll try tomorrow with my hand-built apps and cross
> fingers for binary compatibility. The resulting libEGL.so.1 on the
> sysroot/rootfs seems to be libEGL-wl.so i.e. wayland, is this OK?

wayland+x11  is the default choice when using poky.conf (the default 
distro from poky), so, if you have not changed DISTRO_FEATURES, it's the 
expected result.

If it's right, depends on your intention.


>
> On master-next there is some (maybe unrelated) error:
> libEGL.so: undefined reference to `gcoOS_CreateDrawable'
> when it is building
> nitrogen6x-poky-linux-gnueabi/qt4-x11-free/4.8.5-r0/qt-everywhere-opensource-src-4.8.5
>
>
> 2013/8/26 Eric Bénard <eric@eukrea.com>:
>> Signed-off-by: Eric Bénard <eric@eukrea.com>
>> ---
>>   qt5-layer/recipes-qt/qt5/qtbase_5.0.2.bbappend |   24 ++++++++++++++++++++++--
>>   1 file changed, 22 insertions(+), 2 deletions(-)
>>
>> diff --git a/qt5-layer/recipes-qt/qt5/qtbase_5.0.2.bbappend b/qt5-layer/recipes-qt/qt5/qtbase_5.0.2.bbappend
>> index 33f0e8b..5553e27 100644
>> --- a/qt5-layer/recipes-qt/qt5/qtbase_5.0.2.bbappend
>> +++ b/qt5-layer/recipes-qt/qt5/qtbase_5.0.2.bbappend
>> @@ -1,11 +1,14 @@
>> +@@ -2,10 +2,12 @@
>>   # Copyright (C) 2013 Eric Bénard - Eukréa Electromatique
>>
>>   HAS_X11 = "${@base_contains('DISTRO_FEATURES', 'x11', 1, 0, d)}"
>>
>> -GL_DEPENDS_mx6 = "${@base_contains('DISTRO_FEATURES', 'x11', '', 'virtual/libgles2 virtual/egl', d)}"
>> -QT_GLFLAGS_mx6 = "${@base_contains('DISTRO_FEATURES', 'x11', '', '-opengl es2 -eglfs', d)}"
>> +GL_DEPENDS_mx6 = "virtual/libgles2 virtual/egl"
>> +QT_GLFLAGS_mx6 = "-opengl es2 -eglfs"
>>   QT_EXAMPLES_mx6 = "-make examples"
>>   QT_DEMOS_mx6 = "-make demos"
>> +XCB_DEPENDS_mx6 += "${@base_contains('DISTRO_FEATURES', 'x11', 'xcb-util-wm xcb-util-image xcb-util-keysyms dbus', '', d)}"
>> +QT_XCB_mx6 = "${@base_contains('DISTRO_FEATURES', 'x11', '-qt-xcb', '', d)}"
>>
>>   GL_DEPENDS_mx5 = "${@base_contains('DISTRO_FEATURES', 'x11', '', 'virtual/libgles2 virtual/egl', d)}"
>>   QT_GLFLAGS_mx5 = "${@base_contains('DISTRO_FEATURES', 'x11', '', '-opengl es2 -eglfs', d)}"
>> @@ -47,6 +50,23 @@ EOF
>>
>>   # copy the hook in the mkspecs directory OE is using
>>   cp ${S}/mkspecs/devices/linux-imx6-g++/qeglfshooks_imx6.cpp ${S}/mkspecs/linux-oe-g++/
>> +
>> +    else
>> +# adapt qmake.conf to our needs
>> +sed -i 's!load(qt_config)!!' ${S}/mkspecs/linux-oe-g++/qmake.conf
>> +cat >> ${S}/mkspecs/linux-oe-g++/qmake.conf <<EOF
>> +IMX6_CFLAGS             = -DLINUX=1
>> +QMAKE_LIBS_EGL         += -lEGL
>> +QMAKE_LIBS_OPENGL_ES2  += -lGLESv2 -lEGL -lGAL
>> +QMAKE_LIBS_OPENVG      += -lOpenVG -lEGL -lGAL
>> +QMAKE_CFLAGS_RELEASE   += \$\$IMX6_CFLAGS
>> +QMAKE_CXXFLAGS_RELEASE += \$\$IMX6_CFLAGS
>> +QMAKE_CFLAGS_DEBUG   += \$\$IMX6_CFLAGS
>> +QMAKE_CXXFLAGS_DEBUG += \$\$IMX6_CFLAGS
>> +QMAKE_CFLAGS_EGL += \$\$IMX6_CFLAGS
>> +load(qt_config)
>> +
>> +EOF
>>       fi
>>   }
>>
>> --
>> 1.7.10.4
>>
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>


-- 
Daiane

Re: [meta-fsl-arm][RFC] qtbase: add xcb support for i.MX6

[Eric Bénard]

Le Wed, 28 Aug 2013 15:35:31 +0300,
Juha Vuolle <juvuolle@gmail.com> a écrit :

> Built fine on master. Can't say if it works as there is no example
> apps or qmake to build my own (and I ended up applying the patch on
> 5.1.0 instead of the 5.0.2). But I did get out an image with the Qt
> libs in place so I'll try tomorrow with my hand-built apps and cross
> fingers for binary compatibility. The resulting libEGL.so.1 on the
> sysroot/rootfs seems to be libEGL-wl.so i.e. wayland, is this OK?
> 
no :-(

Eric

Re: [meta-fsl-arm][RFC] qtbase: add xcb support for i.MX6

[Juha Vuolle]

2013/8/28 Eric Bénard <eric@eukrea.com>:
> Le Wed, 28 Aug 2013 15:35:31 +0300,
> Juha Vuolle <juvuolle@gmail.com> a écrit :
>
>> Built fine on master. Can't say if it works as there is no example
>> apps or qmake to build my own (and I ended up applying the patch on
>> 5.1.0 instead of the 5.0.2). But I did get out an image with the Qt
>> libs in place so I'll try tomorrow with my hand-built apps and cross
>> fingers for binary compatibility. The resulting libEGL.so.1 on the
>> sysroot/rootfs seems to be libEGL-wl.so i.e. wayland, is this OK?
>>
> no :-(

Ok removed the wayland from poky conf and got the libEGL-x11 in the image.

The Qt 5 widgets again work fine. Gles2 programs start but don't
render, just the title pane from the matchbox window manager. I guess
its still progress. Here is what it gives:

First start attempt:
root@nitrogen6x:~/qtapps/helloworld# DISPLAY=:0 ./helloworld
Qt Warning: Could not find a location of the system's Compose files.
Consider setting the QTCOMPOSE environment variable.
QXcbConnection: XCB error: 148 (Unknown), sequence: 148, resource id:
0, major code: 141 (Unknown), minor code: 20

Second and all later start attempts:
root@nitrogen6x:~/qtapps/helloworld# DISPLAY=:0 ./helloworld
Qt Warning: Could not find a location of the system's Compose files.
Consider setting the QTCOMPOSE environment variable.
QSGContext::initialize: depth buffer support missing, expect rendering errors
QSGContext::initialize: stencil buffer support missing, expect rendering errors
QOpenGLShaderProgram: could not create shader program
QOpenGLShader: could not create shader
QSGMaterialShader: Shader compilation failed:
...

Almost as if it would be using the wrong GL version and not getting on
with the shaders.
Some perhaps interesting picks from stracing the helloworld start:

open("/usr/lib/libGLESv2.so.2", O_RDONLY|O_CLOEXEC) = 3
...
open("/usr/lib/libEGL.so.1", O_RDONLY|O_CLOEXEC) = 3
...
open("/usr/lib/libGL.so.1", O_RDONLY|O_CLOEXEC) = 3
...
open("/usr/lib/libxcb-glx.so.0", O_RDONLY|O_CLOEXEC) = 4

Not sure where to look into next, any thoughts? Seems so close :-)
I wonder should it really open glx and libgl too.

Thanks,
Juha

> Eric

Re: [meta-fsl-arm][RFC] qtbase: add xcb support for i.MX6

[Eric Bénard]

Hi Juha,

Le Thu, 29 Aug 2013 11:07:18 +0300,
Juha Vuolle <juvuolle@gmail.com> a écrit :
> Not sure where to look into next, any thoughts? Seems so close :-)

may you please share your procedure to compile qt5 for xcb externaly
as you did initially ?
Maybe something is missing in my patch.

Eric

Re: [meta-fsl-arm][RFC] qtbase: add xcb support for i.MX6

[Juha Vuolle]

Hi Eric,

2013/8/29 Eric Bénard <eric@eukrea.com>:
> Hi Juha,
>
> Le Thu, 29 Aug 2013 11:07:18 +0300,
> Juha Vuolle <juvuolle@gmail.com> a écrit :
>> Not sure where to look into next, any thoughts? Seems so close :-)
>
> may you please share your procedure to compile qt5 for xcb externaly
> as you did initially ?
> Maybe something is missing in my patch.

I mostly did as in the
https://community.freescale.com/docs/DOC-94066

I suppose the interesting part is the configure line which for me was:

./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/j/yocto/fsl-master/build/tmp/sysroots/i686-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-
-sysroot /home/j/yocto/fsl-master/build/tmp/sysroots/nitrogen6x
-prefix /home/j/nx6-xcb-inst

In Qt there is actually some .pro -file checks for xcb qpa
 contains(QT_CONFIG, opengles2) {
     DEFINES += XCB_USE_EGL
        LIBS += -lEGL
        HEADERS += qxcbeglsurface.h
} else{
     DEFINES += XCB_USE_GLX
        HEADERS += qglxintegration.h
        SOURCES += qglxintegration.cpp
}

Not sure if they could play some role here. Hmm..





> Eric

Re: [meta-fsl-arm][RFC] qtbase: add xcb support for i.MX6

[Juha Vuolle]

Against that image with handbuilt Qt XCB QPA starting egl/gles2 won't
start with the same reason as few tries ago:

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

I forced Qt to return the "Visual ID" 33 and indeed the application started.

The application title is there again but no other visual output.
Interestingly the application responds to click events etc. i.e. it is
there, just as transparent.

In xorg logs there are

[3336165.957] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[3336165.957] (II) VIVANTE(0): using default device
[3336165.957] (II) VIVANTE(0): Creating default Display subsection in
Screen section
        "Default Screen Section" for depth/fbbpp 16/16
[3336165.957] (==) VIVANTE(0): Depth 16, (==) framebuffer bpp 16
[3336165.957] (==) VIVANTE(0): RGB weight 565
[3336165.957] (==) VIVANTE(0): Default visual is TrueColor

But I don't know how to tamper those values.

"Almost works"



2013/8/29 Juha Vuolle <juvuolle@gmail.com>:
> Hi Eric,
>
> 2013/8/29 Eric Bénard <eric@eukrea.com>:
>> Hi Juha,
>>
>> Le Thu, 29 Aug 2013 11:07:18 +0300,
>> Juha Vuolle <juvuolle@gmail.com> a écrit :
>>> Not sure where to look into next, any thoughts? Seems so close :-)
>>
>> may you please share your procedure to compile qt5 for xcb externaly
>> as you did initially ?
>> Maybe something is missing in my patch.
>
> I mostly did as in the
> https://community.freescale.com/docs/DOC-94066
>
> I suppose the interesting part is the configure line which for me was:
>
> ./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/j/yocto/fsl-master/build/tmp/sysroots/i686-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-
> -sysroot /home/j/yocto/fsl-master/build/tmp/sysroots/nitrogen6x
> -prefix /home/j/nx6-xcb-inst
>
> In Qt there is actually some .pro -file checks for xcb qpa
>  contains(QT_CONFIG, opengles2) {
>      DEFINES += XCB_USE_EGL
>         LIBS += -lEGL
>         HEADERS += qxcbeglsurface.h
> } else{
>      DEFINES += XCB_USE_GLX
>         HEADERS += qglxintegration.h
>         SOURCES += qglxintegration.cpp
> }
>
> Not sure if they could play some role here. Hmm..
>
>
>
>
>
>> Eric

Re: [meta-fsl-arm][RFC] qtbase: add xcb support for i.MX6

[Juha Vuolle]

(Just a little bit more monologing, I could only get the X working
with RGB565 and RGB888 (via uboot options), neither which work with
the EGL 4 bit colour depths. )

2013/8/29 Juha Vuolle <juvuolle@gmail.com>:
> Against that image with handbuilt Qt XCB QPA starting egl/gles2 won't
> start with the same reason as few tries ago:
>
> 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
>
> I forced Qt to return the "Visual ID" 33 and indeed the application started.
>
> The application title is there again but no other visual output.
> Interestingly the application responds to click events etc. i.e. it is
> there, just as transparent.
>
> In xorg logs there are
>
> [3336165.957] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
> [3336165.957] (II) VIVANTE(0): using default device
> [3336165.957] (II) VIVANTE(0): Creating default Display subsection in
> Screen section
>         "Default Screen Section" for depth/fbbpp 16/16
> [3336165.957] (==) VIVANTE(0): Depth 16, (==) framebuffer bpp 16
> [3336165.957] (==) VIVANTE(0): RGB weight 565
> [3336165.957] (==) VIVANTE(0): Default visual is TrueColor
>
> But I don't know how to tamper those values.
>
> "Almost works"
>
>
>
> 2013/8/29 Juha Vuolle <juvuolle@gmail.com>:
>> Hi Eric,
>>
>> 2013/8/29 Eric Bénard <eric@eukrea.com>:
>>> Hi Juha,
>>>
>>> Le Thu, 29 Aug 2013 11:07:18 +0300,
>>> Juha Vuolle <juvuolle@gmail.com> a écrit :
>>>> Not sure where to look into next, any thoughts? Seems so close :-)
>>>
>>> may you please share your procedure to compile qt5 for xcb externaly
>>> as you did initially ?
>>> Maybe something is missing in my patch.
>>
>> I mostly did as in the
>> https://community.freescale.com/docs/DOC-94066
>>
>> I suppose the interesting part is the configure line which for me was:
>>
>> ./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/j/yocto/fsl-master/build/tmp/sysroots/i686-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-
>> -sysroot /home/j/yocto/fsl-master/build/tmp/sysroots/nitrogen6x
>> -prefix /home/j/nx6-xcb-inst
>>
>> In Qt there is actually some .pro -file checks for xcb qpa
>>  contains(QT_CONFIG, opengles2) {
>>      DEFINES += XCB_USE_EGL
>>         LIBS += -lEGL
>>         HEADERS += qxcbeglsurface.h
>> } else{
>>      DEFINES += XCB_USE_GLX
>>         HEADERS += qglxintegration.h
>>         SOURCES += qglxintegration.cpp
>> }
>>
>> Not sure if they could play some role here. Hmm..
>>
>>
>>
>>
>>
>>> Eric

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