Patchwork [meta-fsl-arm,v4,0/9] iMX6Q BSP 1.1.0 upgrade

login
register
mail settings
Submitter Thomas Senyk
Date Feb. 13, 2013, 5:44 p.m.
Message ID <5136010.02L8BgeO9t@rudolf>
Download mbox | patch
Permalink /patch/44581/
State Not Applicable
Delegated to: Otavio Salvador
Headers show

Comments

Thomas Senyk - Feb. 13, 2013, 5:44 p.m.
On Tue, February 12, 2013 19:59:45 Otavio Salvador wrote:
> On Tue, Feb 12, 2013 at 7:58 PM, Otavio Salvador
> 
> <otavio@ossystems.com.br> wrote:
> > Hello,
> > 
> > This patch series upgrades the iMX6Q BSP to 1.1.0; it also try to fix
> > the DRI support for it.
> > 
> > Please give it a try as this is a huge upgrade and we might have
> > regressions and pending issues still unkown. This series depends on a
> > cuple of patches I sent to OpenEmbeeded-Core mailing list for
> > xserver-xorg and mesa, please apply them before playing with this
> > series.
> 
> I've created a bundle for this series:
> 
> OE-Core/Poky patches:
> 
> http://patches.openembedded.org/bundle/otavio/oe-core-dri-patches/
> 
> Meta-FSL-ARM patches:
> 
> http://patches.openembedded.org/bundle/otavio/bsp-1.1.0-update/

Nice thanks for the bundle.

Most of my issues got fixed in v4! good job! :)

The left overs:

1. After applied the upstream patches I got:

ERROR: No recipes available for:
  /home/tsenyk/projects/oe-yocto/fsl-community-bsp/sources/meta-fsl-
arm/recipes-graphics/mesa/mesa-dri_9.0.1.bbappend
ERROR: Command execution failed: Exited with 1

... their is probably just some patch missing or something .. I just deleted 
it and it was good ;)
I don't care that much about this one :) (I just wanted to report this)


2. The deploy and symlinks in the image look very good now:
lrwxrwxrwx 1 root root       12 Feb 13 17:49 libEGL.so -> libEGL-fb.so
-rw-r--r-- 1 root root   803326 Feb 13 17:33 libGAL-fb.so
lrwxrwxrwx 1 root root       12 Feb 13 17:49 libGAL.so -> libGAL-fb.so

nice!

Also the deploy in the sysroot looks good (only libEGL-fb.so and non of the 
others are present) .... so the file-split is working, but there are no 
symblinks.

I tried to fix this by creating symlinks manually in do_install:




I have absolutely NO idea if this is in anyway the right thing to do!
I had errors, bitbake complaining about .so files not part of the -dev package 
... but for some reason I don't get those anymore after I removed all of my 
other changes and just kept the 'ln -s'-lines ... so:
If you think it the right way, just take it and submit v5 and/or commit it 
after v4 is merged.


3. I still got the following errors when starting any Qt5 application:

vertex shader compilation error: 
fragment shader compilation error: 
program link error: No vertex shader attached.

My setup: I do a image of my own, the main(!) contents of the image is:
inherit core-image
IMAGE_INSTALL += "libpng tslib libudev gpu-viv-bin-mx6q"
IMAGE_FEATURES += "ssh-server-openssh tools-debug"
DEPENDS = "gpu-viv-bin-mx6q libpng"

Then I compile Qt5 git from outside of yocto, my configure line:
../qt5/configure -opensource -confirm-license -make libs -device imx6 -device-
option CROSS_COMPILE=~/projects/oe-yocto/fsl-community-bsp/imx6-
build-10/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-
gnueabi/arm-poky-linux-gnueabi- -sysroot ~/projects/oe-yocto/fsl-community-
bsp/imx6-build-10/tmp/sysroots/imx6qsabrelite -prefix /opt/pelagicore/Qt5.0-
yocto-imx6-10 -opengl es2 -no-pch -v



This way I've compiled Qt5 against yocto builds for a while now.
The only related problem I had in the past was the '#define mediump vs. 
heighp' which I could solve a patching Qt.
This isn't helping anymore ... but I'm still investigating.

Greets
Thomas



> 
> --
> Otavio Salvador                             O.S. Systems
> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
Otavio Salvador - Feb. 13, 2013, 9:11 p.m.
On Wed, Feb 13, 2013 at 3:44 PM, Thomas Senyk
<thomas.senyk@pelagicore.com> wrote:
>
> On Tue, February 12, 2013 19:59:45 Otavio Salvador wrote:
> > On Tue, Feb 12, 2013 at 7:58 PM, Otavio Salvador
> >
> > <otavio@ossystems.com.br> wrote:
> > > Hello,
> > >
> > > This patch series upgrades the iMX6Q BSP to 1.1.0; it also try to fix
> > > the DRI support for it.
> > >
> > > Please give it a try as this is a huge upgrade and we might have
> > > regressions and pending issues still unkown. This series depends on a
> > > cuple of patches I sent to OpenEmbeeded-Core mailing list for
> > > xserver-xorg and mesa, please apply them before playing with this
> > > series.
> >
> > I've created a bundle for this series:
> >
> > OE-Core/Poky patches:
> >
> > http://patches.openembedded.org/bundle/otavio/oe-core-dri-patches/
> >
> > Meta-FSL-ARM patches:
> >
> > http://patches.openembedded.org/bundle/otavio/bsp-1.1.0-update/
>
> Nice thanks for the bundle.
>
> Most of my issues got fixed in v4! good job! :)
>
> The left overs:
>
> 1. After applied the upstream patches I got:
>
> ERROR: No recipes available for:
>   /home/tsenyk/projects/oe-yocto/fsl-community-bsp/sources/meta-fsl-
> arm/recipes-graphics/mesa/mesa-dri_9.0.1.bbappend
> ERROR: Command execution failed: Exited with 1
>
> ... their is probably just some patch missing or something .. I just deleted
> it and it was good ;)
> I don't care that much about this one :) (I just wanted to report this)


Yes. I will check if we need to keep the bbappend or it is safe to drop it.

>
> 2. The deploy and symlinks in the image look very good now:
> lrwxrwxrwx 1 root root       12 Feb 13 17:49 libEGL.so -> libEGL-fb.so
> -rw-r--r-- 1 root root   803326 Feb 13 17:33 libGAL-fb.so
> lrwxrwxrwx 1 root root       12 Feb 13 17:49 libGAL.so -> libGAL-fb.so
>
> nice!


Not that nice; in fact we shoudln't have the symlinks or X11 things
might end linking against framebuffer libraries by mistake.

>
> Also the deploy in the sysroot looks good (only libEGL-fb.so and non of the
> others are present) .... so the file-split is working, but there are no
> symblinks.
>
> I tried to fix this by creating symlinks manually in do_install:
>
> diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc b/recipes-
> graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> index 9818c72..af6dc82 100644
> --- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> +++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> @@ -91,6 +91,20 @@ do_install () {
>         ${D}${libdir}/libGAL.so \
>         ${D}${libdir}/libVIVANTE.so
>
> +    if [ "${KEEP_XLIBS}" = "yes" ]; then
> +        ln -s ${D}${libdir}/libEGL-x11.so ${D}${libdir}/libEGL.so
> +        ln -s ${D}${libdir}/libGAL-x11.so ${D}${libdir}/libGAL.so
> +        ln -s ${D}${libdir}/libVIVANTE-x11.so ${D}${libdir}/libVIVANTE.so
> +    elif [ "${KEEP_DFBLIBS}" = "yes" ]; then
> +        ln -s ${D}${libdir}/libEGL-dfb.so ${D}${libdir}/libEGL.so
> +        ln -s ${D}${libdir}/libGAL-dfb.so ${D}${libdir}/libGAL.so
> +        ln -s ${D}${libdir}/libVIVANTE-dfb.so ${D}${libdir}/libVIVANTE.so
> +    else
> +        ln -s libEGL-fb.so ${D}${libdir}/libEGL.so
> +        ln -s libGAL-fb.so ${D}${libdir}/libGAL.so
> +        ln -s libVIVANTE-fb.so ${D}${libdir}/libVIVANTE.so
> +    fi
> +
>      find ${D}${libdir} -type f -exec chmod 644 {} \;
>      find ${D}${includedir} -type f -exec chmod 644 {} \;
>  }

Read obove...

> I have absolutely NO idea if this is in anyway the right thing to do!
> I had errors, bitbake complaining about .so files not part of the -dev package
> ... but for some reason I don't get those anymore after I removed all of my
> other changes and just kept the 'ln -s'-lines ... so:
> If you think it the right way, just take it and submit v5 and/or commit it
> after v4 is merged.

No; it is not.

> 3. I still got the following errors when starting any Qt5 application:
>
> vertex shader compilation error:
> fragment shader compilation error:
> program link error: No vertex shader attached.

> My setup: I do a image of my own, the main(!) contents of the image is:
> inherit core-image
> IMAGE_INSTALL += "libpng tslib libudev gpu-viv-bin-mx6q"
> IMAGE_FEATURES += "ssh-server-openssh tools-debug"
> DEPENDS = "gpu-viv-bin-mx6q libpng"
>
> Then I compile Qt5 git from outside of yocto, my configure line:
> ../qt5/configure -opensource -confirm-license -make libs -device imx6 -device-
> option CROSS_COMPILE=~/projects/oe-yocto/fsl-community-bsp/imx6-
> build-10/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-
> gnueabi/arm-poky-linux-gnueabi- -sysroot ~/projects/oe-yocto/fsl-community-
> bsp/imx6-build-10/tmp/sysroots/imx6qsabrelite -prefix /opt/pelagicore/Qt5.0-
> yocto-imx6-10 -opengl es2 -no-pch -v

This might be the cause of the problem. We need to build it using
Yocto toolchain so it links with proper library names or we raise the
errors we need to deal with. Can you give it a try?

> This way I've compiled Qt5 against yocto builds for a while now.
> The only related problem I had in the past was the '#define mediump vs.
> heighp' which I could solve a patching Qt.
> This isn't helping anymore ... but I'm still investigating.

Please check if you can build against the toolchain. To generate the
toolchain for your image do:

bitbake <image> -c populate_sdk

I hope it works :)

--
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Thomas Senyk - Feb. 15, 2013, 5:10 p.m.
On Wed, February 13, 2013 19:11:59 Otavio Salvador wrote:
> On Wed, Feb 13, 2013 at 3:44 PM, Thomas Senyk
> 
> <thomas.senyk@pelagicore.com> wrote:
> > On Tue, February 12, 2013 19:59:45 Otavio Salvador wrote:
> > > On Tue, Feb 12, 2013 at 7:58 PM, Otavio Salvador
> > > 
> > > <otavio@ossystems.com.br> wrote:
> > > > Hello,
> > > > 
> > > > This patch series upgrades the iMX6Q BSP to 1.1.0; it also try to fix
> > > > the DRI support for it.
> > > > 
> > > > Please give it a try as this is a huge upgrade and we might have
> > > > regressions and pending issues still unkown. This series depends on a
> > > > cuple of patches I sent to OpenEmbeeded-Core mailing list for
> > > > xserver-xorg and mesa, please apply them before playing with this
> > > > series.
> > > 
> > > I've created a bundle for this series:
> > > 
> > > OE-Core/Poky patches:
> > > 
> > > http://patches.openembedded.org/bundle/otavio/oe-core-dri-patches/
> > > 
> > > Meta-FSL-ARM patches:
> > > 
> > > http://patches.openembedded.org/bundle/otavio/bsp-1.1.0-update/
> > 
> > Nice thanks for the bundle.
> > 
> > Most of my issues got fixed in v4! good job! :)
> > 
> > The left overs:
> > 
> > 1. After applied the upstream patches I got:
> > 
> > ERROR: No recipes available for:
> >   /home/tsenyk/projects/oe-yocto/fsl-community-bsp/sources/meta-fsl-
> > 
> > arm/recipes-graphics/mesa/mesa-dri_9.0.1.bbappend
> > ERROR: Command execution failed: Exited with 1
> > 
> > ... their is probably just some patch missing or something .. I just
> > deleted it and it was good ;)
> > I don't care that much about this one :) (I just wanted to report this)
> 
> Yes. I will check if we need to keep the bbappend or it is safe to drop it.
> 
> > 2. The deploy and symlinks in the image look very good now:
> > lrwxrwxrwx 1 root root       12 Feb 13 17:49 libEGL.so -> libEGL-fb.so
> > -rw-r--r-- 1 root root   803326 Feb 13 17:33 libGAL-fb.so
> > lrwxrwxrwx 1 root root       12 Feb 13 17:49 libGAL.so -> libGAL-fb.so
> > 
> > nice!
> 
> Not that nice; in fact we shoudln't have the symlinks or X11 things
> might end linking against framebuffer libraries by mistake.

This sounds rather unconventional ;)
I've never seen any platform were libEGL-something.so is the EGL target to 
link to.

In general one should define the default flavor of the GPU-driver
   ... which is setting the libEGL.so symblink.

In relation to the "link by mistake"-argument:
a) You have a fb-only setup: there will be no x11-things.
b) You have a x11 setup: the default is libEGL-x11.so and theirfor no problem.
    ... if on a x11 setup a application want to explicitly link against 
libEGL-fb.so it can do anyway, but at least the default on is set.
c) You have a dfb setup: the default link goes to libEGL-dfb.so

How do applications within the yocto build link against libEGL?
There are generally no .pc file for GPU-drivers
   ... are there internal variables to reference?

> 
> > Also the deploy in the sysroot looks good (only libEGL-fb.so and non of
> > the
> > others are present) .... so the file-split is working, but there are no
> > symblinks.
> > 
> > I tried to fix this by creating symlinks manually in do_install:
> > 
> > diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> > b/recipes- graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> > index 9818c72..af6dc82 100644
> > --- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> > +++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> > @@ -91,6 +91,20 @@ do_install () {
> > 
> >         ${D}${libdir}/libGAL.so \
> >         ${D}${libdir}/libVIVANTE.so
> > 
> > +    if [ "${KEEP_XLIBS}" = "yes" ]; then
> > +        ln -s ${D}${libdir}/libEGL-x11.so ${D}${libdir}/libEGL.so
> > +        ln -s ${D}${libdir}/libGAL-x11.so ${D}${libdir}/libGAL.so
> > +        ln -s ${D}${libdir}/libVIVANTE-x11.so ${D}${libdir}/libVIVANTE.so
> > +    elif [ "${KEEP_DFBLIBS}" = "yes" ]; then
> > +        ln -s ${D}${libdir}/libEGL-dfb.so ${D}${libdir}/libEGL.so
> > +        ln -s ${D}${libdir}/libGAL-dfb.so ${D}${libdir}/libGAL.so
> > +        ln -s ${D}${libdir}/libVIVANTE-dfb.so ${D}${libdir}/libVIVANTE.so
> > +    else
> > +        ln -s libEGL-fb.so ${D}${libdir}/libEGL.so
> > +        ln -s libGAL-fb.so ${D}${libdir}/libGAL.so
> > +        ln -s libVIVANTE-fb.so ${D}${libdir}/libVIVANTE.so
> > +    fi
> > +
> > 
> >      find ${D}${libdir} -type f -exec chmod 644 {} \;
> >      find ${D}${includedir} -type f -exec chmod 644 {} \;
> >  
> >  }
> 
> Read obove...
> 
> > I have absolutely NO idea if this is in anyway the right thing to do!
> > I had errors, bitbake complaining about .so files not part of the -dev
> > package ... but for some reason I don't get those anymore after I removed
> > all of my other changes and just kept the 'ln -s'-lines ... so:
> > If you think it the right way, just take it and submit v5 and/or commit it
> > after v4 is merged.
> 
> No; it is not.

Because of the above or because the way I set the symlinks is wrong?

> 
> > 3. I still got the following errors when starting any Qt5 application:
> > 
> > vertex shader compilation error:
> > fragment shader compilation error:
> > program link error: No vertex shader attached.
> > 
> > My setup: I do a image of my own, the main(!) contents of the image is:
> > inherit core-image
> > IMAGE_INSTALL += "libpng tslib libudev gpu-viv-bin-mx6q"
> > IMAGE_FEATURES += "ssh-server-openssh tools-debug"
> > DEPENDS = "gpu-viv-bin-mx6q libpng"
> > 
> > Then I compile Qt5 git from outside of yocto, my configure line:
> > ../qt5/configure -opensource -confirm-license -make libs -device imx6
> > -device- option CROSS_COMPILE=~/projects/oe-yocto/fsl-community-bsp/imx6-
> > build-10/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-
> > gnueabi/arm-poky-linux-gnueabi- -sysroot
> > ~/projects/oe-yocto/fsl-community-
> > bsp/imx6-build-10/tmp/sysroots/imx6qsabrelite -prefix
> > /opt/pelagicore/Qt5.0- yocto-imx6-10 -opengl es2 -no-pch -v
> 
> This might be the cause of the problem. We need to build it using
> Yocto toolchain so it links with proper library names or we raise the
> errors we need to deal with. Can you give it a try?
> 
> > This way I've compiled Qt5 against yocto builds for a while now.
> > The only related problem I had in the past was the '#define mediump vs.
> > heighp' which I could solve a patching Qt.
> > This isn't helping anymore ... but I'm still investigating.
> 
> Please check if you can build against the toolchain. To generate the
> toolchain for your image do:
> 
> bitbake <image> -c populate_sdk

I already use the yocto toolchain and sysroot ... I think? ;)
I'll checkout what does '-c populate_sdk' as soon as I find some time (I guess 
week after next week)

> 
> I hope it works :)

Me too ;)

> 
> --
> Otavio Salvador                             O.S. Systems
> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
Tomas Frydrych - Feb. 15, 2013, 6:08 p.m.
On 15/02/13 17:10, Thomas Senyk wrote:
>> Not that nice; in fact we shoudln't have the symlinks or X11 things
>> might end linking against framebuffer libraries by mistake.
> 
> This sounds rather unconventional ;)
> I've never seen any platform were libEGL-something.so is the EGL target to 
> link to.
> 
> In general one should define the default flavor of the GPU-driver
>    ... which is setting the libEGL.so symblink.
> 
> In relation to the "link by mistake"-argument:
> a) You have a fb-only setup: there will be no x11-things.
> b) You have a x11 setup: the default is libEGL-x11.so and theirfor no problem.
>     ... if on a x11 setup a application want to explicitly link against 
> libEGL-fb.so it can do anyway, but at least the default on is set.
> c) You have a dfb setup: the default link goes to libEGL-dfb.so
> 

Agreed; it generally makes little sense to have multiple versions of EGL
available at run time, and normal applications will be looking for
libEGL.so anyway.

> How do applications within the yocto build link against libEGL?
> There are generally no .pc file for GPU-drivers
>    ... are there internal variables to reference?

There is nothing Yocto specific here, how the application looks for EGL
is up to the application author. My recommendation would be if the
upstream driver does not provide a .pc file, to provide one as part of
the Yocto packaging, it is trivial to create one, and libraries such as
cogl will use it if they find it, and it saves much pain all around,
because other home grown ways of checking libEGL availability are
usually not cross-compilation friendly.

Tomas
Otavio Salvador - Feb. 15, 2013, 6:23 p.m.
On Fri, Feb 15, 2013 at 3:10 PM, Thomas Senyk
<thomas.senyk@pelagicore.com> wrote:
> On Wed, February 13, 2013 19:11:59 Otavio Salvador wrote:
>> On Wed, Feb 13, 2013 at 3:44 PM, Thomas Senyk
>>
>> <thomas.senyk@pelagicore.com> wrote:
>> > On Tue, February 12, 2013 19:59:45 Otavio Salvador wrote:
>> > > On Tue, Feb 12, 2013 at 7:58 PM, Otavio Salvador
>> > >
>> > > <otavio@ossystems.com.br> wrote:
>> > > > Hello,
>> > > >
>> > > > This patch series upgrades the iMX6Q BSP to 1.1.0; it also try to fix
>> > > > the DRI support for it.
>> > > >
>> > > > Please give it a try as this is a huge upgrade and we might have
>> > > > regressions and pending issues still unkown. This series depends on a
>> > > > cuple of patches I sent to OpenEmbeeded-Core mailing list for
>> > > > xserver-xorg and mesa, please apply them before playing with this
>> > > > series.
>> > >
>> > > I've created a bundle for this series:
>> > >
>> > > OE-Core/Poky patches:
>> > >
>> > > http://patches.openembedded.org/bundle/otavio/oe-core-dri-patches/
>> > >
>> > > Meta-FSL-ARM patches:
>> > >
>> > > http://patches.openembedded.org/bundle/otavio/bsp-1.1.0-update/
>> >
>> > Nice thanks for the bundle.
>> >
>> > Most of my issues got fixed in v4! good job! :)
>> >
>> > The left overs:
>> >
>> > 1. After applied the upstream patches I got:
>> >
>> > ERROR: No recipes available for:
>> >   /home/tsenyk/projects/oe-yocto/fsl-community-bsp/sources/meta-fsl-
>> >
>> > arm/recipes-graphics/mesa/mesa-dri_9.0.1.bbappend
>> > ERROR: Command execution failed: Exited with 1
>> >
>> > ... their is probably just some patch missing or something .. I just
>> > deleted it and it was good ;)
>> > I don't care that much about this one :) (I just wanted to report this)
>>
>> Yes. I will check if we need to keep the bbappend or it is safe to drop it.
>>
>> > 2. The deploy and symlinks in the image look very good now:
>> > lrwxrwxrwx 1 root root       12 Feb 13 17:49 libEGL.so -> libEGL-fb.so
>> > -rw-r--r-- 1 root root   803326 Feb 13 17:33 libGAL-fb.so
>> > lrwxrwxrwx 1 root root       12 Feb 13 17:49 libGAL.so -> libGAL-fb.so
>> >
>> > nice!
>>
>> Not that nice; in fact we shoudln't have the symlinks or X11 things
>> might end linking against framebuffer libraries by mistake.
>
> This sounds rather unconventional ;)
> I've never seen any platform were libEGL-something.so is the EGL target to
> link to.
>
> In general one should define the default flavor of the GPU-driver
>    ... which is setting the libEGL.so symblink.

For this the alternatives system might be a solution for the target.
The problem is what to do during the build of applications. Think in
such case:

 - gpu-viv is build
 - app-fb is build
 - app-x11 is build

If we have libEGL.so how we manage to link each to the right one?

> In relation to the "link by mistake"-argument:
> a) You have a fb-only setup: there will be no x11-things.
> b) You have a x11 setup: the default is libEGL-x11.so and theirfor no problem.
>     ... if on a x11 setup a application want to explicitly link against
> libEGL-fb.so it can do anyway, but at least the default on is set.
> c) You have a dfb setup: the default link goes to libEGL-dfb.so

This works well for runtime and I fully agree.

I am concerned about how we will manage it at *build* time. Bear on
mind that app-fb and app-x11 can be build in parallel so change the
link during the build is not going to work.

> How do applications within the yocto build link against libEGL?
> There are generally no .pc file for GPU-drivers
>    ... are there internal variables to reference?

You may need to patch the application to link to one or another. Or
play with LDFLAGS...

>> > Also the deploy in the sysroot looks good (only libEGL-fb.so and non of
>> > the
>> > others are present) .... so the file-split is working, but there are no
>> > symblinks.
>> >
>> > I tried to fix this by creating symlinks manually in do_install:
>> >
>> > diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
>> > b/recipes- graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
>> > index 9818c72..af6dc82 100644
>> > --- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
>> > +++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
>> > @@ -91,6 +91,20 @@ do_install () {
>> >
>> >         ${D}${libdir}/libGAL.so \
>> >         ${D}${libdir}/libVIVANTE.so
>> >
>> > +    if [ "${KEEP_XLIBS}" = "yes" ]; then
>> > +        ln -s ${D}${libdir}/libEGL-x11.so ${D}${libdir}/libEGL.so
>> > +        ln -s ${D}${libdir}/libGAL-x11.so ${D}${libdir}/libGAL.so
>> > +        ln -s ${D}${libdir}/libVIVANTE-x11.so ${D}${libdir}/libVIVANTE.so
>> > +    elif [ "${KEEP_DFBLIBS}" = "yes" ]; then
>> > +        ln -s ${D}${libdir}/libEGL-dfb.so ${D}${libdir}/libEGL.so
>> > +        ln -s ${D}${libdir}/libGAL-dfb.so ${D}${libdir}/libGAL.so
>> > +        ln -s ${D}${libdir}/libVIVANTE-dfb.so ${D}${libdir}/libVIVANTE.so
>> > +    else
>> > +        ln -s libEGL-fb.so ${D}${libdir}/libEGL.so
>> > +        ln -s libGAL-fb.so ${D}${libdir}/libGAL.so
>> > +        ln -s libVIVANTE-fb.so ${D}${libdir}/libVIVANTE.so
>> > +    fi
>> > +
>> >
>> >      find ${D}${libdir} -type f -exec chmod 644 {} \;
>> >      find ${D}${includedir} -type f -exec chmod 644 {} \;
>> >
>> >  }
>>
>> Read obove...
>>
>> > I have absolutely NO idea if this is in anyway the right thing to do!
>> > I had errors, bitbake complaining about .so files not part of the -dev
>> > package ... but for some reason I don't get those anymore after I removed
>> > all of my other changes and just kept the 'ln -s'-lines ... so:
>> > If you think it the right way, just take it and submit v5 and/or commit it
>> > after v4 is merged.
>>
>> No; it is not.
>
> Because of the above or because the way I set the symlinks is wrong?

Your code is right the problem is the concurrent build as explained above.

>> > 3. I still got the following errors when starting any Qt5 application:
>> >
>> > vertex shader compilation error:
>> > fragment shader compilation error:
>> > program link error: No vertex shader attached.
>> >
>> > My setup: I do a image of my own, the main(!) contents of the image is:
>> > inherit core-image
>> > IMAGE_INSTALL += "libpng tslib libudev gpu-viv-bin-mx6q"
>> > IMAGE_FEATURES += "ssh-server-openssh tools-debug"
>> > DEPENDS = "gpu-viv-bin-mx6q libpng"
>> >
>> > Then I compile Qt5 git from outside of yocto, my configure line:
>> > ../qt5/configure -opensource -confirm-license -make libs -device imx6
>> > -device- option CROSS_COMPILE=~/projects/oe-yocto/fsl-community-bsp/imx6-
>> > build-10/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-
>> > gnueabi/arm-poky-linux-gnueabi- -sysroot
>> > ~/projects/oe-yocto/fsl-community-
>> > bsp/imx6-build-10/tmp/sysroots/imx6qsabrelite -prefix
>> > /opt/pelagicore/Qt5.0- yocto-imx6-10 -opengl es2 -no-pch -v
>>
>> This might be the cause of the problem. We need to build it using
>> Yocto toolchain so it links with proper library names or we raise the
>> errors we need to deal with. Can you give it a try?
>>
>> > This way I've compiled Qt5 against yocto builds for a while now.
>> > The only related problem I had in the past was the '#define mediump vs.
>> > heighp' which I could solve a patching Qt.
>> > This isn't helping anymore ... but I'm still investigating.
>>
>> Please check if you can build against the toolchain. To generate the
>> toolchain for your image do:
>>
>> bitbake <image> -c populate_sdk
>
> I already use the yocto toolchain and sysroot ... I think? ;)
> I'll checkout what does '-c populate_sdk' as soon as I find some time (I guess
> week after next week)

Right; if I find the need time I will try to play with it as well.

Regards,
Otavio Salvador - Feb. 15, 2013, 6:25 p.m.
On Fri, Feb 15, 2013 at 4:08 PM, Tomas Frydrych
<tf+lists.yocto@r-finger.com> wrote:
> On 15/02/13 17:10, Thomas Senyk wrote:
>>> Not that nice; in fact we shoudln't have the symlinks or X11 things
>>> might end linking against framebuffer libraries by mistake.
>>
>> This sounds rather unconventional ;)
>> I've never seen any platform were libEGL-something.so is the EGL target to
>> link to.
>>
>> In general one should define the default flavor of the GPU-driver
>>    ... which is setting the libEGL.so symblink.
>>
>> In relation to the "link by mistake"-argument:
>> a) You have a fb-only setup: there will be no x11-things.
>> b) You have a x11 setup: the default is libEGL-x11.so and theirfor no problem.
>>     ... if on a x11 setup a application want to explicitly link against
>> libEGL-fb.so it can do anyway, but at least the default on is set.
>> c) You have a dfb setup: the default link goes to libEGL-dfb.so
>>
>
> Agreed; it generally makes little sense to have multiple versions of EGL
> available at run time, and normal applications will be looking for
> libEGL.so anyway.

In theory I agree as well; what worries me is how to build one app
against libEGL-fb and another against libEGL-x11 in parallel.

>> How do applications within the yocto build link against libEGL?
>> There are generally no .pc file for GPU-drivers
>>    ... are there internal variables to reference?
>
> There is nothing Yocto specific here, how the application looks for EGL
> is up to the application author. My recommendation would be if the
> upstream driver does not provide a .pc file, to provide one as part of
> the Yocto packaging, it is trivial to create one, and libraries such as
> cogl will use it if they find it, and it saves much pain all around,
> because other home grown ways of checking libEGL availability are
> usually not cross-compilation friendly.

cross-compilation and packaging unfriendly ;-)
Thomas Senyk - Feb. 26, 2013, 5:25 p.m.
On Fri, February 15, 2013 16:23:42 Otavio Salvador wrote:
> On Fri, Feb 15, 2013 at 3:10 PM, Thomas Senyk
> 
> <thomas.senyk@pelagicore.com> wrote:
> > On Wed, February 13, 2013 19:11:59 Otavio Salvador wrote:
> >> On Wed, Feb 13, 2013 at 3:44 PM, Thomas Senyk
> >> 
> >> <thomas.senyk@pelagicore.com> wrote:
> >> > On Tue, February 12, 2013 19:59:45 Otavio Salvador wrote:
> >> > > On Tue, Feb 12, 2013 at 7:58 PM, Otavio Salvador
> >> > > 
> >> > > <otavio@ossystems.com.br> wrote:
> >> > > > Hello,
> >> > > > 
> >> > > > This patch series upgrades the iMX6Q BSP to 1.1.0; it also try to
> >> > > > fix
> >> > > > the DRI support for it.
> >> > > > 
> >> > > > Please give it a try as this is a huge upgrade and we might have
> >> > > > regressions and pending issues still unkown. This series depends on
> >> > > > a
> >> > > > cuple of patches I sent to OpenEmbeeded-Core mailing list for
> >> > > > xserver-xorg and mesa, please apply them before playing with this
> >> > > > series.
> >> > > 
> >> > > I've created a bundle for this series:
> >> > > 
> >> > > OE-Core/Poky patches:
> >> > > 
> >> > > http://patches.openembedded.org/bundle/otavio/oe-core-dri-patches/
> >> > > 
> >> > > Meta-FSL-ARM patches:
> >> > > 
> >> > > http://patches.openembedded.org/bundle/otavio/bsp-1.1.0-update/
> >> > 
> >> > Nice thanks for the bundle.
> >> > 
> >> > Most of my issues got fixed in v4! good job! :)
> >> > 
> >> > The left overs:
> >> > 
> >> > 1. After applied the upstream patches I got:
> >> > 
> >> > ERROR: No recipes available for:
> >> >   /home/tsenyk/projects/oe-yocto/fsl-community-bsp/sources/meta-fsl-
> >> > 
> >> > arm/recipes-graphics/mesa/mesa-dri_9.0.1.bbappend
> >> > ERROR: Command execution failed: Exited with 1
> >> > 
> >> > ... their is probably just some patch missing or something .. I just
> >> > deleted it and it was good ;)
> >> > I don't care that much about this one :) (I just wanted to report this)
> >> 
> >> Yes. I will check if we need to keep the bbappend or it is safe to drop
> >> it.
> >> 
> >> > 2. The deploy and symlinks in the image look very good now:
> >> > lrwxrwxrwx 1 root root       12 Feb 13 17:49 libEGL.so -> libEGL-fb.so
> >> > -rw-r--r-- 1 root root   803326 Feb 13 17:33 libGAL-fb.so
> >> > lrwxrwxrwx 1 root root       12 Feb 13 17:49 libGAL.so -> libGAL-fb.so
> >> > 
> >> > nice!
> >> 
> >> Not that nice; in fact we shoudln't have the symlinks or X11 things
> >> might end linking against framebuffer libraries by mistake.
> > 
> > This sounds rather unconventional ;)
> > I've never seen any platform were libEGL-something.so is the EGL target to
> > link to.
> > 
> > In general one should define the default flavor of the GPU-driver
> > 
> >    ... which is setting the libEGL.so symblink.
> 
> For this the alternatives system might be a solution for the target.
> The problem is what to do during the build of applications. Think in
> such case:
> 
>  - gpu-viv is build
>  - app-fb is build
>  - app-x11 is build
> 
> If we have libEGL.so how we manage to link each to the right one?

Why would you support this anyway?
Having two EGL versions on your system/sysroot at the same time sounds wrong 
doesn't it?

I'd say it depends on your DISTRO_FEATURES and you need to choice either 
linuxfb, directfb or x11.
 ...and the rules are something like:
  - is x11 in your DISTRO_FEATURES? => x11 version of drivers
  - if not, is directfb in your DISTRO_FEATURES? => egl version of drivers
  - if not: linuxfb version of drivers


<side note>
Besides that: You need to solve the "link to the right one" anyway, if you 
have libEGL.so or not. (Although I admit it's more likely to cause problems if 
you have it)
<\side note>

> 
> > In relation to the "link by mistake"-argument:
> > a) You have a fb-only setup: there will be no x11-things.
> > b) You have a x11 setup: the default is libEGL-x11.so and theirfor no
> > problem.> 
> >     ... if on a x11 setup a application want to explicitly link against
> > 
> > libEGL-fb.so it can do anyway, but at least the default on is set.
> > c) You have a dfb setup: the default link goes to libEGL-dfb.so
> 
> This works well for runtime and I fully agree.
> 
> I am concerned about how we will manage it at *build* time. Bear on
> mind that app-fb and app-x11 can be build in parallel so change the
> link during the build is not going to work.

again: why support 2 build targets in the same sysroot?

> 
> > How do applications within the yocto build link against libEGL?
> > There are generally no .pc file for GPU-drivers
> > 
> >    ... are there internal variables to reference?
> 
> You may need to patch the application to link to one or another. Or
> play with LDFLAGS...

That sounds intense...this would mean that one HW-layer (meta-fsl-arm) tries 
to invent/enforce a new way of building application for everybody(?)?
Not sure this will thrive ;)

> 
> >> > Also the deploy in the sysroot looks good (only libEGL-fb.so and non of
> >> > the
> >> > others are present) .... so the file-split is working, but there are no
> >> > symblinks.
> >> > 
> >> > I tried to fix this by creating symlinks manually in do_install:
> >> > 
> >> > diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> >> > b/recipes- graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> >> > index 9818c72..af6dc82 100644
> >> > --- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> >> > +++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> >> > @@ -91,6 +91,20 @@ do_install () {
> >> > 
> >> >         ${D}${libdir}/libGAL.so \
> >> >         ${D}${libdir}/libVIVANTE.so
> >> > 
> >> > +    if [ "${KEEP_XLIBS}" = "yes" ]; then
> >> > +        ln -s ${D}${libdir}/libEGL-x11.so ${D}${libdir}/libEGL.so
> >> > +        ln -s ${D}${libdir}/libGAL-x11.so ${D}${libdir}/libGAL.so
> >> > +        ln -s ${D}${libdir}/libVIVANTE-x11.so
> >> > ${D}${libdir}/libVIVANTE.so
> >> > +    elif [ "${KEEP_DFBLIBS}" = "yes" ]; then
> >> > +        ln -s ${D}${libdir}/libEGL-dfb.so ${D}${libdir}/libEGL.so
> >> > +        ln -s ${D}${libdir}/libGAL-dfb.so ${D}${libdir}/libGAL.so
> >> > +        ln -s ${D}${libdir}/libVIVANTE-dfb.so
> >> > ${D}${libdir}/libVIVANTE.so
> >> > +    else
> >> > +        ln -s libEGL-fb.so ${D}${libdir}/libEGL.so
> >> > +        ln -s libGAL-fb.so ${D}${libdir}/libGAL.so
> >> > +        ln -s libVIVANTE-fb.so ${D}${libdir}/libVIVANTE.so
> >> > +    fi
> >> > +
> >> > 
> >> >      find ${D}${libdir} -type f -exec chmod 644 {} \;
> >> >      find ${D}${includedir} -type f -exec chmod 644 {} \;
> >> >  
> >> >  }
> >> 
> >> Read obove...
> >> 
> >> > I have absolutely NO idea if this is in anyway the right thing to do!
> >> > I had errors, bitbake complaining about .so files not part of the -dev
> >> > package ... but for some reason I don't get those anymore after I
> >> > removed
> >> > all of my other changes and just kept the 'ln -s'-lines ... so:
> >> > If you think it the right way, just take it and submit v5 and/or commit
> >> > it
> >> > after v4 is merged.
> >> 
> >> No; it is not.
> > 
> > Because of the above or because the way I set the symlinks is wrong?
> 
> Your code is right the problem is the concurrent build as explained above.
> 
> >> > 3. I still got the following errors when starting any Qt5 application:
> >> > 
> >> > vertex shader compilation error:
> >> > fragment shader compilation error:
> >> > program link error: No vertex shader attached.
> >> > 
> >> > My setup: I do a image of my own, the main(!) contents of the image is:
> >> > inherit core-image
> >> > IMAGE_INSTALL += "libpng tslib libudev gpu-viv-bin-mx6q"
> >> > IMAGE_FEATURES += "ssh-server-openssh tools-debug"
> >> > DEPENDS = "gpu-viv-bin-mx6q libpng"
> >> > 
> >> > Then I compile Qt5 git from outside of yocto, my configure line:
> >> > ../qt5/configure -opensource -confirm-license -make libs -device imx6
> >> > -device- option
> >> > CROSS_COMPILE=~/projects/oe-yocto/fsl-community-bsp/imx6-
> >> > build-10/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-
> >> > gnueabi/arm-poky-linux-gnueabi- -sysroot
> >> > ~/projects/oe-yocto/fsl-community-
> >> > bsp/imx6-build-10/tmp/sysroots/imx6qsabrelite -prefix
> >> > /opt/pelagicore/Qt5.0- yocto-imx6-10 -opengl es2 -no-pch -v
> >> 
> >> This might be the cause of the problem. We need to build it using
> >> Yocto toolchain so it links with proper library names or we raise the
> >> errors we need to deal with. Can you give it a try?
> >> 
> >> > This way I've compiled Qt5 against yocto builds for a while now.
> >> > The only related problem I had in the past was the '#define mediump vs.
> >> > heighp' which I could solve a patching Qt.
> >> > This isn't helping anymore ... but I'm still investigating.
> >> 
> >> Please check if you can build against the toolchain. To generate the
> >> toolchain for your image do:
> >> 
> >> bitbake <image> -c populate_sdk
> > 
> > I already use the yocto toolchain and sysroot ... I think? ;)
> > I'll checkout what does '-c populate_sdk' as soon as I find some time (I
> > guess week after next week)
> 
> Right; if I find the need time I will try to play with it as well.
> 
> Regards,
Otavio Salvador - Feb. 26, 2013, 5:39 p.m.
On Tue, Feb 26, 2013 at 2:25 PM, Thomas Senyk
<thomas.senyk@pelagicore.com> wrote:
> On Fri, February 15, 2013 16:23:42 Otavio Salvador wrote:
>> On Fri, Feb 15, 2013 at 3:10 PM, Thomas Senyk
>>
>> <thomas.senyk@pelagicore.com> wrote:
>> > On Wed, February 13, 2013 19:11:59 Otavio Salvador wrote:
>> >> On Wed, Feb 13, 2013 at 3:44 PM, Thomas Senyk
>> >>
>> >> <thomas.senyk@pelagicore.com> wrote:
>> >> > On Tue, February 12, 2013 19:59:45 Otavio Salvador wrote:
>> >> > > On Tue, Feb 12, 2013 at 7:58 PM, Otavio Salvador
>> >> > >
>> >> > > <otavio@ossystems.com.br> wrote:
>> >> > > > Hello,
>> >> > > >
>> >> > > > This patch series upgrades the iMX6Q BSP to 1.1.0; it also try to
>> >> > > > fix
>> >> > > > the DRI support for it.
>> >> > > >
>> >> > > > Please give it a try as this is a huge upgrade and we might have
>> >> > > > regressions and pending issues still unkown. This series depends on
>> >> > > > a
>> >> > > > cuple of patches I sent to OpenEmbeeded-Core mailing list for
>> >> > > > xserver-xorg and mesa, please apply them before playing with this
>> >> > > > series.
>> >> > >
>> >> > > I've created a bundle for this series:
>> >> > >
>> >> > > OE-Core/Poky patches:
>> >> > >
>> >> > > http://patches.openembedded.org/bundle/otavio/oe-core-dri-patches/
>> >> > >
>> >> > > Meta-FSL-ARM patches:
>> >> > >
>> >> > > http://patches.openembedded.org/bundle/otavio/bsp-1.1.0-update/
>> >> >
>> >> > Nice thanks for the bundle.
>> >> >
>> >> > Most of my issues got fixed in v4! good job! :)
>> >> >
>> >> > The left overs:
>> >> >
>> >> > 1. After applied the upstream patches I got:
>> >> >
>> >> > ERROR: No recipes available for:
>> >> >   /home/tsenyk/projects/oe-yocto/fsl-community-bsp/sources/meta-fsl-
>> >> >
>> >> > arm/recipes-graphics/mesa/mesa-dri_9.0.1.bbappend
>> >> > ERROR: Command execution failed: Exited with 1
>> >> >
>> >> > ... their is probably just some patch missing or something .. I just
>> >> > deleted it and it was good ;)
>> >> > I don't care that much about this one :) (I just wanted to report this)
>> >>
>> >> Yes. I will check if we need to keep the bbappend or it is safe to drop
>> >> it.
>> >>
>> >> > 2. The deploy and symlinks in the image look very good now:
>> >> > lrwxrwxrwx 1 root root       12 Feb 13 17:49 libEGL.so -> libEGL-fb.so
>> >> > -rw-r--r-- 1 root root   803326 Feb 13 17:33 libGAL-fb.so
>> >> > lrwxrwxrwx 1 root root       12 Feb 13 17:49 libGAL.so -> libGAL-fb.so
>> >> >
>> >> > nice!
>> >>
>> >> Not that nice; in fact we shoudln't have the symlinks or X11 things
>> >> might end linking against framebuffer libraries by mistake.
>> >
>> > This sounds rather unconventional ;)
>> > I've never seen any platform were libEGL-something.so is the EGL target to
>> > link to.
>> >
>> > In general one should define the default flavor of the GPU-driver
>> >
>> >    ... which is setting the libEGL.so symblink.
>>
>> For this the alternatives system might be a solution for the target.
>> The problem is what to do during the build of applications. Think in
>> such case:
>>
>>  - gpu-viv is build
>>  - app-fb is build
>>  - app-x11 is build
>>
>> If we have libEGL.so how we manage to link each to the right one?
>
> Why would you support this anyway?
> Having two EGL versions on your system/sysroot at the same time sounds wrong
> doesn't it?

At runtime, I agree but not at build time.

> I'd say it depends on your DISTRO_FEATURES and you need to choice either
> linuxfb, directfb or x11.
>  ...and the rules are something like:
>   - is x11 in your DISTRO_FEATURES? => x11 version of drivers
>   - if not, is directfb in your DISTRO_FEATURES? => egl version of drivers
>   - if not: linuxfb version of drivers

But distro features does not mean "enforce X11 use" but "allow X11
use" so it seems we should support fb use even with X11 feature
enabled.

> <side note>
> Besides that: You need to solve the "link to the right one" anyway, if you
> have libEGL.so or not. (Although I admit it's more likely to cause problems if
> you have it)
> <\side note>
>
>>
>> > In relation to the "link by mistake"-argument:
>> > a) You have a fb-only setup: there will be no x11-things.
>> > b) You have a x11 setup: the default is libEGL-x11.so and theirfor no
>> > problem.>
>> >     ... if on a x11 setup a application want to explicitly link against
>> >
>> > libEGL-fb.so it can do anyway, but at least the default on is set.
>> > c) You have a dfb setup: the default link goes to libEGL-dfb.so
>>
>> This works well for runtime and I fully agree.
>>
>> I am concerned about how we will manage it at *build* time. Bear on
>> mind that app-fb and app-x11 can be build in parallel so change the
>> link during the build is not going to work.
>
> again: why support 2 build targets in the same sysroot?

Read above.

>> > How do applications within the yocto build link against libEGL?
>> > There are generally no .pc file for GPU-drivers
>> >
>> >    ... are there internal variables to reference?
>>
>> You may need to patch the application to link to one or another. Or
>> play with LDFLAGS...
>
> That sounds intense...this would mean that one HW-layer (meta-fsl-arm) tries
> to invent/enforce a new way of building application for everybody(?)?
> Not sure this will thrive ;)

Well, the "right" way of deal with it is to have a library which loads
the right backend libraries depending if you're running in X11 or not.
Besides it is not new way but a explicit build flag ... not that bad.

>> >> > Also the deploy in the sysroot looks good (only libEGL-fb.so and non of
>> >> > the
>> >> > others are present) .... so the file-split is working, but there are no
>> >> > symblinks.
>> >> >
>> >> > I tried to fix this by creating symlinks manually in do_install:
>> >> >
>> >> > diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
>> >> > b/recipes- graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
>> >> > index 9818c72..af6dc82 100644
>> >> > --- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
>> >> > +++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
>> >> > @@ -91,6 +91,20 @@ do_install () {
>> >> >
>> >> >         ${D}${libdir}/libGAL.so \
>> >> >         ${D}${libdir}/libVIVANTE.so
>> >> >
>> >> > +    if [ "${KEEP_XLIBS}" = "yes" ]; then
>> >> > +        ln -s ${D}${libdir}/libEGL-x11.so ${D}${libdir}/libEGL.so
>> >> > +        ln -s ${D}${libdir}/libGAL-x11.so ${D}${libdir}/libGAL.so
>> >> > +        ln -s ${D}${libdir}/libVIVANTE-x11.so
>> >> > ${D}${libdir}/libVIVANTE.so
>> >> > +    elif [ "${KEEP_DFBLIBS}" = "yes" ]; then
>> >> > +        ln -s ${D}${libdir}/libEGL-dfb.so ${D}${libdir}/libEGL.so
>> >> > +        ln -s ${D}${libdir}/libGAL-dfb.so ${D}${libdir}/libGAL.so
>> >> > +        ln -s ${D}${libdir}/libVIVANTE-dfb.so
>> >> > ${D}${libdir}/libVIVANTE.so
>> >> > +    else
>> >> > +        ln -s libEGL-fb.so ${D}${libdir}/libEGL.so
>> >> > +        ln -s libGAL-fb.so ${D}${libdir}/libGAL.so
>> >> > +        ln -s libVIVANTE-fb.so ${D}${libdir}/libVIVANTE.so
>> >> > +    fi
>> >> > +
>> >> >
>> >> >      find ${D}${libdir} -type f -exec chmod 644 {} \;
>> >> >      find ${D}${includedir} -type f -exec chmod 644 {} \;
>> >> >
>> >> >  }
>> >>
>> >> Read obove...
>> >>
>> >> > I have absolutely NO idea if this is in anyway the right thing to do!
>> >> > I had errors, bitbake complaining about .so files not part of the -dev
>> >> > package ... but for some reason I don't get those anymore after I
>> >> > removed
>> >> > all of my other changes and just kept the 'ln -s'-lines ... so:
>> >> > If you think it the right way, just take it and submit v5 and/or commit
>> >> > it
>> >> > after v4 is merged.
>> >>
>> >> No; it is not.
>> >
>> > Because of the above or because the way I set the symlinks is wrong?
>>
>> Your code is right the problem is the concurrent build as explained above.
>>
>> >> > 3. I still got the following errors when starting any Qt5 application:
>> >> >
>> >> > vertex shader compilation error:
>> >> > fragment shader compilation error:
>> >> > program link error: No vertex shader attached.
>> >> >
>> >> > My setup: I do a image of my own, the main(!) contents of the image is:
>> >> > inherit core-image
>> >> > IMAGE_INSTALL += "libpng tslib libudev gpu-viv-bin-mx6q"
>> >> > IMAGE_FEATURES += "ssh-server-openssh tools-debug"
>> >> > DEPENDS = "gpu-viv-bin-mx6q libpng"
>> >> >
>> >> > Then I compile Qt5 git from outside of yocto, my configure line:
>> >> > ../qt5/configure -opensource -confirm-license -make libs -device imx6
>> >> > -device- option
>> >> > CROSS_COMPILE=~/projects/oe-yocto/fsl-community-bsp/imx6-
>> >> > build-10/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-
>> >> > gnueabi/arm-poky-linux-gnueabi- -sysroot
>> >> > ~/projects/oe-yocto/fsl-community-
>> >> > bsp/imx6-build-10/tmp/sysroots/imx6qsabrelite -prefix
>> >> > /opt/pelagicore/Qt5.0- yocto-imx6-10 -opengl es2 -no-pch -v
>> >>
>> >> This might be the cause of the problem. We need to build it using
>> >> Yocto toolchain so it links with proper library names or we raise the
>> >> errors we need to deal with. Can you give it a try?
>> >>
>> >> > This way I've compiled Qt5 against yocto builds for a while now.
>> >> > The only related problem I had in the past was the '#define mediump vs.
>> >> > heighp' which I could solve a patching Qt.
>> >> > This isn't helping anymore ... but I'm still investigating.
>> >>
>> >> Please check if you can build against the toolchain. To generate the
>> >> toolchain for your image do:
>> >>
>> >> bitbake <image> -c populate_sdk
>> >
>> > I already use the yocto toolchain and sysroot ... I think? ;)
>> > I'll checkout what does '-c populate_sdk' as soon as I find some time (I
>> > guess week after next week)
>>
>> Right; if I find the need time I will try to play with it as well.

Did you try the sdk?
Thomas Senyk - Feb. 26, 2013, 5:49 p.m.
On Tue, February 26, 2013 14:39:18 Otavio Salvador wrote:
> On Tue, Feb 26, 2013 at 2:25 PM, Thomas Senyk
> 
> <thomas.senyk@pelagicore.com> wrote:
> > On Fri, February 15, 2013 16:23:42 Otavio Salvador wrote:
> >> On Fri, Feb 15, 2013 at 3:10 PM, Thomas Senyk
> >> 
> >> <thomas.senyk@pelagicore.com> wrote:
> >> > On Wed, February 13, 2013 19:11:59 Otavio Salvador wrote:
> >> >> On Wed, Feb 13, 2013 at 3:44 PM, Thomas Senyk
> >> >> 
> >> >> <thomas.senyk@pelagicore.com> wrote:
> >> >> > On Tue, February 12, 2013 19:59:45 Otavio Salvador wrote:
> >> >> > > On Tue, Feb 12, 2013 at 7:58 PM, Otavio Salvador
> >> >> > > 
> >> >> > > <otavio@ossystems.com.br> wrote:
> >> >> > > > Hello,
> >> >> > > > 
> >> >> > > > This patch series upgrades the iMX6Q BSP to 1.1.0; it also try
> >> >> > > > to
> >> >> > > > fix
> >> >> > > > the DRI support for it.
> >> >> > > > 
> >> >> > > > Please give it a try as this is a huge upgrade and we might have
> >> >> > > > regressions and pending issues still unkown. This series depends
> >> >> > > > on
> >> >> > > > a
> >> >> > > > cuple of patches I sent to OpenEmbeeded-Core mailing list for
> >> >> > > > xserver-xorg and mesa, please apply them before playing with
> >> >> > > > this
> >> >> > > > series.
> >> >> > > 
> >> >> > > I've created a bundle for this series:
> >> >> > > 
> >> >> > > OE-Core/Poky patches:
> >> >> > > 
> >> >> > > http://patches.openembedded.org/bundle/otavio/oe-core-dri-patches/
> >> >> > > 
> >> >> > > Meta-FSL-ARM patches:
> >> >> > > 
> >> >> > > http://patches.openembedded.org/bundle/otavio/bsp-1.1.0-update/
> >> >> > 
> >> >> > Nice thanks for the bundle.
> >> >> > 
> >> >> > Most of my issues got fixed in v4! good job! :)
> >> >> > 
> >> >> > The left overs:
> >> >> > 
> >> >> > 1. After applied the upstream patches I got:
> >> >> > 
> >> >> > ERROR: No recipes available for:
> >> >> >   /home/tsenyk/projects/oe-yocto/fsl-community-bsp/sources/meta-fsl-
> >> >> > 
> >> >> > arm/recipes-graphics/mesa/mesa-dri_9.0.1.bbappend
> >> >> > ERROR: Command execution failed: Exited with 1
> >> >> > 
> >> >> > ... their is probably just some patch missing or something .. I just
> >> >> > deleted it and it was good ;)
> >> >> > I don't care that much about this one :) (I just wanted to report
> >> >> > this)
> >> >> 
> >> >> Yes. I will check if we need to keep the bbappend or it is safe to
> >> >> drop
> >> >> it.
> >> >> 
> >> >> > 2. The deploy and symlinks in the image look very good now:
> >> >> > lrwxrwxrwx 1 root root       12 Feb 13 17:49 libEGL.so ->
> >> >> > libEGL-fb.so
> >> >> > -rw-r--r-- 1 root root   803326 Feb 13 17:33 libGAL-fb.so
> >> >> > lrwxrwxrwx 1 root root       12 Feb 13 17:49 libGAL.so ->
> >> >> > libGAL-fb.so
> >> >> > 
> >> >> > nice!
> >> >> 
> >> >> Not that nice; in fact we shoudln't have the symlinks or X11 things
> >> >> might end linking against framebuffer libraries by mistake.
> >> > 
> >> > This sounds rather unconventional ;)
> >> > I've never seen any platform were libEGL-something.so is the EGL target
> >> > to
> >> > link to.
> >> > 
> >> > In general one should define the default flavor of the GPU-driver
> >> > 
> >> >    ... which is setting the libEGL.so symblink.
> >> 
> >> For this the alternatives system might be a solution for the target.
> >> The problem is what to do during the build of applications. Think in
> >> 
> >> such case:
> >>  - gpu-viv is build
> >>  - app-fb is build
> >>  - app-x11 is build
> >> 
> >> If we have libEGL.so how we manage to link each to the right one?
> > 
> > Why would you support this anyway?
> > Having two EGL versions on your system/sysroot at the same time sounds
> > wrong doesn't it?
> 
> At runtime, I agree but not at build time.
> 
> > I'd say it depends on your DISTRO_FEATURES and you need to choice either
> > linuxfb, directfb or x11.
> > 
> >  ...and the rules are something like:
> >   - is x11 in your DISTRO_FEATURES? => x11 version of drivers
> >   - if not, is directfb in your DISTRO_FEATURES? => egl version of drivers
> >   - if not: linuxfb version of drivers
> 
> But distro features does not mean "enforce X11 use" but "allow X11
> use" so it seems we should support fb use even with X11 feature
> enabled.
> 
> > <side note>
> > Besides that: You need to solve the "link to the right one" anyway, if you
> > have libEGL.so or not. (Although I admit it's more likely to cause
> > problems if you have it)
> > <\side note>
> > 
> >> > In relation to the "link by mistake"-argument:
> >> > a) You have a fb-only setup: there will be no x11-things.
> >> > b) You have a x11 setup: the default is libEGL-x11.so and theirfor no
> >> > problem.>
> >> > 
> >> >     ... if on a x11 setup a application want to explicitly link against
> >> > 
> >> > libEGL-fb.so it can do anyway, but at least the default on is set.
> >> > c) You have a dfb setup: the default link goes to libEGL-dfb.so
> >> 
> >> This works well for runtime and I fully agree.
> >> 
> >> I am concerned about how we will manage it at *build* time. Bear on
> >> mind that app-fb and app-x11 can be build in parallel so change the
> >> link during the build is not going to work.
> > 
> > again: why support 2 build targets in the same sysroot?
> 
> Read above.
> 
> >> > How do applications within the yocto build link against libEGL?
> >> > There are generally no .pc file for GPU-drivers
> >> > 
> >> >    ... are there internal variables to reference?
> >> 
> >> You may need to patch the application to link to one or another. Or
> >> play with LDFLAGS...
> > 
> > That sounds intense...this would mean that one HW-layer (meta-fsl-arm)
> > tries to invent/enforce a new way of building application for
> > everybody(?)? Not sure this will thrive ;)
> 
> Well, the "right" way of deal with it is to have a library which loads
> the right backend libraries depending if you're running in X11 or not.
> Besides it is not new way but a explicit build flag ... not that bad.
> 
> >> >> > Also the deploy in the sysroot looks good (only libEGL-fb.so and non
> >> >> > of
> >> >> > the
> >> >> > others are present) .... so the file-split is working, but there are
> >> >> > no
> >> >> > symblinks.
> >> >> > 
> >> >> > I tried to fix this by creating symlinks manually in do_install:
> >> >> > 
> >> >> > diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> >> >> > b/recipes- graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> >> >> > index 9818c72..af6dc82 100644
> >> >> > --- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> >> >> > +++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> >> >> > @@ -91,6 +91,20 @@ do_install () {
> >> >> > 
> >> >> >         ${D}${libdir}/libGAL.so \
> >> >> >         ${D}${libdir}/libVIVANTE.so
> >> >> > 
> >> >> > +    if [ "${KEEP_XLIBS}" = "yes" ]; then
> >> >> > +        ln -s ${D}${libdir}/libEGL-x11.so ${D}${libdir}/libEGL.so
> >> >> > +        ln -s ${D}${libdir}/libGAL-x11.so ${D}${libdir}/libGAL.so
> >> >> > +        ln -s ${D}${libdir}/libVIVANTE-x11.so
> >> >> > ${D}${libdir}/libVIVANTE.so
> >> >> > +    elif [ "${KEEP_DFBLIBS}" = "yes" ]; then
> >> >> > +        ln -s ${D}${libdir}/libEGL-dfb.so ${D}${libdir}/libEGL.so
> >> >> > +        ln -s ${D}${libdir}/libGAL-dfb.so ${D}${libdir}/libGAL.so
> >> >> > +        ln -s ${D}${libdir}/libVIVANTE-dfb.so
> >> >> > ${D}${libdir}/libVIVANTE.so
> >> >> > +    else
> >> >> > +        ln -s libEGL-fb.so ${D}${libdir}/libEGL.so
> >> >> > +        ln -s libGAL-fb.so ${D}${libdir}/libGAL.so
> >> >> > +        ln -s libVIVANTE-fb.so ${D}${libdir}/libVIVANTE.so
> >> >> > +    fi
> >> >> > +
> >> >> > 
> >> >> >      find ${D}${libdir} -type f -exec chmod 644 {} \;
> >> >> >      find ${D}${includedir} -type f -exec chmod 644 {} \;
> >> >> >  
> >> >> >  }
> >> >> 
> >> >> Read obove...
> >> >> 
> >> >> > I have absolutely NO idea if this is in anyway the right thing to
> >> >> > do!
> >> >> > I had errors, bitbake complaining about .so files not part of the
> >> >> > -dev
> >> >> > package ... but for some reason I don't get those anymore after I
> >> >> > removed
> >> >> > all of my other changes and just kept the 'ln -s'-lines ... so:
> >> >> > If you think it the right way, just take it and submit v5 and/or
> >> >> > commit
> >> >> > it
> >> >> > after v4 is merged.
> >> >> 
> >> >> No; it is not.
> >> > 
> >> > Because of the above or because the way I set the symlinks is wrong?
> >> 
> >> Your code is right the problem is the concurrent build as explained
> >> above.
> >> 
> >> >> > 3. I still got the following errors when starting any Qt5
> >> >> > application:
> >> >> > 
> >> >> > vertex shader compilation error:
> >> >> > fragment shader compilation error:
> >> >> > program link error: No vertex shader attached.
> >> >> > 
> >> >> > My setup: I do a image of my own, the main(!) contents of the image
> >> >> > is:
> >> >> > inherit core-image
> >> >> > IMAGE_INSTALL += "libpng tslib libudev gpu-viv-bin-mx6q"
> >> >> > IMAGE_FEATURES += "ssh-server-openssh tools-debug"
> >> >> > DEPENDS = "gpu-viv-bin-mx6q libpng"
> >> >> > 
> >> >> > Then I compile Qt5 git from outside of yocto, my configure line:
> >> >> > ../qt5/configure -opensource -confirm-license -make libs -device
> >> >> > imx6
> >> >> > -device- option
> >> >> > CROSS_COMPILE=~/projects/oe-yocto/fsl-community-bsp/imx6-
> >> >> > build-10/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linu
> >> >> > x-
> >> >> > gnueabi/arm-poky-linux-gnueabi- -sysroot
> >> >> > ~/projects/oe-yocto/fsl-community-
> >> >> > bsp/imx6-build-10/tmp/sysroots/imx6qsabrelite -prefix
> >> >> > /opt/pelagicore/Qt5.0- yocto-imx6-10 -opengl es2 -no-pch -v
> >> >> 
> >> >> This might be the cause of the problem. We need to build it using
> >> >> Yocto toolchain so it links with proper library names or we raise the
> >> >> errors we need to deal with. Can you give it a try?
> >> >> 
> >> >> > This way I've compiled Qt5 against yocto builds for a while now.
> >> >> > The only related problem I had in the past was the '#define mediump
> >> >> > vs.
> >> >> > heighp' which I could solve a patching Qt.
> >> >> > This isn't helping anymore ... but I'm still investigating.
> >> >> 
> >> >> Please check if you can build against the toolchain. To generate the
> >> >> toolchain for your image do:
> >> >> 
> >> >> bitbake <image> -c populate_sdk
> >> > 
> >> > I already use the yocto toolchain and sysroot ... I think? ;)
> >> > I'll checkout what does '-c populate_sdk' as soon as I find some time
> >> > (I
> >> > guess week after next week)
> >> 
> >> Right; if I find the need time I will try to play with it as well.
> 
> Did you try the sdk?

A colleague did and said he has the same results is with the "normal" 
toolchain/sysroot.
Erik Botö - March 20, 2013, 2:13 p.m.
Hi,

What's the latest on getting 1.1.0 into master?

Cheers,
Erik
Otavio Salvador - March 20, 2013, 2:25 p.m.
On Wed, Mar 20, 2013 at 11:13 AM, Erik Botö <erik.boto@pelagicore.com> wrote:
> Hi,
>
> What's the latest on getting 1.1.0 into master?

I am merging the ready parts (today I merged 3 patches) and should
send some more today.

Patch

diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc b/recipes-
graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
index 9818c72..af6dc82 100644
--- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
+++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
@@ -91,6 +91,20 @@  do_install () {
        ${D}${libdir}/libGAL.so \
        ${D}${libdir}/libVIVANTE.so
 
+    if [ "${KEEP_XLIBS}" = "yes" ]; then
+        ln -s ${D}${libdir}/libEGL-x11.so ${D}${libdir}/libEGL.so
+        ln -s ${D}${libdir}/libGAL-x11.so ${D}${libdir}/libGAL.so
+        ln -s ${D}${libdir}/libVIVANTE-x11.so ${D}${libdir}/libVIVANTE.so
+    elif [ "${KEEP_DFBLIBS}" = "yes" ]; then
+        ln -s ${D}${libdir}/libEGL-dfb.so ${D}${libdir}/libEGL.so
+        ln -s ${D}${libdir}/libGAL-dfb.so ${D}${libdir}/libGAL.so
+        ln -s ${D}${libdir}/libVIVANTE-dfb.so ${D}${libdir}/libVIVANTE.so
+    else
+        ln -s libEGL-fb.so ${D}${libdir}/libEGL.so
+        ln -s libGAL-fb.so ${D}${libdir}/libGAL.so
+        ln -s libVIVANTE-fb.so ${D}${libdir}/libVIVANTE.so
+    fi
+
     find ${D}${libdir} -type f -exec chmod 644 {} \;
     find ${D}${includedir} -type f -exec chmod 644 {} \;
 }