[OE-core] [oe-core 14/20] mesa-dri: introduce MACHINE_DRI_MODULES

[Martin Jansa]

On Thu, Oct 13, 2011 at 02:56:24PM +0100, Richard Purdie wrote:
> On Thu, 2011-10-13 at 15:32 +0200, Martin Jansa wrote:
> > On Thu, Oct 13, 2011 at 02:23:54PM +0100, Richard Purdie wrote:
> > > On Thu, 2011-10-13 at 13:30 +0200, Martin Jansa wrote:
> > > > * not everybody needs i915, i965
> > > > 
> > > > Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
> > > > ---
> > > >  meta/recipes-graphics/mesa/mesa-dri.inc     |    4 ++++
> > > >  meta/recipes-graphics/mesa/mesa-dri_7.11.bb |    2 --
> > > >  2 files changed, 4 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/meta/recipes-graphics/mesa/mesa-dri.inc b/meta/recipes-graphics/mesa/mesa-dri.inc
> > > > index 603438e..be6905c 100644
> > > > --- a/meta/recipes-graphics/mesa/mesa-dri.inc
> > > > +++ b/meta/recipes-graphics/mesa/mesa-dri.inc
> > > > @@ -6,6 +6,10 @@ DEFAULT_PREFERENCE = "-1"
> > > >  
> > > >  EXTRA_OECONF += "--with-driver=dri --disable-egl --disable-gallium --without-gallium-drivers"
> > > >  
> > > > +MACHINE_DRI_MODULES ?= ""
> > > > +PACKAGE_ARCH = "${@['${MACHINE_ARCH}','${TUNE_PKGARCH}'][bb.data.getVar('MACHINE_DRI_MODULES',d,1) == '']}"
> > > > +EXTRA_OECONF += "--with-dri-drivers=swrast,${MACHINE_DRI_MODULES}"
> > > > +
> > > >  python populate_packages_prepend() {
> > > >  	import os.path
> > > 
> > > Whilst I understand the problem, I don't like this solution.
> > > Particularly, it means that the meas-dri package needs to be marked as
> > > machine specific which I don't like the idea of at all.
> > > 
> > > How about we do this on a per architecture basis?
> > 
> > taken from cover-letter:
> > but maybe we can use it as distro variable and keep it with default arch.
> > But then we cannot just add ie glamo dri module from meta-openmoko like this:
> > http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=b50c8d00cf764c276b0792c0623b8eda3d18d343
> > without distro (setting MACHINE_DRI_MODULES) depending on such bsp layer.
> 
> Whilst I hadn't seen the patch I was guessing you were doing something
> like this. Will the glamo module build on all arm platforms or just
> gta02 specifically?

It should build on all arm platforms, but depends on another patch to
libdrm
http://git.shr-project.org/git/?p=meta-smartphone.git;a=commit;h=0a846fa3dec896751b44811cd909013874920aae
which should also build on all arm platforms.

I was using both patches for all machines (distr==SHR basis) in OE-classic, 
but with BSP layers I found it nice to keep them only in respective layer 
and now I would need to move them to upper layer again..

Regards,

> > per architecture has same problem as distro basis
> > 
> > btw: in old recipes there was --with-dri-drivers with only one -, so maybe it 
> > wasn't actually working even for i915, i965 before or configure has benevolent syntax
> 
> It defaults to enable all modules. We don't have libdrm-nouveau (or
> llvm) so we had to change the config options to explicitly enable the
> pieces I know are cared about on x86 in the latest version. This is why
> the COMPATIBLE_HOST is there too since that recipe was always meaning to
> compile these modules.
> 
> FWIW, if a patch needs some change in behaviour such as the introduction
> of a variable like MACHINE_DRI_MODULES, we need to spell this out very
> clearly. I know its better in this series but that was a major problem
> in the last version. I'm spelling this out for anyone else on the
> mailing list to take note of!
> 
> Cheers,
> 
> Richard
>  
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20111013/ebcf51b6/attachment-0002.sig>