Re: [OE-core] [PATCH] mesa-gl: The purpose of mesa-gl is to provide for X11 usage

["Mark Hatle" <mark.hatle@kernel.crashing.org>]

> On Wed, Mar 25, 2020 at 02:27:37PM -0500, Mark Hatle wrote:
>> > To be honest, I would just take the entire recipe out. It's causing
>> > trouble
>> > during updates, isn't being tested neither for builds nor at runtime,
>> and
>> > is supposed to provide some specific configuration which as this
>> > discussion
>> > makes clear, nobody seems to quite understand.
>>
>> With the abomination that is libmali (and similar), it is still needed.
>> It's the only way to support GL on a primarily GLES compatible system.
>>
>> The problem is the way they do this seems to be a custom version of
>> libdrm, which then conflicts with the mesa version.  Thus the issues.
>>
>> I'm happy to continue testing my particular needs now and the future
>> (thus
>> the patch against master.)
>>...
>
> Stupid question:
>
> Is
>   PREFERRED_PROVIDER_virtual/mesa = "mesa-gl"
>   PREFERRED_PROVIDER_virtual/libgl = "mesa-gl"
> equivalent to
>   PACKAGECONFIG_pn-mesa = "opengl dri x11"
> ?

I don't know.  I didn't write this.

However, doing some investigation, the big difference here is the overall
capabilities.  There are common distributions where a user may want to use
mesa (no external libdrm) as well as distress where they want to use an
external drm and the mesa-gl version only.

So 'mesa' and 'external drm + mesa-gl' are equivalent in functionality for
a given distro.  Only difference being optimization.

You may ask why would I use one vs the other.  In my case, we have a
family of SoC parts.  Some of the family have a Mali graphics chip on
them, while others don't have any optimized graphics so everything has to
be software rendered.  The only difference (from a software point of view)
is if the Mali is on-board or not.  So using a common (binary)
distribution, and being able to just swap those parts is highly desirable.
 (Does that ACTUALLY work right now, I'm not sure.. but that is what I am
working on.)

>> --Mark
>
> cu
> Adrian
>