<div class="gmail_quote">On Thu, Sep 6, 2012 at 4:25 PM, Koen Kooi <span dir="ltr"><<a href="mailto:koen@dominion.thruhere.net" target="_blank">koen@dominion.thruhere.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Op 6 sep. 2012, om 15:04 heeft "Burton, Ross" <<a href="mailto:ross.burton@intel.com">ross.burton@intel.com</a>> het volgende geschreven:<br>
<div><div class="h5"><br>
> (CCing oe-core, discussion should happen there really)<br>
><br>
> On 6 September 2012 11:00, Andrei Gherzan <<a href="mailto:andrei@gherzan.ro">andrei@gherzan.ro</a>> wrote:<br>
>> In DISTRO_FEATURES we have opengl. That is pretty vague and generally we<br>
>> don't want to have mesa on machines where there is no libgl but only gles +<br>
>> egl. For example if we want to compile something that adds a DEPENDS based<br>
>> on DISTRO_FEATURE opengl, this dependency will be added even if there is no<br>
>> libgl implemented for that specific machine.<br>
>><br>
>> First idea would be that opengl (gl / gles) are machine related. On the<br>
>> other hand opengl can be a DISTRO_FEATURE as we have a software<br>
>> implementation - mesa.<br>
>><br>
>> How would you guys see a solution for this? The idea that came into my mind<br>
>> was to map opengl to libgl or libgles. Or to both if there is the case.<br>
><br>
> (First I must apologise for the uneven flow of this mail - my mornings<br>
> been pretty choppy but hopefully people can see what I'm thinking)<br>
><br>
> I've been thinking about this quite a lot recently, as the current<br>
> setup is broken in some way on most hardware. There is a bigger<br>
> problem than just distro or machine features - the packaging isn't<br>
> obvious or correct either.<br>
><br>
> First, we need a concrete definition of the "opengl" distro feature.<br>
> I propose just "some form of OpenGL functionality" without any<br>
> implications about what specification is present.<br>
><br>
> Then, machine features for the portions of OpenGL that the hardware<br>
> supports - gl, gles1, gles2. I'd love to say "gles" means GLESv2 but<br>
> I suspect we're not quite safe from the horrors of hardware that only<br>
> supports GLESv1 yet.<br>
><br>
> We then need more virtual providers for the GL libraries. Mesa is an<br>
> obvious provider - it provides libgl, libglesv1, libglesv2 and libegl.<br>
> On Raspberry Pi the binary drivers provide libglesv1, glesv2, and<br>
> egl. As the performance of the software renderer will be terrible,<br>
> unsetting the libgl provider makes a lot of sense.<br>
><br>
> Because there are multiple providers of the GL libraries, and they are<br>
> not all specific to a single machine, every package that provides GL<br>
> packages need to be namespaced. The Debian-renaming makes this<br>
> trickier but luckily it can be overridden in the recipe, so Mesa<br>
> should be building libgl-mesa, libegl-mesa, and so on. Every other<br>
> provider of the GL libraries should do this too.<br>
><br>
> Library dependencies are also broken, of course. A package that links<br>
> to libGL.so.1 shouldn't get a dependency on mesa-dri or whatever was<br>
> installed to provide that library, but a dependency on a virtual<br>
> "libgl" package. As far as I'm aware this isn't something that the<br>
> automatic shlibs dependency generation handles, but there is plenty of<br>
> prior art for this.<br>
<br>
</div></div>It's not automatic, but you can do something like this:<br>
<br>
<a href="http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=23b02134" target="_blank">http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=23b02134</a><br>
<br>
That recipe ships multiple copies of the libraries to account for different silicon revisions (the shader compiler will offload different things to the CPU), but we don't want the shlibs code to pickup the copies. So for mesa you can do:<br>
<br>
PRIVATE_LIBS_${PN}-dri = "libGL.so"<br>
RPROVIDES_${PN}-dri = $magic_python_function(PACKAGE_CONFIG, sometthing, something, libgl)<br>
<br>
And in the recipes that link to a GL lib you do:<br>
<br>
RDEPENDS_${PN} = "libGL"<br>
<br>
Which only leaves the DISTRO to sort out the runtime preferred provider, which is likely a conf file with a bunch of PACKAGE_CONFIG entries for all the machines the DISTRO wants to support.<br><br></blockquote><div>I'm not sure how this would work as there are recipes like libsdl with:</div>
<div>${@base_contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl', '', d)} </div><div><br></div><div>ag </div></div>