* Error message about multiple EGL / GLES providers @ 2013-05-20 18:18 Carlos Rafael Giani 2013-05-21 9:45 ` Burton, Ross 0 siblings, 1 reply; 7+ messages in thread From: Carlos Rafael Giani @ 2013-05-20 18:18 UTC (permalink / raw) To: Meta-OpenEmbedded Mailing listing Hello, I am currently adapting the cubox layer for dylan, and get these errors: ERROR: Multiple .bb files are due to be built which each provide virtual/libgles1 ERROR: Multiple .bb files are due to be built which each provide virtual/libgles2 ERROR: Multiple .bb files are due to be built which each provide virtual/egl I set the PREFERRED_PROVIDERS in the machine config file like this: PREFERRED_PROVIDER_virtual/egl_cubox ?= "marvell-libgfx" PREFERRED_PROVIDER_virtual/libgles1_cubox ?= "marvell-libgfx" PREFERRED_PROVIDER_virtual/libgles2_cubox ?= "marvell-libgfx" which is the way pretty much all layers seem to do it. I remember a discussion about this, with the outcome that these errors are inevitable in danny, and that dylan has special features in place to deal with the collisions between platform EGL/GLES drivers and mesa. However, I cannot find such a feature. Does anybody know more? cheers ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Error message about multiple EGL / GLES providers 2013-05-20 18:18 Error message about multiple EGL / GLES providers Carlos Rafael Giani @ 2013-05-21 9:45 ` Burton, Ross 2013-05-21 10:08 ` Carlos Rafael Giani 0 siblings, 1 reply; 7+ messages in thread From: Burton, Ross @ 2013-05-21 9:45 UTC (permalink / raw) To: openembedded-devel On 20 May 2013 19:18, Carlos Rafael Giani <dv@pseudoterminal.org> wrote: > I am currently adapting the cubox layer for dylan, and get these errors: > > ERROR: Multiple .bb files are due to be built which each provide > virtual/libgles1 > ERROR: Multiple .bb files are due to be built which each provide > virtual/libgles2 > ERROR: Multiple .bb files are due to be built which each provide virtual/egl What are the bb files that are being build? I'm guessing mesa and marvell-libgfx, but can you confirm this? If you use depexp you can find out what's pulling in mesa, but it's generally mesa-demos. This depends on virtual/libgl that you're not providing, so it will pull in Mesa. If you don't have any support for "big" GL then the easiest fix is to take the recent patches to mesa-demos in master that let you turn off GL using PACKAGECONFIG options. Ross ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Error message about multiple EGL / GLES providers 2013-05-21 9:45 ` Burton, Ross @ 2013-05-21 10:08 ` Carlos Rafael Giani 2013-05-21 10:51 ` Paul Barker 2013-05-21 15:22 ` Burton, Ross 0 siblings, 2 replies; 7+ messages in thread From: Carlos Rafael Giani @ 2013-05-21 10:08 UTC (permalink / raw) To: openembedded-devel On 2013-05-21 11:45, Burton, Ross wrote: > On 20 May 2013 19:18, Carlos Rafael Giani <dv@pseudoterminal.org> wrote: >> I am currently adapting the cubox layer for dylan, and get these errors: >> >> ERROR: Multiple .bb files are due to be built which each provide >> virtual/libgles1 >> ERROR: Multiple .bb files are due to be built which each provide >> virtual/libgles2 >> ERROR: Multiple .bb files are due to be built which each provide virtual/egl > What are the bb files that are being build? I'm guessing mesa and > marvell-libgfx, but can you confirm this? If you use depexp you can > find out what's pulling in mesa, but it's generally mesa-demos. This > depends on virtual/libgl that you're not providing, so it will pull in > Mesa. > > If you don't have any support for "big" GL then the easiest fix is to > take the recent patches to mesa-demos in master that let you turn off > GL using PACKAGECONFIG options. > > Ross > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel The collision is indeed between marvell-libgfx and mesa, I just verified. My case is actually quite common with embedded 3D hardware - EGL, OpenGL ES 1.x,2.x and OpenVG are supported, but desktop OpenGL isn't. I have seen this with nVidia Tegra, Vivante, PowerVR, and ARM Mali hardware so far. It would be useful to instruct Mesa to turn off its OpenGLES and EGL support, leaving Mesa only for GLX+Desktop OpenGL (software-rendered), if anybody really needs it. As an alternative, as you suggest, I could simply turn off desktop OpenGL, but I have the feeling that this would be better off as a user decision that can be configured in the local.conf file. What do you think? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Error message about multiple EGL / GLES providers 2013-05-21 10:08 ` Carlos Rafael Giani @ 2013-05-21 10:51 ` Paul Barker 2013-05-21 15:22 ` Burton, Ross 1 sibling, 0 replies; 7+ messages in thread From: Paul Barker @ 2013-05-21 10:51 UTC (permalink / raw) To: openembedded-devel On 21 May 2013 11:08, Carlos Rafael Giani <dv@pseudoterminal.org> wrote: > On 2013-05-21 11:45, Burton, Ross wrote: >> >> On 20 May 2013 19:18, Carlos Rafael Giani <dv@pseudoterminal.org> wrote: >>> >>> I am currently adapting the cubox layer for dylan, and get these errors: >>> >>> ERROR: Multiple .bb files are due to be built which each provide >>> virtual/libgles1 >>> ERROR: Multiple .bb files are due to be built which each provide >>> virtual/libgles2 >>> ERROR: Multiple .bb files are due to be built which each provide >>> virtual/egl >> >> What are the bb files that are being build? I'm guessing mesa and >> marvell-libgfx, but can you confirm this? If you use depexp you can >> find out what's pulling in mesa, but it's generally mesa-demos. This >> depends on virtual/libgl that you're not providing, so it will pull in >> Mesa. >> >> If you don't have any support for "big" GL then the easiest fix is to >> take the recent patches to mesa-demos in master that let you turn off >> GL using PACKAGECONFIG options. >> >> Ross > > > The collision is indeed between marvell-libgfx and mesa, I just verified. My > case is actually quite common with embedded 3D hardware - EGL, OpenGL ES > 1.x,2.x and OpenVG are supported, but desktop OpenGL isn't. I have seen this > with nVidia Tegra, Vivante, PowerVR, and ARM Mali hardware so far. It would > be useful to instruct Mesa to turn off its OpenGLES and EGL support, leaving > Mesa only for GLX+Desktop OpenGL (software-rendered), if anybody really > needs it. As an alternative, as you suggest, I could simply turn off desktop > OpenGL, but I have the feeling that this would be better off as a user > decision that can be configured in the local.conf file. What do you think? > This also crops up when building for raspberrypi with the meta-raspberrypi layer. The errors I see in a `bitbake world` are (with paths shortened): ERROR: Multiple .bb files are due to be built which each provide virtual/egl (.../openembedded-core/meta/recipes-graphics/mesa/mesa_9.0.2.bb .../meta-raspberrypi/recipes-graphics/userland/userland_git.bb). This usually means one provides something the other doesn't and should. ERROR: Multiple .bb files are due to be built which each provide virtual/libgles2 (.../openembedded-core/meta/recipes-graphics/mesa/mesa_9.0.2.bb .../meta-raspberrypi/recipes-graphics/userland/userland_git.bb). This usually means one provides something the other doesn't and should. It's not really something I've looked into much (I don't know the full list of things mesa provides) but if there's a solution for other platforms I could have a look at doing a similar thing in meta-raspberrypi. -- Paul Barker Email: paul@paulbarker.me.uk http://www.paulbarker.me.uk ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Error message about multiple EGL / GLES providers 2013-05-21 10:08 ` Carlos Rafael Giani 2013-05-21 10:51 ` Paul Barker @ 2013-05-21 15:22 ` Burton, Ross 2013-05-21 16:47 ` Otavio Salvador 2013-05-21 16:57 ` Carlos Rafael Giani 1 sibling, 2 replies; 7+ messages in thread From: Burton, Ross @ 2013-05-21 15:22 UTC (permalink / raw) To: openembedded-devel On 21 May 2013 11:08, Carlos Rafael Giani <dv@pseudoterminal.org> wrote: > It would > be useful to instruct Mesa to turn off its OpenGLES and EGL support, leaving > Mesa only for GLX+Desktop OpenGL (software-rendered), if anybody really > needs it. As an alternative, as you suggest, I could simply turn off desktop > OpenGL, but I have the feeling that this would be better off as a user > decision that can be configured in the local.conf file. What do you think? You can change mesa's PACKAGECONFIG to not build egl and gles. meta-intel does something like this because the EMGD/CDT drivers are in the same boat. However considering our software GL support in Mesa is currently swrast (very very bad) and not llvmpipe (usable if you have enough CPU, which we generally don't) you generally don't want to actually have any OpenGL present at all. Generally it's mesa-demos that pulls in virtual/libgl, and in master this can be disabled. This may be worth a backport if someone wants to backport and test it. Ross ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Error message about multiple EGL / GLES providers 2013-05-21 15:22 ` Burton, Ross @ 2013-05-21 16:47 ` Otavio Salvador 2013-05-21 16:57 ` Carlos Rafael Giani 1 sibling, 0 replies; 7+ messages in thread From: Otavio Salvador @ 2013-05-21 16:47 UTC (permalink / raw) To: OpenEmbedded Devel List On Tue, May 21, 2013 at 12:22 PM, Burton, Ross <ross.burton@intel.com>wrote: > On 21 May 2013 11:08, Carlos Rafael Giani <dv@pseudoterminal.org> wrote: > > It would > > be useful to instruct Mesa to turn off its OpenGLES and EGL support, > leaving > > Mesa only for GLX+Desktop OpenGL (software-rendered), if anybody really > > needs it. As an alternative, as you suggest, I could simply turn off > desktop > > OpenGL, but I have the feeling that this would be better off as a user > > decision that can be configured in the local.conf file. What do you > think? > > You can change mesa's PACKAGECONFIG to not build egl and gles. > meta-intel does something like this because the EMGD/CDT drivers are > in the same boat. > > However considering our software GL support in Mesa is currently > swrast (very very bad) and not llvmpipe (usable if you have enough > CPU, which we generally don't) you generally don't want to actually > have any OpenGL present at all. Generally it's mesa-demos that pulls > in virtual/libgl, and in master this can be disabled. This may be > worth a backport if someone wants to backport and test it. +1 -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Error message about multiple EGL / GLES providers 2013-05-21 15:22 ` Burton, Ross 2013-05-21 16:47 ` Otavio Salvador @ 2013-05-21 16:57 ` Carlos Rafael Giani 1 sibling, 0 replies; 7+ messages in thread From: Carlos Rafael Giani @ 2013-05-21 16:57 UTC (permalink / raw) To: openembedded-devel On 05/21/2013 05:22 PM, Burton, Ross wrote: > On 21 May 2013 11:08, Carlos Rafael Giani <dv@pseudoterminal.org> wrote: >> It would >> be useful to instruct Mesa to turn off its OpenGLES and EGL support, leaving >> Mesa only for GLX+Desktop OpenGL (software-rendered), if anybody really >> needs it. As an alternative, as you suggest, I could simply turn off desktop >> OpenGL, but I have the feeling that this would be better off as a user >> decision that can be configured in the local.conf file. What do you think? > You can change mesa's PACKAGECONFIG to not build egl and gles. > meta-intel does something like this because the EMGD/CDT drivers are > in the same boat. > > However considering our software GL support in Mesa is currently > swrast (very very bad) and not llvmpipe (usable if you have enough > CPU, which we generally don't) you generally don't want to actually > have any OpenGL present at all. Generally it's mesa-demos that pulls > in virtual/libgl, and in master this can be disabled. This may be > worth a backport if someone wants to backport and test it. > > Ross > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel Good point. It would also discourage people from using compositing managers which render using desktop OpenGL, then wondering why the 3D effects are so awfully slow. Same goes for stuff like Enlightenment Evas, which uses by default the desktop GL backend instead of the GLES one. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-05-21 16:57 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-05-20 18:18 Error message about multiple EGL / GLES providers Carlos Rafael Giani 2013-05-21 9:45 ` Burton, Ross 2013-05-21 10:08 ` Carlos Rafael Giani 2013-05-21 10:51 ` Paul Barker 2013-05-21 15:22 ` Burton, Ross 2013-05-21 16:47 ` Otavio Salvador 2013-05-21 16:57 ` Carlos Rafael Giani
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox