<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 9, 2013 at 3:17 PM, Burton, Ross <span dir="ltr"><<a href="mailto:ross.burton@intel.com" target="_blank">ross.burton@intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">> how about gl vs gles?<br>
<br>
</div>The problem of any patch that touches the opengl distro feature is<br>
that it causes this discussion, because the semantics of it are rather<br>
vague to say the least!<br>
<div class="im"><br>
> i have been trying to understand over the last couple of days whether or not<br>
> 'opengl' in DISTRO_FEATURES means OpenGL and OpenGLES. I don't think it's<br>
> clearly indicated anywhere.<br>
<br>
</div>My personal opinion is it means "enable support for the OpenGL<br>
collection of APIs, include OpenGL, GLES and/or EGL". Last year there<br>
was a patch series from the early Wayland enabling that added machine<br>
features for each form of GL, but that wasn't finished or merged (not<br>
entirely required).<br>
<div class="im"><br>
> in libsdl recipe, we have this:<br>
><br>
> DEPENDS = "${@base_contains('DISTRO_FEATURES', 'directfb', 'directfb', '',<br>
> d)} \<br>
> ${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl',<br>
> '', d)} \<br>
><br>
> and in EXTRA_OECONF we add this:<br>
> ${@base_contains('DISTRO_FEATURES', 'opengl', '--enable-video-opengl',<br>
> '--disable-video-opengl', d)} \<br>
><br>
> which tends to make me think that 'opengl' means 'OpenGL', not OpenGLES. I<br>
> am building for ARM platforms with GLes support, but no GL support. I<br>
> initially had 'opengl' in DISTRO_FEATURES, but we ended with mesa being<br>
> pulled in because of libsdl, which was wrong. So we now removed 'opengl'<br>
> from our DISTRO_FEATURES list. (note we have our own EGL/GLes library for<br>
> GPU, so we don't want mesa at all).<br>
<br>
</div>OpenGL-wrangling aside, that's a pretty good example of where<br>
PACKAGECONFIG should be used so your configuration can easily tweak<br>
SDL without changing distro features.<br></blockquote><div><br></div><div>well, if opengl means gl or gles, then doing something like this should be considered wrong (bug):</div><div><br></div><div><span style="color:rgb(80,0,80)">> ${@base_contains('DISTRO_</span><span style="color:rgb(80,0,80)">FEATURES', 'opengl', '--enable-video-opengl',</span><br style="color:rgb(80,0,80)">
<span style="color:rgb(80,0,80)">> '--disable-video-opengl', d)} \</span><br style="color:rgb(80,0,80)"></div><div><br></div><div>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> In weston recipe, we have this:<br>
> ${@base_contains('DISTRO_FEATURES', 'opengles2', 'gles', '', d)}<br>
><br>
> so, that seems to imply that opengles2 is now a 'new' DISTRO_FEATURES, but<br>
> it's only used once (looking at oe-core and meta-oe).<br>
<br>
</div>Not sure what I was thinking there, potentially a bad search and<br>
replace. As you say its the only instance of that feature. Patch<br>
incoming to fix that.<br>
<br>
I'm happy for DISTRO_FEATURES to be vague and just mean the GL<br>
collection instead of specific implementations, because OpenGL/GLX vs<br>
GLESv2/EGL etc is a machine-specific feature and encoding that into<br>
DISTRO_FEATURES would mean changing the distro features when the<br>
machine changes, which is obviously wrong. </blockquote><div><br></div><div>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> We may need some<br>
machine-level hints as to the GL feature set available for recipes<br>
that don't probe at runtime.</blockquote></div><br>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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>