Re: egl libraries and binary drivers
On 04.04.2018 20:44, Wookey wrote:
> Hi X people (keep me cc:ed, I'm not on this list)
>
> I am confused about X dependencies, and am hoping you can clarify or
> point me at some docs. I know very little about X, despite having just
> packaged the mali drivers.
>
> My confusion is around libegl and how the dependencies should work,
> especially the virtual package libegl-x11.
>
> We have:
> libegl1-x11 (virtual package)
> libegl1 (from libglvnd). Vendor neutral GL dispatch library
>
> this latter depends on libegl-mesa0 | libegl-vendor
>
> The binary mali userspace driver (source:mali-midgard-driver) provides a
> /usr/lib/arm-linux-gnueabihf/libEGL.so.1
> which conflicts with libegl1
>
> currently that package conflicts with libegl1-x11, which I think was
> correct until recently, but it looks like it should conflict with
> libegl1 now instead. Is that right?
>
> AIUI the binary driver _could_ provide libegl-vendor, but that
> requires it to provide a libEGL_${VENDOR}.so.1 instead of libegl1.so.1
> (and do the right things internally). It doesn't yet do that, and I
> don't know when it will. It's not just a matter of renaming, right?
> I found this explanation which helped: https://lwn.net/Articles/518394/
> and this may be more up-to-date:
> https://github.com/aritger/linux-opengl-abi-proposal/blob/master/linux-opengl-abi-proposal.txt
>
> So, for the time being the mali driver is an old-fashion
> 'one-EGL-implementation-at-a-time' driver. What should it provide and
> conflict with?
>
> (And is this different on arches that support OPenGL rather than openGLES?)
>
> Apologies for my very vague understanding of this area. Any advice
> gratefully received.
You should probably just divert the conflicting libs, like fglrx/nvidia
used to do.
--
t
Reply to: