diff mbox

Including machine specific mesa-driver

Message ID CAP71WjzeJhjGNeYq8nKtR7BHPesdhcmyCb+1A+BeHhsp8Gh=tw@mail.gmail.com
State New
Headers show

Commit Message

Nicolas Dechesne Sept. 24, 2015, 6:36 p.m. UTC 
On Wed, Sep 23, 2015 at 11:50 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> 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.


right.

>
>
> 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.

it looks like it's either libGL (when using X/GLX) or libEGL that
would dynamically load the libary. So we might be able to do something
along these lines:

 MACHINE_FEATURES = "alsa bluetooth usbgadget screen"

 MACHINEOVERRIDES =. "qemuall:"

-------

how does that look like?

It's untested for now, btw.

Comments

Richard Purdie Sept. 24, 2015, 8:17 p.m. UTC | #1 
On Thu, 2015-09-24 at 11:36 -0700, Nicolas Dechesne wrote:
> On Wed, Sep 23, 2015 at 11:50 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > 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.
> 
> 
> right.
> 
> >
> >
> > 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.
> 
> it looks like it's either libGL (when using X/GLX) or libEGL that
> would dynamically load the libary. So we might be able to do something
> along these lines:
> 
> --- a/meta/conf/machine/include/qemu.inc
> +++ b/meta/conf/machine/include/qemu.inc
> @@ -5,12 +5,14 @@ PREFERRED_PROVIDER_virtual/libgles1 ?= "mesa"
>  PREFERRED_PROVIDER_virtual/libgles2 ?= "mesa"
> 
>  XSERVER ?= "xserver-xorg \
> -            ${@bb.utils.contains('DISTRO_FEATURES', 'opengl',
> 'mesa-driver-swrast', '', d)} \
>              xf86-input-evdev \
>              xf86-input-mouse \
>              xf86-video-fbdev \
>              xf86-input-keyboard"
> 
> +RDEPENDS_libgl-mesa = "${@bb.utils.contains('DISTRO_FEATURES',
> 'opengl', 'mesa-driver-swrast', '', d)}"
> +RDEPENDS_libegl-mesa = "${@bb.utils.contains('DISTRO_FEATURES',
> 'opengl', 'mesa-driver-swrast', '', d)}"
> +
>  MACHINE_FEATURES = "alsa bluetooth usbgadget screen"
> 
>  MACHINEOVERRIDES =. "qemuall:"
> 
> -------
> 
> how does that look like?
> 
> It's untested for now, btw.

It would make mesa machine specific which probably isn't what we
want :/.

Cheers,

Richard
diff mbox

Patch

--- a/meta/conf/machine/include/qemu.inc
+++ b/meta/conf/machine/include/qemu.inc
@@ -5,12 +5,14 @@  PREFERRED_PROVIDER_virtual/libgles1 ?= "mesa"
 PREFERRED_PROVIDER_virtual/libgles2 ?= "mesa"

 XSERVER ?= "xserver-xorg \
-            ${@bb.utils.contains('DISTRO_FEATURES', 'opengl',
'mesa-driver-swrast', '', d)} \
             xf86-input-evdev \
             xf86-input-mouse \
             xf86-video-fbdev \
             xf86-input-keyboard"

+RDEPENDS_libgl-mesa = "${@bb.utils.contains('DISTRO_FEATURES',
'opengl', 'mesa-driver-swrast', '', d)}"
+RDEPENDS_libegl-mesa = "${@bb.utils.contains('DISTRO_FEATURES',
'opengl', 'mesa-driver-swrast', '', d)}"
+