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

Darren Hart dvhart at linux.intel.com
Tue Sep 10 02:37:20 UTC 2013


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 at 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
Intel Open Source Technology Center
Yocto Project - Linux Kernel





More information about the Openembedded-core mailing list