From: Mark Hatle <mark.hatle@kernel.crashing.org>
To: Alexander Kanavin <alex.kanavin@gmail.com>
Cc: Ross Burton <ross.burton@arm.com>, Khem Raj <raj.khem@gmail.com>,
Kai Kang <kai.kang@windriver.com>,
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable
Date: Wed, 26 Oct 2022 12:20:33 -0500 [thread overview]
Message-ID: <4070adb4-bfb0-9d96-2193-c8f8386383e9@kernel.crashing.org> (raw)
In-Reply-To: <CANNYZj_KT77PhQtPd3gTT4J9RWZNnY0UgvH_PmOZXNs+yewM6Q@mail.gmail.com>
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?
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.
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.
--Mark
> Alex
next prev parent reply other threads:[~2022-10-26 17:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-18 23:08 [PATCH v2] mesa: Add native patch via a variable Khem Raj
2022-10-19 5:42 ` [OE-core] " Alexander Kanavin
2022-10-19 6:34 ` Khem Raj
2022-10-19 6:54 ` Alexander Kanavin
2022-10-19 15:04 ` Khem Raj
[not found] ` <171F65F5948858B5.6129@lists.openembedded.org>
2022-10-19 10:35 ` Alexander Kanavin
2022-10-26 14:34 ` Mark Hatle
2022-10-26 16:03 ` Alexander Kanavin
2022-10-26 17:20 ` Mark Hatle [this message]
2022-10-26 17:48 ` Joshua Watt
2022-10-26 18:01 ` Alexander Kanavin
2022-10-27 0:46 ` Mark Hatle
2022-10-28 10:59 ` Alexander Kanavin
2022-10-28 18:01 ` Mark Hatle
2022-10-26 20:58 ` Mark Hatle
2022-10-19 15:29 ` Ross Burton
2022-10-19 16:04 ` Alexander Kanavin
2022-10-26 14:13 ` Richard Purdie
2022-10-19 16:05 ` Martin Jansa
2022-10-21 21:59 ` Khem Raj
[not found] ` <171F61FEE1540458.9064@lists.openembedded.org>
2022-10-19 5:50 ` Alexander Kanavin
2022-10-19 5:55 ` Kai
2022-10-19 5:58 ` Martin Jansa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4070adb4-bfb0-9d96-2193-c8f8386383e9@kernel.crashing.org \
--to=mark.hatle@kernel.crashing.org \
--cc=alex.kanavin@gmail.com \
--cc=kai.kang@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
--cc=ross.burton@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox