Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

Alexander Kanavin
2022-10-26T18:01:45Z

Is there a combination of libmali recipe and mesa-gl somewhere public
so we could try to pick it apart and see what links to where?

My (perhaps confused) understanding is similar to Joshua's: 'gl' is
basically 'opengl in x11' or 'opengl rendered to memory', and if a
system uses neither, then it is not needed.

Alex

On Wed, 26 Oct 2022 at 19:48, Joshua Watt <jpewhacker@gmail.com> wrote:
>
> On Wed, Oct 26, 2022 at 12:21 PM Mark Hatle
> <mark.hatle@kernel.crashing.org> wrote:
> >
> >
> >
> > On 10/26/22 11:03 AM, Alexander Kanavin wrote:
> > > On Wed, 26 Oct 2022 at 16:35, Mark Hatle <mark.hatle@kernel.crashing.org> wrote:
> > >> (I just saw this, so a little late on the reply, but..)
> > >>
> > >> mesa-gl is ABSOLUTELY still being used. It's needed for libmali usage. Not
> > >> everyone wants to use lima support for graphics.
> > >>
> > >> It was broken into two separate packages so that is was VERY clear if you were
> > >> using mesa for 'everything' (mesa), or mesa JUST for 'gl' (not gles).
> > >
> > > Okay, I'm not going to propose this, but can you clarify, what is the
> > > current use for 'gl'? Is it just opengl 3d in standalone x server
> > > based systems (which is slowly dying), or is there something else to
> > > it?
>
> Are you specifically talking about libmali with the following statements?
>
> I would say that in general libmali is probably not doing things in
> the "normal" way if so, although I'm not trying to say that it isn't a
> legitimate way to do it.
>
> >
> > Anything that needs "OpenGL", i.e. Wayland/Weston, X11, Chromium, etc etc etc.
> > These all end up linking to a combination of libmali and mesa-gl.
>
> In general (maybe not for libmali) Wayland and Weston themselves don't
> use OpenGL, or mesa-gl. Individual clients may be able to use it,
> although it's rare in my (incomplete) experience. Most of the OpenGL
> users in Wayland/Weston are going through XWayland/X11 and using GLX.
>
> >
> > Pretty much anything that depends on 'virtual/gl' (vs virtual/libgles1,2,3).
> > libmali provides virtual/libgles1 and virtual/libgles2 and a few other things
> > that meta-gl doesn't.
> >
> > libmali also doesn't include the DRM/DRI parts. This comes from mesa-gl.
>
> In general, DRM/DRI doesn't come from mesa-gl. libdrm is its own
> recipe, and libgbm comes from mesa proper, or from some other
> dedicated vendor specific libgbm recipe.
>
>
> If this is sidetracking the discussion please ignore; I'm just a
> little confused by the above statements because either A) libmali is
> really weird B) my understanding of things is _way_ off, or C) the
> statements aren't quite correct.
>
> >
> > --Mark
> >
> > > Alex
> >
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > View/Reply Online (#172165): https://lists.openembedded.org/g/openembedded-core/message/172165
> > Mute This Topic: https://lists.openembedded.org/mt/94420106/3616693
> > Group Owner: openembedded-core+owner@lists.openembedded.org
> > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [JPEWhacker@gmail.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >