Message ID | 5042ABBC.60502@gmail.com |
---|---|
State | New |
Headers | show |
diff --git a/meta/recipes-graphics/mesa/mesa-common.inc b/meta/recipes-graphics/mesa/mesa-common.inc index cfe4a37..074dc5e 100644 --- a/meta/recipes-graphics/mesa/mesa-common.inc +++ b/meta/recipes-graphics/mesa/mesa-common.inc @@ -17,7 +17,12 @@ PE = "2" DEPENDS = "libxml2-native makedepend-native flex-native bison-native" -PROVIDES = "virtual/libgl virtual/libgles1 virtual/libgles2 virtual/egl" +PROV_EGL = "${@base_contains('DISTRO_FEATURES', 'egl', 'virtual/libegl', '', d)}" +PROV_GLES = "${@base_contains('DISTRO_FEATURES', 'gles', 'virtual/libgles1 virtual/libgles2', '', d)}" +PROV_GLES1 = "${@base_contains('DISTRO_FEATURES', 'gles1', 'virtual/libgles1', '', d)}" +PROV_GLES2 = "${@base_contains('DISTRO_FEATURES', 'gles2', 'virtual/libgles2', '', d)}" +
On 2 September 2012 01:43, Zoltan Gaal <z.p.gaal@gmail.com> wrote: > I'm new to oe, and I've seen there was quite a big discussion about the gles > support in mesa. > Now libgles-omap3 has the mentioned conflict with the mesa-dri as both > provides virtual/egl. I think a patch like this would solve the issue: Can't you just set PREFERRED_PROVIDER? meta-intel has the same problem with the EMGD and psb drivers also conflicting with mesa-dri. Ross
I've tried it, but mesa-dri is required for xserver and it won't compile without it. libgles-omap3 cannot replace the mesa dependency, though I'm not sure if it is a simple config issue or some interface is missing (libgl). And as libgles-omap3 also provides virtual/egl, the bitbake process detects, there exists multiple projects with the same provided feature: NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue ERROR: Multiple .bb files are due to be built which each provide virtual/egl (/home/gzp/work/gumstix/oe/oe-meta/meta-ti/recipes-graphics/libgles/libgles-omap3_4.05.00.03.bb /home/gzp/work/gumstix/oe/oe-core/meta/recipes-graphics/mesa/mesa-dri_8.0.4.bb). This usually means one provides something the other doesn't and should. NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks (in local.conf: PREFERRED_PROVIDER_virtual/egl="libgles-omap3") Gzp
On 2 September 2012 11:39, Zoltan Gaal <z.p.gaal@gmail.com> wrote: > I've tried it, but mesa-dri is required for xserver and it won't compile > without it. libgles-omap3 cannot replace the mesa dependency, though I'm not > sure if it is a simple config issue or some interface is missing (libgl). > And as libgles-omap3 also provides virtual/egl, the bitbake process detects, > there exists multiple projects with the same provided feature: So you end up with a system which has hardware accelerated EGL and GLES (though libgles-omap3) and software-only GL (through the software renderer in mesa)? Doesn't sound optimal. It's probably worth looking at making the GL dependency in X optional, so you can build X with just GLES support. Ross
On Sun, 2012-09-02 at 12:39 +0200, Zoltan Gaal wrote: > I've tried it, but mesa-dri is required for xserver and it won't compile > without it. libgles-omap3 cannot replace the mesa dependency, though I'm > not sure if it is a simple config issue or some interface is missing > (libgl). And as libgles-omap3 also provides virtual/egl, the bitbake > process detects, there exists multiple projects with the same provided > feature: > > NOTE: Resolving any missing task queue dependencies > NOTE: Preparing runqueue > ERROR: Multiple .bb files are due to be built which each provide > virtual/egl > (/home/gzp/work/gumstix/oe/oe-meta/meta-ti/recipes-graphics/libgles/libgles-omap3_4.05.00.03.bb > /home/gzp/work/gumstix/oe/oe-core/meta/recipes-graphics/mesa/mesa-dri_8.0.4.bb). > This usually means one provides something the other doesn't and should. > NOTE: Executing SetScene Tasks > NOTE: Executing RunQueue Tasks > > (in local.conf: PREFERRED_PROVIDER_virtual/egl="libgles-omap3") Try also adding it to MULTI_PROVIDER_WHITELIST (see bitbake.conf). This error message did use to just be a note but was turned into an error at various user's requests. Sometimes it means there are serious configuration issues, in a case like this, its ok though... Cheers, Richard
Thanks, that eliminated the error (warning), though I don't really like the idea. A recipe states something that's not so: mesa does not provides egl without the packageconfig, but who cares, while it is working and not too much confusing. In the pre-yocto ages there were much worse dependecies :) Thx, Gzp
On Sun, 2012-09-02 at 15:30 +0200, Andreas Müller wrote: > On Sun, Sep 2, 2012 at 2:39 PM, Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > On Sun, 2012-09-02 at 12:39 +0200, Zoltan Gaal wrote: > >> I've tried it, but mesa-dri is required for xserver and it won't compile > >> without it. libgles-omap3 cannot replace the mesa dependency, though I'm > >> not sure if it is a simple config issue or some interface is missing > >> (libgl). And as libgles-omap3 also provides virtual/egl, the bitbake > >> process detects, there exists multiple projects with the same provided > >> feature: > >> > >> NOTE: Resolving any missing task queue dependencies > >> NOTE: Preparing runqueue > >> ERROR: Multiple .bb files are due to be built which each provide > >> virtual/egl > >> (/home/gzp/work/gumstix/oe/oe-meta/meta-ti/recipes-graphics/libgles/libgles-omap3_4.05.00.03.bb > >> /home/gzp/work/gumstix/oe/oe-core/meta/recipes-graphics/mesa/mesa-dri_8.0.4.bb). > >> This usually means one provides something the other doesn't and should. > >> NOTE: Executing SetScene Tasks > >> NOTE: Executing RunQueue Tasks > >> > >> (in local.conf: PREFERRED_PROVIDER_virtual/egl="libgles-omap3") > > > > Try also adding it to MULTI_PROVIDER_WHITELIST (see bitbake.conf). > > > > This error message did use to just be a note but was turned into an > > error at various user's requests. Sometimes it means there are serious > > configuration issues, in a case like this, its ok though... > > > The problem is not the error message in first place but the wrong libs > (egl/gles/glesv2) in rootfs. As soon as mesa is in, libgles-omap libs > are out. This sounds like a configuration issue. Firstly, the machine config needs to make sure the libgles-omap package is included in the image, probably through something like the XSERVER variable although I appreciate we don't have anything for egl at this point. Secondly, the libglex-omap module should CONFLICT/REPLACE/PROVIDE the bits of mesa it replaces. Cheers, Richard