[OE-core] [PATCH] mesa-dri: Enable swrast only by default and intel drivers only on IA platform

Khem Raj raj.khem at gmail.com
Fri Oct 14 22:53:25 UTC 2011


On Fri, Oct 14, 2011 at 3:15 PM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Fri, 2011-10-14 at 18:05 +0200, Martin Jansa wrote:
>> On Fri, Oct 14, 2011 at 04:55:50PM +0100, Richard Purdie wrote:
>> > On Fri, 2011-10-14 at 17:30 +0200, Martin Jansa wrote:
>> > > On Fri, Oct 14, 2011 at 04:25:16PM +0100, Richard Purdie wrote:
>> > > > On Fri, 2011-10-14 at 11:46 -0300, Otavio Salvador wrote:
>> > > > > +1
>> > > > >
>> > > > > Just another thing, I'd prefer to have DRIDRIVERS as ?= so machine can
>> > > > > override it.
>> > > >
>> > > > I really wouldn't recommend overriding this on a per machine basis, it
>> > > > needs to be on a per arch basis. This is because the recipe is not
>> > > > machine specific (nor should it be).
>> > > >
>> > > > Configuration therefore falls to the distro, not machine.
>> > >
>> > > Why not make it machine specific only when machine provides own module
>> > > (like the case with glamo on om-gta02)?
>> > >
>> > > Or recipe cannot change PACKAGE_ARCH in some special cases (like
>> > > $MACHINE in path to some file in SRC_URI) anymore?
>> >
>> > It works just fine but its not nice practise in my opinion for a library
>> > like this and I don't see there is any need in this case. Certainly I
>> > don't see it as something OE-Core should be recommending.
>>
>> So can I send patches adding my glamo.patch to libdrm and mesa-dri so we
>> can add glamo to
>> DRIDRIVERS_armv4t ?
>
> No, what I mean is if the layer containing that machine appends those
> patches for arm in general (or armv4t), you can then enable the dri
> drivers for armv4t in general to.

but there can be more than 1 armv4t machines in different layers.

>
> It means you would have to keep the layer enabled whenever generating
> armv4t feeds but I think that is ok as long as you know about it?
>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>




More information about the Openembedded-core mailing list