[PATCH 1/2] mesa: use distro_features_check to abort build without opengl feature

[PATCH 1/2] mesa: use distro_features_check to abort build without opengl feature

[Ross Burton]

Stop mesa from building on distributions without the "opengl" DISTRO_FEATURE.

Signed-off-by: Ross Burton <ross.burton@intel.com>
---
 meta/recipes-graphics/mesa/mesa.inc |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 71fcabd..79605fa 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -19,7 +19,9 @@ DEPENDS = "expat makedepend-native flex-native bison-native"
 
 PROVIDES = "virtual/libgl virtual/libgles1 virtual/libgles2 virtual/egl"
 
-inherit autotools pkgconfig pythonnative gettext
+inherit autotools pkgconfig pythonnative gettext distro_features_check
+
+REQUIRED_DISTRO_FEATURES = "opengl"
 
 EXTRA_OECONF = "--enable-shared-glapi"
 
-- 
1.7.10.4

[PATCH 2/2] xf86-video-intel: allow builds without opengl, add more options

[Ross Burton]

Allow builds without the opengl DISTRO_FEATURE by disabling DRI.

Also add new options for UXA (not default upstream, requires DRI) and udev
(enabled by default)

Finally remove a few obsolete dependencies.

Signed-off-by: Ross Burton <ross.burton@intel.com>
---
 meta/recipes-graphics/xorg-driver/xf86-video-intel_2.21.13.bb |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.21.13.bb b/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.21.13.bb
index 54c4d17..f26544b 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.21.13.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.21.13.bb
@@ -9,11 +9,14 @@ Infrastructure (DRI)."
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=8730ad58d11c7bbad9a7066d69f7808e"
 
-DEPENDS += "virtual/libx11 drm xf86driproto glproto \
-            virtual/libgl xineramaproto libpciaccess udev"
+DEPENDS += "virtual/libx11 drm libpciaccess pixman"
 
-PACKAGECONFIG ??= ""
+PACKAGECONFIG ??= "sna udev ${@base_contains('DISTRO_FEATURES', 'opengl', 'dri', '', d)}"
+
+PACKAGECONFIG[dri] = "--enable-dri,--disable-dri,xf86driproto dri2proto"
 PACKAGECONFIG[sna] = "--enable-sna,--disable-sna"
+PACKAGECONFIG[uxa] = "--enable-uxa,--disable-uxa"
+PACKAGECONFIG[udev] = "--enable-udev,--disable-udev,udev"
 PACKAGECONFIG[xvmc] = "--enable-xvmc,--disable-xvmc,libxvmc"
 
 # --enable-kms-only option is required by ROOTLESS_X
-- 
1.7.10.4

Re: [PATCH 1/2] mesa: use distro_features_check to abort build without opengl feature

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]

On Mon, Sep 09, 2013 at 11:19:11AM +0100, Ross Burton wrote:
> Stop mesa from building on distributions without the "opengl" DISTRO_FEATURE.
> 
> Signed-off-by: Ross Burton <ross.burton@intel.com>
> ---
>  meta/recipes-graphics/mesa/mesa.inc |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
> index 71fcabd..79605fa 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -19,7 +19,9 @@ DEPENDS = "expat makedepend-native flex-native bison-native"
>  
>  PROVIDES = "virtual/libgl virtual/libgles1 virtual/libgles2 virtual/egl"
>  
> -inherit autotools pkgconfig pythonnative gettext
> +inherit autotools pkgconfig pythonnative gettext distro_features_check
> +
> +REQUIRED_DISTRO_FEATURES = "opengl"

Is this really needed? I was building mesa in distro without opengl for
long time and was considering (probably incorrectly) opengl DISTRO_FEATURE more
like sign of proper hw GL libraries.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [PATCH 1/2] mesa: use distro_features_check to abort build without opengl feature

[Burton, Ross]

On 9 September 2013 13:08, Martin Jansa <martin.jansa@gmail.com> wrote:
>> +REQUIRED_DISTRO_FEATURES = "opengl"
>
> Is this really needed? I was building mesa in distro without opengl for
> long time and was considering (probably incorrectly) opengl DISTRO_FEATURE more
> like sign of proper hw GL libraries.

I'd always understood the "opengl" DISTRO_FEATURE to mean "give me GL
support".  *What* that means depends on the target hardware, could be
entirely software rendering through Mesa or binary HW drivers.

Ross

Re: [PATCH 1/2] mesa: use distro_features_check to abort build without opengl feature

[Burton, Ross]

On 9 September 2013 13:12, Burton, Ross <ross.burton@intel.com> wrote:
> I'd always understood the "opengl" DISTRO_FEATURE to mean "give me GL
> support".  *What* that means depends on the target hardware, could be
> entirely software rendering through Mesa or binary HW drivers.

Forgot to say the rationale for the check is the same as the libX11
DISTRO_FEATURES check: a distribution asking for no opengl shouldn't
be building a GL stack, and aborting if that happens ensures that the
appropriate checks are in place.

Ross

Re: [PATCH 1/2] mesa: use distro_features_check to abort build without opengl feature

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

On Mon, Sep 09, 2013 at 01:16:44PM +0100, Burton, Ross wrote:
> On 9 September 2013 13:12, Burton, Ross <ross.burton@intel.com> wrote:
> > I'd always understood the "opengl" DISTRO_FEATURE to mean "give me GL
> > support".  *What* that means depends on the target hardware, could be
> > entirely software rendering through Mesa or binary HW drivers.
> 
> Forgot to say the rationale for the check is the same as the libX11
> DISTRO_FEATURES check: a distribution asking for no opengl shouldn't
> be building a GL stack, and aborting if that happens ensures that the
> appropriate checks are in place.

OK fair enough, thanks for explanation, it's time to add opengl in my
DISTRO_FEATURES if I haven't done it already :).

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [PATCH 1/2] mesa: use distro_features_check to abort build without opengl feature

[Nicolas Dechesne]

[-- Attachment #1: Type: text/plain, Size: 1971 bytes --]

On Mon, Sep 9, 2013 at 2:12 PM, Burton, Ross <ross.burton@intel.com> wrote:

> On 9 September 2013 13:08, Martin Jansa <martin.jansa@gmail.com> wrote:
> >> +REQUIRED_DISTRO_FEATURES = "opengl"
> >
> > Is this really needed? I was building mesa in distro without opengl for
> > long time and was considering (probably incorrectly) opengl
> DISTRO_FEATURE more
> > like sign of proper hw GL libraries.
>
> I'd always understood the "opengl" DISTRO_FEATURE to mean "give me GL
> support".  *What* that means depends on the target hardware, could be
> entirely software rendering through Mesa or binary HW drivers.


how about gl vs gles?

i have been trying to understand over the last couple of days whether or
not 'opengl' in DISTRO_FEATURES means OpenGL and OpenGLES. I don't think
it's clearly indicated anywhere.

in libsdl recipe, we have this:

DEPENDS = "${@base_contains('DISTRO_FEATURES', 'directfb', 'directfb', '',
d)} \

           ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
'', d)} \

and in EXTRA_OECONF we add this:
${@base_contains('DISTRO_FEATURES', 'opengl', '--enable-video-opengl',
'--disable-video-opengl', d)} \


which tends to make me think that 'opengl' means 'OpenGL', not OpenGLES. I
am building for ARM platforms with GLes support, but no GL support. I
initially had 'opengl' in DISTRO_FEATURES, but we ended with mesa being
pulled in because of libsdl, which was wrong. So we now removed 'opengl'
from our DISTRO_FEATURES list. (note we have our own EGL/GLes library for
GPU, so we don't want mesa at all).

In weston recipe, we have this:
${@base_contains('DISTRO_FEATURES', 'opengles2', 'gles', '', d)}

so, that seems to imply that opengles2 is now a 'new' DISTRO_FEATURES, but
it's only used once (looking at oe-core and meta-oe).

To me having 2 different flags for opengl and opengles in DISTRO_FEATURES
does make sense...  but i could be wrong..

what do you think?

[-- Attachment #2: Type: text/html, Size: 3643 bytes --]

Re: [PATCH 1/2] mesa: use distro_features_check to abort build without opengl feature

[Burton, Ross]

On 9 September 2013 13:40, Nicolas Dechesne <nicolas.dechesne@linaro.org> wrote:
> how about gl vs gles?

The problem of any patch that touches the opengl distro feature is
that it causes this discussion, because the semantics of it are rather
vague to say the least!

> i have been trying to understand over the last couple of days whether or not
> 'opengl' in DISTRO_FEATURES means OpenGL and OpenGLES. I don't think it's
> clearly indicated anywhere.

My personal opinion is it means "enable support for the OpenGL
collection of APIs, include OpenGL, GLES and/or EGL".  Last year there
was a patch series from the early Wayland enabling that added machine
features for each form of GL, but that wasn't finished or merged (not
entirely required).

> in libsdl recipe, we have this:
>
> DEPENDS = "${@base_contains('DISTRO_FEATURES', 'directfb', 'directfb', '',
> d)} \
>            ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
> '', d)} \
>
> and in EXTRA_OECONF we add this:
> ${@base_contains('DISTRO_FEATURES', 'opengl', '--enable-video-opengl',
> '--disable-video-opengl', d)} \
>
> which tends to make me think that 'opengl' means 'OpenGL', not OpenGLES. I
> am building for ARM platforms with GLes support, but no GL support. I
> initially had 'opengl' in DISTRO_FEATURES, but we ended with mesa being
> pulled in because of libsdl, which was wrong. So we now removed 'opengl'
> from our DISTRO_FEATURES list. (note we have our own EGL/GLes library for
> GPU, so we don't want mesa at all).

OpenGL-wrangling aside, that's a pretty good example of where
PACKAGECONFIG should be used so your configuration can easily tweak
SDL without changing distro features.

> In weston recipe, we have this:
> ${@base_contains('DISTRO_FEATURES', 'opengles2', 'gles', '', d)}
>
> so, that seems to imply that opengles2 is now a 'new' DISTRO_FEATURES, but
> it's only used once (looking at oe-core and meta-oe).

Not sure what I was thinking there, potentially a bad search and
replace.  As you say its the only instance of that feature.  Patch
incoming to fix that.

I'm happy for DISTRO_FEATURES to be vague and just mean the GL
collection instead of specific implementations, because OpenGL/GLX vs
GLESv2/EGL etc is a machine-specific feature and encoding that into
DISTRO_FEATURES would mean changing the distro features when the
machine changes, which is obviously wrong.  We may need some
machine-level hints as to the GL feature set available for recipes
that don't probe at runtime.

Ross

Re: [PATCH 1/2] mesa: use distro_features_check to abort build without opengl feature

[Nicolas Dechesne]

[-- Attachment #1: Type: text/plain, Size: 3859 bytes --]

On Mon, Sep 9, 2013 at 3:17 PM, Burton, Ross <ross.burton@intel.com> wrote:

> > how about gl vs gles?
>
> The problem of any patch that touches the opengl distro feature is
> that it causes this discussion, because the semantics of it are rather
> vague to say the least!
>
> > i have been trying to understand over the last couple of days whether or
> not
> > 'opengl' in DISTRO_FEATURES means OpenGL and OpenGLES. I don't think it's
> > clearly indicated anywhere.
>
> My personal opinion is it means "enable support for the OpenGL
> collection of APIs, include OpenGL, GLES and/or EGL".  Last year there
> was a patch series from the early Wayland enabling that added machine
> features for each form of GL, but that wasn't finished or merged (not
> entirely required).
>
> > in libsdl recipe, we have this:
> >
> > DEPENDS = "${@base_contains('DISTRO_FEATURES', 'directfb', 'directfb',
> '',
> > d)} \
> >            ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
> > '', d)} \
> >
> > and in EXTRA_OECONF we add this:
> > ${@base_contains('DISTRO_FEATURES', 'opengl', '--enable-video-opengl',
> > '--disable-video-opengl', d)} \
> >
> > which tends to make me think that 'opengl' means 'OpenGL', not OpenGLES.
> I
> > am building for ARM platforms with GLes support, but no GL support. I
> > initially had 'opengl' in DISTRO_FEATURES, but we ended with mesa being
> > pulled in because of libsdl, which was wrong. So we now removed 'opengl'
> > from our DISTRO_FEATURES list. (note we have our own EGL/GLes library for
> > GPU, so we don't want mesa at all).
>
> OpenGL-wrangling aside, that's a pretty good example of where
> PACKAGECONFIG should be used so your configuration can easily tweak
> SDL without changing distro features.
>

well, if opengl means gl or gles, then doing something like this should be
considered wrong (bug):

> ${@base_contains('DISTRO_FEATURES', 'opengl', '--enable-video-opengl',
> '--disable-video-opengl', d)} \

since here it's clear that opengl means gl, not gles. it clearly breaks on
machine where opengl means gles and no gl support is available (here i am
considering pulling mesa as a bug, since we probably don't want it on
embedded devices).


>
> > In weston recipe, we have this:
> > ${@base_contains('DISTRO_FEATURES', 'opengles2', 'gles', '', d)}
> >
> > so, that seems to imply that opengles2 is now a 'new' DISTRO_FEATURES,
> but
> > it's only used once (looking at oe-core and meta-oe).
>
> Not sure what I was thinking there, potentially a bad search and
> replace.  As you say its the only instance of that feature.  Patch
> incoming to fix that.
>
> I'm happy for DISTRO_FEATURES to be vague and just mean the GL
> collection instead of specific implementations, because OpenGL/GLX vs
> GLESv2/EGL etc is a machine-specific feature and encoding that into
> DISTRO_FEATURES would mean changing the distro features when the
> machine changes, which is obviously wrong.


well, i am not quite convinced that GL/GLX vs GLes/EGL really is machine
specific. It might have been the case before, but more and more i think
this is becoming a 'distro' (or stack, or product?) preference. things like
Qt5 or wayland now enforce the need for gles, so to me this is no longer
machine dependent. Without GLES on your machine you can't run them anymore.



>  We may need some
> machine-level hints as to the GL feature set available for recipes
> that don't probe at runtime.


yes, i agree. we need to know what machines can do GL, GLX, EGL, GLES, and
what distro 'need/expect' and combine the 2 sets (and use mesa as fallback
when needed, or even we should be able to prohibit mesa too). we could get
such thing using opengl and opengles flags in DISTRO_ and
MACHINES_FEATURES.. but it's not quite nice.

[-- Attachment #2: Type: text/html, Size: 5477 bytes --]

Re: [PATCH 1/2] mesa: use distro_features_check to abort build without opengl feature

[Nicolas Dechesne]

hi,

On Mon, Sep 9, 2013 at 2:40 PM, Nicolas Dechesne
<nicolas.dechesne@linaro.org> wrote:
> On Mon, Sep 9, 2013 at 2:12 PM, Burton, Ross <ross.burton@intel.com> wrote:
>>
>> On 9 September 2013 13:08, Martin Jansa <martin.jansa@gmail.com> wrote:
>> >> +REQUIRED_DISTRO_FEATURES = "opengl"
>> >
>> > Is this really needed? I was building mesa in distro without opengl for
>> > long time and was considering (probably incorrectly) opengl
>> > DISTRO_FEATURE more
>> > like sign of proper hw GL libraries.
>>
>> I'd always understood the "opengl" DISTRO_FEATURE to mean "give me GL
>> support".  *What* that means depends on the target hardware, could be
>> entirely software rendering through Mesa or binary HW drivers.
>
>
> how about gl vs gles?
>
> i have been trying to understand over the last couple of days whether or not
> 'opengl' in DISTRO_FEATURES means OpenGL and OpenGLES. I don't think it's
> clearly indicated anywhere.
>
> in libsdl recipe, we have this:
>
> DEPENDS = "${@base_contains('DISTRO_FEATURES', 'directfb', 'directfb', '',
> d)} \
>            ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
> '', d)} \
>
> and in EXTRA_OECONF we add this:
> ${@base_contains('DISTRO_FEATURES', 'opengl', '--enable-video-opengl',
> '--disable-video-opengl', d)} \

back on this topic... something is weird. as i said above, we built
our OE based distro for ARM platform with *no* GL support, but with
GLES support. As soon as we pull libav in our images it DEPENS on
virtual/libsdl, and as mentioned above libdsl with 'opengl' in
DISTRO_FEATURES will end up with adding dependency on virtual/libgl
which we don't want (and don't have on our platform).

how do we get around this problem?

i am still not convinced that we should treat GL and GLES with a
single 'DISTRO_FEATURE' since they aren't 'equivalent' features. I
understand we need a mechanism to say if the platforms has 'graphics'
support, and for some recipes 'graphics' is enough, but especially for
libsdl this isn't enough since on GLES platforms we don't want
--enable-video-opengl to be enabled since that is a GL feature, not
GLES.

thanks

Re: [PATCH 1/2] mesa: use distro_features_check to abort build without opengl feature

[Burton, Ross]

On 23 October 2013 09:53, Nicolas Dechesne <nicolas.dechesne@linaro.org> wrote:
> i am still not convinced that we should treat GL and GLES with a
> single 'DISTRO_FEATURE' since they aren't 'equivalent' features. I
> understand we need a mechanism to say if the platforms has 'graphics'
> support, and for some recipes 'graphics' is enough, but especially for
> libsdl this isn't enough since on GLES platforms we don't want
> --enable-video-opengl to be enabled since that is a GL feature, not
> GLES.

I don't think anyone thinks that the current opengl feature is
sufficient but there hasn't been a good enough alternative just yet.
Are you proposing that the "opengl" distro feature is re-purposed as
"OpenGL", and we add "opengles" for "OpenGLES".  Does this need to be
GLES-version-specific, what about EGL, and what about machines which
can support multiple drivers/GPU hardware?

Ross

Re: [PATCH 1/2] mesa: use distro_features_check to abort build without opengl feature

[Nicolas Dechesne]

On Wed, Oct 23, 2013 at 11:00 AM, Burton, Ross <ross.burton@intel.com> wrote:
> On 23 October 2013 09:53, Nicolas Dechesne <nicolas.dechesne@linaro.org> wrote:
>> i am still not convinced that we should treat GL and GLES with a
>> single 'DISTRO_FEATURE' since they aren't 'equivalent' features. I
>> understand we need a mechanism to say if the platforms has 'graphics'
>> support, and for some recipes 'graphics' is enough, but especially for
>> libsdl this isn't enough since on GLES platforms we don't want
>> --enable-video-opengl to be enabled since that is a GL feature, not
>> GLES.
>
> I don't think anyone thinks that the current opengl feature is
> sufficient but there hasn't been a good enough alternative just yet.
> Are you proposing that the "opengl" distro feature is re-purposed as
> "OpenGL", and we add "opengles" for "OpenGLES".  Does this need to be
> GLES-version-specific, what about EGL, and what about machines which
> can support multiple drivers/GPU hardware?

well, that's more or less what I had said in that thread earlier. e.g.
make opengl vs opengles 2 distinct "DISTRO_FEATURE". at least what's
sure now, is that currently it is broken, libsdl is the only instance
we have noticed the problem, there could be more, not sure.

i agree that we could easily extend the number of combos... but we
could start 'small' and add new 'feature' whenever needed. the problem
is probably even more subtle... right now opengl is a DISTRO_FEATURE
to say globally if the 'distro/stack' we build has some sort of
graphics.. if we start getting into EGL, GLX, and GL/GLES versions
then we start going into machine features.

a quick grep (in the layers i use) reveals that the situation isn't
really too good ;-)

-- meta-openembedded/meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb:PACKAGECONFIG
??= "${@base_contains('DISTRO_FEATURES', 'opengl', 'opengl',
'openglesv2', d)}"
-- meta-openembedded/meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb:
   ${@base_contains('DISTRO_FEATURES', 'opengl', '--enable-gl',
'--enable-gles', d)} \

here, we use opengl distro feature to switch between GL and GLES

-- meta-qt5/recipes-qt/qt5/qtbase.inc:PACKAGECONFIG_GL ?=
"${@base_contains('DISTRO_FEATURES', 'opengl', 'gl', '', d)}"

here, opengl is used to enable GL , nothing about GLES. in our layer,
we have added a .bbapend with this to get Qt to work:

# By default, qtbase.inc PACKAGECONFIG_GL is either "gl" (if DISTRO_FEATURES
# includes "opengl") or empty (if it doesn't). Over-ride and force to "gles2".
PACKAGECONFIG_GL = "gles2"

-- openembedded-core/meta/conf/machine/include/ia32-base.inc:
 ${@base_contains('DISTRO_FEATURES', 'opengl',
'xserver-xorg-extension-glx', '', d)} \

here, used to enable GLX

-- openembedded-core/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb:
       ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
'', d)} \
-- openembedded-core/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb:
            ${@base_contains('DISTRO_FEATURES', 'opengl',
'--enable-video-opengl', '--disable-video-opengl', d)} \

here to enable GL features, incompatible with GLES.

-- openembedded-core/meta/recipes-graphics/wayland/weston_1.1.0.bb:
               ${@base_contains('DISTRO_FEATURES', 'opengles2',
'gles', '', d)} \

here, we have an instance of opengles2, which we discussed already.
that's the only place where we have that, and you agreed it was a bug.

-- openembedded-core/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.21.13.bb:PACKAGECONFIG
??= "sna udev ${@base_contains('DISTRO_FEATURES', 'opengl', 'dri', '',
d)}"
-- openembedded-core/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc:PACKAGECONFIG
??= "udev ${@base_contains('DISTRO_FEATURES', 'opengl', 'dri dri2
glx', '', d)}"

to enable GLX/DRI

-- openembedded-core/meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb:DEPENDS
+= " ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
'', d)}"

another instance, like libsdl which would break on GLES only platform.

-- openembedded-core/meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb:
           ${@base_contains('DISTRO_FEATURES', 'opengl',
'--enable-webgl', '--disable-webgl', d)} \

here to enable WebGL

So i think given these examples, it's difficult to 'define' what
opengl DISTRO_FEATURE means. it is used for many different things, so
maybe this isn't the 'right level of abstraction'. what do you think?


ps: sorry, i have the feeling that gmail is going to mess up very
badly with the formatting of this email...

Re: [PATCH 1/2] mesa: use distro_features_check to abort build without opengl feature

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 5585 bytes --]

Even if there is separate DISTRO_FEATURE for gles, we still have problem
that the same distribution can support MACHINEs with different support for
*gl*.

You still cannot build the same TUNE_PKGARCH qtbase package where once it's
used for MACHINE where you have only mesa as *gl* provider and for
different MACHINE which has binary blob for gles2. DISTRO_FEATUREs can
contain only common denominator for features available in all supported
MACHINEs. Splitting it to 2 separate features doesn't help with this.

And if we cannot build TUNE_PKGARCH qtbase we would need to make also
qtwebkit MACHINE_ARCH and I really don't like it, because of webkit build
time :/.


On Wed, Oct 23, 2013 at 11:25 AM, Nicolas Dechesne <
nicolas.dechesne@linaro.org> wrote:

> On Wed, Oct 23, 2013 at 11:00 AM, Burton, Ross <ross.burton@intel.com>
> wrote:
> > On 23 October 2013 09:53, Nicolas Dechesne <nicolas.dechesne@linaro.org>
> wrote:
> >> i am still not convinced that we should treat GL and GLES with a
> >> single 'DISTRO_FEATURE' since they aren't 'equivalent' features. I
> >> understand we need a mechanism to say if the platforms has 'graphics'
> >> support, and for some recipes 'graphics' is enough, but especially for
> >> libsdl this isn't enough since on GLES platforms we don't want
> >> --enable-video-opengl to be enabled since that is a GL feature, not
> >> GLES.
> >
> > I don't think anyone thinks that the current opengl feature is
> > sufficient but there hasn't been a good enough alternative just yet.
> > Are you proposing that the "opengl" distro feature is re-purposed as
> > "OpenGL", and we add "opengles" for "OpenGLES".  Does this need to be
> > GLES-version-specific, what about EGL, and what about machines which
> > can support multiple drivers/GPU hardware?
>
> well, that's more or less what I had said in that thread earlier. e.g.
> make opengl vs opengles 2 distinct "DISTRO_FEATURE". at least what's
> sure now, is that currently it is broken, libsdl is the only instance
> we have noticed the problem, there could be more, not sure.
>
> i agree that we could easily extend the number of combos... but we
> could start 'small' and add new 'feature' whenever needed. the problem
> is probably even more subtle... right now opengl is a DISTRO_FEATURE
> to say globally if the 'distro/stack' we build has some sort of
> graphics.. if we start getting into EGL, GLX, and GL/GLES versions
> then we start going into machine features.
>
> a quick grep (in the layers i use) reveals that the situation isn't
> really too good ;-)
>
> -- meta-openembedded/meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb:
> PACKAGECONFIG
> ??= "${@base_contains('DISTRO_FEATURES', 'opengl', 'opengl',
> 'openglesv2', d)}"
> -- meta-openembedded/meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb:
>    ${@base_contains('DISTRO_FEATURES', 'opengl', '--enable-gl',
> '--enable-gles', d)} \
>
> here, we use opengl distro feature to switch between GL and GLES
>
> -- meta-qt5/recipes-qt/qt5/qtbase.inc:PACKAGECONFIG_GL ?=
> "${@base_contains('DISTRO_FEATURES', 'opengl', 'gl', '', d)}"
>
> here, opengl is used to enable GL , nothing about GLES. in our layer,
> we have added a .bbapend with this to get Qt to work:
>
> # By default, qtbase.inc PACKAGECONFIG_GL is either "gl" (if
> DISTRO_FEATURES
> # includes "opengl") or empty (if it doesn't). Over-ride and force to
> "gles2".
> PACKAGECONFIG_GL = "gles2"
>
> -- openembedded-core/meta/conf/machine/include/ia32-base.inc:
>  ${@base_contains('DISTRO_FEATURES', 'opengl',
> 'xserver-xorg-extension-glx', '', d)} \
>
> here, used to enable GLX
>
> -- openembedded-core/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb:
>        ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
> '', d)} \
> -- openembedded-core/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb:
>             ${@base_contains('DISTRO_FEATURES', 'opengl',
> '--enable-video-opengl', '--disable-video-opengl', d)} \
>
> here to enable GL features, incompatible with GLES.
>
> -- openembedded-core/meta/recipes-graphics/wayland/weston_1.1.0.bb:
>                ${@base_contains('DISTRO_FEATURES', 'opengles2',
> 'gles', '', d)} \
>
> here, we have an instance of opengles2, which we discussed already.
> that's the only place where we have that, and you agreed it was a bug.
>
> --
> openembedded-core/meta/recipes-graphics/xorg-driver/xf86-video-intel_2.21.13.bb:
> PACKAGECONFIG
> ??= "sna udev ${@base_contains('DISTRO_FEATURES', 'opengl', 'dri', '',
> d)}"
> --
> openembedded-core/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc:PACKAGECONFIG
> ??= "udev ${@base_contains('DISTRO_FEATURES', 'opengl', 'dri dri2
> glx', '', d)}"
>
> to enable GLX/DRI
>
> -- openembedded-core/meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb:DEPENDS
> += " ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',
> '', d)}"
>
> another instance, like libsdl which would break on GLES only platform.
>
> -- openembedded-core/meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb:
>            ${@base_contains('DISTRO_FEATURES', 'opengl',
> '--enable-webgl', '--disable-webgl', d)} \
>
> here to enable WebGL
>
> So i think given these examples, it's difficult to 'define' what
> opengl DISTRO_FEATURE means. it is used for many different things, so
> maybe this isn't the 'right level of abstraction'. what do you think?
>
>
> ps: sorry, i have the feeling that gmail is going to mess up very
> badly with the formatting of this email...
>

[-- Attachment #2: Type: text/html, Size: 7358 bytes --]