mesa-dri: Enable swrast only by default and intel drivers only on IA platform

Signed-off-by Richard Purdie <[email protected]>

---

meta/recipes-graphics/mesa/mesa-dri.inc +0 -0

index 603438e..795144a 100644
@@ -4,7 +4,11 @@ LIB_DEPS += "libdrm expat"
  # most of our targets do not have DRI so will use mesa-xlib

 DEFAULT_PREFERENCE = "-1"

meta/recipes-graphics/mesa/mesa-dri.inc +5 -1

-EXTRA_OECONF += "--with-driver=dri --disable-egl --disable-gallium --without-gallium-drivers"
+DRIDRIVERS = "swrast"
+DRIDRIVERS_x86 = "swrast,i915,i965"
+DRIDRIVERS_x86-64 = "swrast,i915,i965"
+
+EXTRA_OECONF += "--with-driver=dri --disable-egl --disable-gallium --without-gallium-drivers --with-dri-drivers=${DRIDRIVERS}"

 python populate_packages_prepend() {
       import os.path

meta/recipes-graphics/mesa/mesa-dri_7.11.bb +0 -0

index 6a4f9a9..5d25127 100644
@@ -2,7 +2,3 @@ include mesa-common.inc

 include mesa-${PV}.inc
 include mesa-dri.inc
 PR = "${INC_PR}.0"

meta/recipes-graphics/mesa/mesa-dri_7.11.bb +0 -4

-
-EXTRA_OECONF += "--with-dri-drivers=swrast,i915,i965"
-
-COMPATIBLE_HOST = '(i.86.*-linux|x86_64.*-linux)'

meta/recipes-graphics/mesa/mesa-dri_git.bb +0 -0

index 15cde60..a0e1945 100644
@@ -7,5 +7,3 @@ DEFAULT_PREFERENCE = "-2"
 

 PR = "${INC_PR}.0"

meta/recipes-graphics/mesa/mesa-dri_git.bb +0 -2

-COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
-

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

+1

Just another thing, I'd prefer to have DRIDRIVERS as ?= so machine can override it.

Quoted 4 lines · Otavio Salvador

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

Quoted 10 lines · Otavio Salvador

Quoted 4 lines

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

Quoted 1 line

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?

Regards,

Signature · 5 lines

Martin 'JaMa' Jansa     jabber: [email protected]
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 10 lines · Richard Purdie

Quoted 4 lines · Otavio Salvador

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

Quoted 1 line

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?

Quoted 16 lines · Martin Jansa

Quoted 11 lines · Richard Purdie

Quoted 4 lines · Otavio Salvador

+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)?

Quoted 2 lines

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.

Quoted 20 lines · Richard Purdie

Quoted 18 lines · Martin Jansa

Quoted 11 lines · Richard Purdie

Quoted 4 lines · Otavio Salvador

+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?

Quoted 3 lines

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 ?

Quoted 25 lines · Martin Jansa

Quoted 23 lines · Richard Purdie

Quoted 11 lines · Martin Jansa

Quoted 10 lines · Richard Purdie

Quoted 4 lines · Otavio Salvador

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

Quoted 7 lines

Quoted 1 line

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.

Quoted 3 lines

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.

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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Quoted 30 lines · Richard Purdie

Quoted 28 lines · Martin Jansa

Quoted 17 lines · Richard Purdie

Quoted 16 lines · Martin Jansa

Quoted 11 lines · Richard Purdie

Quoted 4 lines · Otavio Salvador

+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)?

Quoted 6 lines

Quoted 2 lines

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 ?

Quoted 3 lines

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.