(CCing oe-core, discussion should happen there really) On 6 September 2012 11:00, Andrei Gherzan <[email protected]> wrote: > In DISTRO_FEATURES we have opengl. That is pretty vague and generally we > don't want to have mesa on machines where there is no libgl but only gles + > egl. For example if we want to compile something that adds a DEPENDS based > on DISTRO_FEATURE opengl, this dependency will be added even if there is no > libgl implemented for that specific machine. > > First idea would be that opengl (gl / gles) are machine related. On the > other hand opengl can be a DISTRO_FEATURE as we have a software > implementation - mesa. > > How would you guys see a solution for this? The idea that came into my mind > was to map opengl to libgl or libgles. Or to both if there is the case.
(First I must apologise for the uneven flow of this mail - my mornings been pretty choppy but hopefully people can see what I'm thinking) I've been thinking about this quite a lot recently, as the current setup is broken in some way on most hardware. There is a bigger problem than just distro or machine features - the packaging isn't obvious or correct either. First, we need a concrete definition of the "opengl" distro feature. I propose just "some form of OpenGL functionality" without any implications about what specification is present. Then, machine features for the portions of OpenGL that the hardware supports - gl, gles1, gles2. I'd love to say "gles" means GLESv2 but I suspect we're not quite safe from the horrors of hardware that only supports GLESv1 yet. We then need more virtual providers for the GL libraries. Mesa is an obvious provider - it provides libgl, libglesv1, libglesv2 and libegl. On Raspberry Pi the binary drivers provide libglesv1, glesv2, and egl. As the performance of the software renderer will be terrible, unsetting the libgl provider makes a lot of sense. Because there are multiple providers of the GL libraries, and they are not all specific to a single machine, every package that provides GL packages need to be namespaced. The Debian-renaming makes this trickier but luckily it can be overridden in the recipe, so Mesa should be building libgl-mesa, libegl-mesa, and so on. Every other provider of the GL libraries should do this too. Library dependencies are also broken, of course. A package that links to libGL.so.1 shouldn't get a dependency on mesa-dri or whatever was installed to provide that library, but a dependency on a virtual "libgl" package. As far as I'm aware this isn't something that the automatic shlibs dependency generation handles, but there is plenty of prior art for this. Finally we can talk about packages. Take xorg-xserver, this can optionally support the GLX extension. If the opengl distro feature is set then it can pass --enable-glx (I've a patch for this[1] already). GLX requires GL so on Raspberry Pi this will mean building mesa and using the software renderer which really isn't a good idea, so that is a strong argument for making the xserver machine-specific and checking both the opengl distro feature *and* the gl machine feature. (side-note: GLX is deprecated, use EGL!) Maybe I need to spend tomorrow morning writing my scribbles down into something more organised on the wiki, after the collective wisdom of oe-core has pointed out why this plan is stupid. Cheers, Ross [1] http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/xorg&id=e7b034379026457f291356e181c6a9ecd7fdb23b _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
