All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denys Dmytriyenko <denis@denix.org>
To: Christopher Larson <clarson@kergoth.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: mesa, libgbm and weston
Date: Mon, 25 Apr 2016 12:50:11 -0400	[thread overview]
Message-ID: <20160425165011.GV16135@denix.org> (raw)
In-Reply-To: <CABcZANmiDeW-B13vE3X0gjX_QfxV5iihD9ZnUKAU=wovnEuxBg@mail.gmail.com>

On Fri, Apr 22, 2016 at 12:27:16AM +0000, Christopher Larson wrote:
> On Thu, Apr 21, 2016 at 5:06 PM Denys Dmytriyenko <denis@denix.org> wrote:
> 
> > All,
> >
> > I've been meaning to ask this for quite some time. It appears that Weston's
> > DRM compositor enabled with "kms" PACKAGECONFIG doesn't really need the
> > entire
> > mesa, but it only needs libgbm. Now, mesa in OE-Core provides libgbm as
> > one of
> > its packages, hence virtual/mesa is added in DEPENDS for kms:
> >
> > PACKAGECONFIG[kms] = "--enable-drm-compositor,--disable-drm-compositor,drm
> > udev virtual/mesa mtdev"
> >
> > On TI platforms with SGX GPU we have GLES/EGL stack (provided by
> > proprietary
> > blobs, yeah) and a separate libgbm, based on Rob Clark's
> > https://github.com/robclark/libgbm
> > Since that is enough to run Weston on our platforms, I've been carrying
> > this
> > bbappend for long time:
> >
> > PACKAGECONFIG[kms] = "--enable-drm-compositor,--disable-drm-compositor,drm
> > udev libgbm mtdev"
> >
> > It's been working fine for long time, but people keep on asking questions
> > and
> > require cleaner solution, since bbappend in a separate layer is somewhat
> > confusing. Now, the question is what is a proper solution here:
> >
> > 1. Change weston recipe in oe-core to depend on libgbm instead of
> > virtual/mesa
> > assuming that it is provided by mesa recipe and it works for other
> > platforms.
> >
> 
> I'd say this, either libgbm or virtual/libgbm.
> 
> 2. Change our libgbm recipe to declare that it PROVIDES virtual/mesa,
> > although
> > it looks like a hack and is somewhat reverse...
> >
> 
> I think the libgbm recipe would basically be lying if you do that, that
> doesn't sound ideal.

Thanks, Chris.

One other thing I was thinking is how to avoid conflict between separate 
libgbm and the one provided by mesa-gl. As mesa-gl may be useful for providing 
SW rendering for OpenGL, while leaving OpenGLES to a separate provider, like 
SGX. Unfortunately, mesa-gl also provides libgbm - would PACKAGECONFIG to use 
a standalone external libgbm work and be acceptable here?

-- 
Denys


  reply	other threads:[~2016-04-25 16:50 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-22  0:05 mesa, libgbm and weston Denys Dmytriyenko
2016-04-22  0:27 ` Christopher Larson
2016-04-25 16:50   ` Denys Dmytriyenko [this message]
2016-04-26 11:59     ` Burton, Ross
2016-04-26 14:00       ` Burton, Ross
2016-04-26 14:27         ` Denys Dmytriyenko
2016-04-26 14:49           ` Otavio Salvador
2016-04-26 14:05       ` Denys Dmytriyenko
2016-04-26 11:36   ` Burton, Ross
2016-04-26 14:02     ` Denys Dmytriyenko
2016-04-26 19:06     ` Burton, Ross

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=20160425165011.GV16135@denix.org \
    --to=denis@denix.org \
    --cc=clarson@kergoth.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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.