Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: Including machine specific mesa-driver
Date: Thu, 24 Sep 2015 07:50:55 +0100	[thread overview]
Message-ID: <1443077455.19044.55.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAP71WjyWRXrvUyi1HvdusRkKLb5Gf3H2gzCNPKkUDAstA4M55A@mail.gmail.com>

On Wed, 2015-09-23 at 22:38 -0700, Nicolas Dechesne wrote:
> in the qemu reference machine we see this pattern:
>
> XSERVER = "xserver-xorg
> \                                                                                                                                                                             
>            ${@bb.utils.contains('DISTRO_FEATURES', 'opengl',
> 'mesa-driver-swrast', '', d)}
> \                                                                                                          
>
> Which is what I had done for my BSP layer as well. However this
> doesn't take into account non X11 based graphics config, such as when
> building a wayland/weston image. The mesa-driver should be
> conditionally pulled when 'mesa' is pulled in.
>
> I cannot find a satisfying way of specifying this better to take both
> cases into account.
>
> we could move 
> ${@bb.utils.contains('DISTRO_FEATURES', 'opengl',
> 'mesa-driver-swrast', '', d)} 
>
> into MACHINE_RRDEPENS, but that's not quite right, since that driver
> is only needed when any of the mesa binary packages is in the image,
> and non graphics image wouldnt' need that.
>
> Since mesa produces a lot of binary packages , using RDEPENDS_xxx for
> all of them doesn't seem very nice neither..
>
> What would you recommend we do? I think we need to fix the qemu images
> anyways.

The idea was that the machine config can nominate the "X11" config it
needs by indicating the drivers that make sense for this piece of
hardware. The XSERVER variable is then used to decide which pieces of X
to pull in and pulling in the right mesa pieces at the same time made
sense then.

We could split the mesa pieces out into a separate MESADRIVERS variable
and the wayland/weston could just pull those in? Ultimately its still
the machine config which has the knowledge of which drivers make sense
for a given platform. Exactly which piece of the system would pull in
MESADRIVERS is a good question but I've not looked at the metadata just
thinking out loud.

Cheers,

Richard







  reply	other threads:[~2015-09-24  6:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-24  5:38 Including machine specific mesa-driver Nicolas Dechesne
2015-09-24  6:50 ` Richard Purdie [this message]
2015-09-24 18:36   ` Nicolas Dechesne
2015-09-24 20:17     ` Richard Purdie

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=1443077455.19044.55.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=nicolas.dechesne@linaro.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox