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