| 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
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: (mesa-dri is required by xserver, and libgles-omap3 is the accelerated gles driver from ti, which also provides egl by nature) +PROVIDES = "virtual/libgl ${PROV_EGL} ${PROV_GLES1} ${PROV_GLES2}" # for mesa-dri and mesa-xlib FILESEXTRAPATHS_append := "${THISDIR}/mesa:" @@ -41,14 +46,20 @@ EXCLUDE_FROM_WORLD = "1" # ie mesa-dri could be empty and mesa-dri-dev RDEPENDS on it ALLOW_EMPTY_${PN} = "1" -PACKAGES =+ "libegl libegl-dev libegl-dbg \ +PACK_EGL = "${@base_contains('DISTRO_FEATURES', 'egl', 'libegl libegl-dev libegl-dbg', '', d)}" +PACK_GLES = "${@base_contains('DISTRO_FEATURES', 'gles', 'libgles1 libgles1-dev libgles2 libgles2-dev', '', d)}" +PACK_GLES1 = "${@base_contains('DISTRO_FEATURES', 'gles1', 'libgles1 libgles1-dev', '', d)}" +PACK_GLES2 = "${@base_contains('DISTRO_FEATURES', 'gles2', 'libgles2 libgles2-dev', '', d)}" + +PACKAGES =+ "${PACK_EGL} \ libglu libglu-dev \ libosmesa libosmesa-dev \ libgl libgl-dev \ libglapi libglapi-dev \ libgbm libgbm-dev \ - libgles1 libgles1-dev \ - libgles2 libgles2-dev \ + ${PACK_GLES} \ + ${PACK_GLES1} \ + ${PACK_GLES2} \ " FILES_libegl = "${libdir}/libEGL.so.* ${libdir}/egl/*.so"