All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Trevor Woerner" <twoerner@gmail.com>
To: Phil Blundell <pb@pbcl.net>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH] mesa.inc: add dispmanx support
Date: Thu, 10 Dec 2020 21:48:50 -0500	[thread overview]
Message-ID: <20201211024850.GA25551@localhost> (raw)
In-Reply-To: <20201204105141.GU30831@pbcl.net>

On Fri 2020-12-04 @ 11:51:41 AM, Phil Blundell wrote:
> On Thu, Dec 03, 2020 at 05:35:23PM -0500, Trevor Woerner wrote:
> > On Thu, Dec 3, 2020 at 5:25 PM Phil Blundell <pb@pbcl.net> wrote:
> > 
> > > If we're talking about OpenGLES applications, wouldn't you already have
> > > opengl in DISTRO_FEATURES?
> > >
> > 
> > Not necessarily.
> > 
> > Adding opengl to DISTRO_FEATURES really means "enable a bunch of
> > PACKAGECONFIGs all over the place because I need x11 and mesa with all the
> > bells and whistles".
> 
> It sounds like there are a few things that have gone wrong here then.
> Firstly, "opengl" in DISTRO_FEATURES isn't supposed to imply anything
> about x11.  If it does, that's just a bug. 

I have this bad habit of saying something specific when I actually mean to use
something as an example, sorry. I meant to say "if, for example, i'm building
an image for x11, and want opengl support…". As far as I can tell enabling
opengl in DISTRO_FEATURES doesn't imply x11 in any way, sorry :-)

> It should indeed enable opengl
> support in other recipes, though.  Can you give an example of the sort
> of thing that's getting enabled there that you don't want?

I am seeing an issue, but after quite a bit of testing and checking, I now
realize that the issue I was seeing is because of something a BSP layer is
doing and is not related to anything in core.

> But secondly, thinking about it again, there's no reason for mesa itself
> to require opengl in DISTRO_FEATURES anyway.  Mesa itself is what provides
> the GL API so it clearly doesn't depend on it.  I think that existing
> DISTRO_FEATURE check in mesa is just bogus and should be removed entirely.

Excellent, I agree.

If I understand it correctly, mesa can PROVIDE more than just the GL
interface; it can, for example, PROVIDE gbm which is useful for situations
where GL is provided via a binary (such as in my case with Raspberry Pi's
userland).

I'll send a patch.

Best regards,
	Trevor

      reply	other threads:[~2020-12-11  2:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-03 13:35 [PATCH] mesa.inc: add dispmanx support Trevor Woerner
2020-12-03 19:00 ` [OE-core] " Khem Raj
2020-12-03 21:54   ` Trevor Woerner
2020-12-03 22:02 ` Phil Blundell
2020-12-03 22:35   ` Trevor Woerner
2020-12-04 10:51     ` Phil Blundell
2020-12-11  2:48       ` Trevor Woerner [this message]

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=20201211024850.GA25551@localhost \
    --to=twoerner@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=pb@pbcl.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.