Patchwork [3/4] xf86-video-mga: Pull in Matrox MGA support from meta-intel

login
register
mail settings
Submitter Darren Hart
Date Sept. 5, 2013, 12:18 a.m.
Message ID <4562a00806c5a6573b5aa650764ad12bc93edda7.1378339881.git.dvhart@linux.intel.com>
Download mbox | patch
Permalink /patch/57377/
State New
Headers show

Comments

Darren Hart - Sept. 5, 2013, 12:18 a.m.
In support of the more generic x86 BSPs, pull in the Matrox driver
recipe from meta-intel.

Remove the checkfile patch from Ross as this is now handled adequately
with the configure prepend hack which assumes success for any checkfile
calls.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Ross Burton <ross.burton@intel.com>
Cc: Nitin A Kamble <nitin.a.kamble@intel.com>
---
 meta/conf/machine/include/ia32-base.inc            |    2 ++
 .../xorg-driver/xf86-video-mga_1.6.2.bb            |   20 ++++++++++++++++++++
 2 files changed, 22 insertions(+)
 create mode 100644 meta/recipes-graphics/xorg-driver/xf86-video-mga_1.6.2.bb
Ross Burton - Sept. 5, 2013, 9:57 a.m.
On 5 September 2013 01:18, Darren Hart <dvhart@linux.intel.com> wrote:
> In support of the more generic x86 BSPs, pull in the Matrox driver
> recipe from meta-intel.

What machine is this for in particular?  In discussion with Nitin
about MGA a few weeks back the conclusion was that the vesa driver
should be sufficient.  As far as I'm aware the reference platforms
don't ship with MGA hardware so it's up to the owner of the platform
to install whatever they have to hand (mga, nvidia, ATI, etc), or am I
wrong about that?

> Remove the checkfile patch from Ross as this is now handled adequately
> with the configure prepend hack which assumes success for any checkfile
> calls.

Assuming success in an distro where opengl isn't enabled will result
in the driver believing that DRI is enabled when it isn't, so expect
to see build failures from this.

Ross
Tom Zanussi - Sept. 5, 2013, 1:04 p.m.
On Thu, 2013-09-05 at 10:57 +0100, Burton, Ross wrote:
> On 5 September 2013 01:18, Darren Hart <dvhart@linux.intel.com> wrote:
> > In support of the more generic x86 BSPs, pull in the Matrox driver
> > recipe from meta-intel.
> 
> What machine is this for in particular?  In discussion with Nitin
> about MGA a few weeks back the conclusion was that the vesa driver
> should be sufficient.  As far as I'm aware the reference platforms
> don't ship with MGA hardware so it's up to the owner of the platform
> to install whatever they have to hand (mga, nvidia, ATI, etc), or am I
> wrong about that?
> 

It's my understanding that some of these server-type systems like Romley
and Crystal Forest have on-chip graphics disabled and ship with ancient
MGA graphics, which apparently we have a cheap source of chips for...

Probably vesa would work for these systems, cc'ing those in the know...

Tom

> > Remove the checkfile patch from Ross as this is now handled adequately
> > with the configure prepend hack which assumes success for any checkfile
> > calls.
> 
> Assuming success in an distro where opengl isn't enabled will result
> in the driver believing that DRI is enabled when it isn't, so expect
> to see build failures from this.
> 
> Ross
Darren Hart - Sept. 5, 2013, 2:52 p.m.
On Thu, 2013-09-05 at 10:57 +0100, Burton, Ross wrote:
> On 5 September 2013 01:18, Darren Hart <dvhart@linux.intel.com> wrote:
> > In support of the more generic x86 BSPs, pull in the Matrox driver
> > recipe from meta-intel.
> 
> What machine is this for in particular?

This was reported when someone was testing on a Romley machine.

>   In discussion with Nitin
> about MGA a few weeks back the conclusion was that the vesa driver
> should be sufficient.  As far as I'm aware the reference platforms
> don't ship with MGA hardware so it's up to the owner of the platform
> to install whatever they have to hand (mga, nvidia, ATI, etc), or am I
> wrong about that?

Nitin?

Yunguo?

> 
> > Remove the checkfile patch from Ross as this is now handled adequately
> > with the configure prepend hack which assumes success for any checkfile
> > calls.
> 
> Assuming success in an distro where opengl isn't enabled will result
> in the driver believing that DRI is enabled when it isn't, so expect
> to see build failures from this.

Should we be adding a distro depends on opengl for this driver as is
being done for others currently?
Ross Burton - Sept. 5, 2013, 3:11 p.m.
On 5 September 2013 15:52, Darren Hart <dvhart@linux.intel.com> wrote:
>> Assuming success in an distro where opengl isn't enabled will result
>> in the driver believing that DRI is enabled when it isn't, so expect
>> to see build failures from this.
>
> Should we be adding a distro depends on opengl for this driver as is
> being done for others currently?

No, because DRI is optional in this driver.  Follow opengl and flip
--enable/disable-dri.

(assuming I don't change the server to always build DRI)

Ross
Ross Burton - Sept. 5, 2013, 3:21 p.m.
On 5 September 2013 16:11, Burton, Ross <ross.burton@intel.com> wrote:
> On 5 September 2013 15:52, Darren Hart <dvhart@linux.intel.com> wrote:
>>> Assuming success in an distro where opengl isn't enabled will result
>>> in the driver believing that DRI is enabled when it isn't, so expect
>>> to see build failures from this.
>>
>> Should we be adding a distro depends on opengl for this driver as is
>> being done for others currently?
>
> No, because DRI is optional in this driver.  Follow opengl and flip
> --enable/disable-dri.
>
> (assuming I don't change the server to always build DRI)

Follow-up.  Using PACKAGECONFIG to respecting the "opengl"
DISTRO_FEATURE and --enable/--disable-dri should work for the MGA
driver.  dri.h is part of Mesa, so obviously opengl and DRI are
entwined.

Ross
Darren Hart - Sept. 10, 2013, 2:37 a.m.
On Fri, 2013-09-06 at 09:30 +0800, Yunguo Wei wrote:
> On 09/05/2013 10:52 PM, Darren Hart wrote:
> > On Thu, 2013-09-05 at 10:57 +0100, Burton, Ross wrote:
> >> On 5 September 2013 01:18, Darren Hart <dvhart@linux.intel.com> wrote:
> >>> In support of the more generic x86 BSPs, pull in the Matrox driver
> >>> recipe from meta-intel.
> >> What machine is this for in particular?
> > This was reported when someone was testing on a Romley machine.
> 
> Yes, it is Intel SDP S2R3, Romley-EP IVY refresh.
> >
> >>    In discussion with Nitin
> >> about MGA a few weeks back the conclusion was that the vesa driver
> >> should be sufficient.  As far as I'm aware the reference platforms
> >> don't ship with MGA hardware so it's up to the owner of the platform
> >> to install whatever they have to hand (mga, nvidia, ATI, etc), or am I
> >> wrong about that?
> > Nitin?
> >
> > Yunguo?
> 
> We thought vesa is supposed to work.
> 
> Intel OSVe team reported this problem against WRLinux 5.0.1, and I fixed 
> it by adding mga package.
> Note that, mga kernel driver was not built-in or as a module.

I missed that the kernel module was missing. Oops. That's easy enough to
add to the common-pc graphics fragment. But what we need to know is if
we should try to get MGA into oe-core or not. I honestly don't
understand why we shouldn't, with intel and omap in there already. It
seems silly to have a special layer for the xorg driver when mesa and
the kernel already build their part for the same hardware....

Are there any compelling arguments for not including the mga driver in
oe-core?

> 
> 
> Regards,
> Yunguo
> >
> >>> Remove the checkfile patch from Ross as this is now handled adequately
> >>> with the configure prepend hack which assumes success for any checkfile
> >>> calls.
> >> Assuming success in an distro where opengl isn't enabled will result
> >> in the driver believing that DRI is enabled when it isn't, so expect
> >> to see build failures from this.
> > Should we be adding a distro depends on opengl for this driver as is
> > being done for others currently?
> >
>
Darren Hart - Sept. 10, 2013, 5:54 p.m.
On Tue, 2013-09-10 at 12:01 +0800, Yunguo Wei wrote:
> On 09/10/2013 10:37 AM, Darren Hart wrote:
> > On Fri, 2013-09-06 at 09:30 +0800, Yunguo Wei wrote:
> >> On 09/05/2013 10:52 PM, Darren Hart wrote:
> >>> On Thu, 2013-09-05 at 10:57 +0100, Burton, Ross wrote:
> >>>> On 5 September 2013 01:18, Darren Hart <dvhart@linux.intel.com> wrote:
> >>>>> In support of the more generic x86 BSPs, pull in the Matrox driver
> >>>>> recipe from meta-intel.
> >>>> What machine is this for in particular?
> >>> This was reported when someone was testing on a Romley machine.
> >> Yes, it is Intel SDP S2R3, Romley-EP IVY refresh.
> >>>>     In discussion with Nitin
> >>>> about MGA a few weeks back the conclusion was that the vesa driver
> >>>> should be sufficient.  As far as I'm aware the reference platforms
> >>>> don't ship with MGA hardware so it's up to the owner of the platform
> >>>> to install whatever they have to hand (mga, nvidia, ATI, etc), or am I
> >>>> wrong about that?
> >>> Nitin?
> >>>
> >>> Yunguo?
> >> We thought vesa is supposed to work.
> >>
> >> Intel OSVe team reported this problem against WRLinux 5.0.1, and I fixed
> >> it by adding mga package.
> >> Note that, mga kernel driver was not built-in or as a module.
> > I missed that the kernel module was missing. Oops. That's easy enough to
> > add to the common-pc graphics fragment. But what we need to know is if
> > we should try to get MGA into oe-core or not. I honestly don't
> > understand why we shouldn't, with intel and omap in there already. It
> > seems silly to have a special layer for the xorg driver when mesa and
> > the kernel already build their part for the same hardware....
> Not sure if adding MGA to config fragment could fix this issue, but in 
> my memory it was not working.
> That's why I added MGA user space package.
> 
> But you can try, any Romley-EP machine could reproduce it.

I don't have one personally. Nitin, could you forward this information
along to someone who does? Can they test with Vesa?

--
Darren

> 
> Regards,
> Yunguo
> 
> >
> > Are there any compelling arguments for not including the mga driver in
> > oe-core?
> >
> >>
> >> Regards,
> >> Yunguo
> >>>>> Remove the checkfile patch from Ross as this is now handled adequately
> >>>>> with the configure prepend hack which assumes success for any checkfile
> >>>>> calls.
> >>>> Assuming success in an distro where opengl isn't enabled will result
> >>>> in the driver believing that DRI is enabled when it isn't, so expect
> >>>> to see build failures from this.
> >>> Should we be adding a distro depends on opengl for this driver as is
> >>> being done for others currently?
> >>>
>

Patch

diff --git a/meta/conf/machine/include/ia32-base.inc b/meta/conf/machine/include/ia32-base.inc
index cb542a5..e13cfca 100644
--- a/meta/conf/machine/include/ia32-base.inc
+++ b/meta/conf/machine/include/ia32-base.inc
@@ -45,6 +45,8 @@  XSERVER_IA32_I965 = "xf86-video-intel \
            mesa-driver-i965 \
            "
 
+XSERVER_IA32_MATROX_MGA = "xf86-video-mga"
+
 XSERVER_IA32_VESA = "xf86-video-vesa"
 
 XSERVER_IA32_FBDEV = "xf86-video-fbdev"
diff --git a/meta/recipes-graphics/xorg-driver/xf86-video-mga_1.6.2.bb b/meta/recipes-graphics/xorg-driver/xf86-video-mga_1.6.2.bb
new file mode 100644
index 0000000..3fc2c77
--- /dev/null
+++ b/meta/recipes-graphics/xorg-driver/xf86-video-mga_1.6.2.bb
@@ -0,0 +1,20 @@ 
+require recipes-graphics/xorg-driver/xorg-driver-video.inc
+
+SUMMARY = "X.Org X server -- Matrox MGA display driver"
+
+DESCRIPTION = "mga is an Xorg driver for Matrox video cards"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=bc1395d2cd32dfc5d6c57d2d8f83d3fc"
+
+DEPENDS += "virtual/libx11 drm xf86driproto glproto virtual/libgl libpciaccess"
+
+EXTRA_OECONF += "--enable-dri"
+
+PR = "r1"
+
+COMPATIBLE_HOST = '(i.86.*-linux|x86_64.*-linux)'
+
+SRC_URI[md5sum] = "f543877db4e260d8b43c7da3095605ed"
+SRC_URI[sha256sum] = "3f89ce250eea93f0de890954687790e06c0bab9e3e303df393e8759a187eca6c"
+
+RDEPENDS_${PN} = "xserver-xorg-module-exa"