mga driver / HALlib

Luc Verhaegen libv at skynet.be
Fri Jul 28 00:03:38 PDT 2006


On Fri, Jul 28, 2006 at 07:52:28AM +0200, Stefan Dirsch wrote:
> On Thu, Jul 27, 2006 at 10:11:49PM +0200, Luc Verhaegen wrote:
> > I doubt that the Xorg driver is still in sync with that binary and the 
> > codedrops matrox does or does not provide (not certain anymore). 
> 
> Right, AFAIK you need the HALlib of Matrox 4.1 driver. HALLib of 4.2
> doesn't seem to work (VT switching issues, blank screen).
> 
> > The 
> > reason for this not being backported could be any of the following:
> > * horrendous click-through license on any download from the matrox site.
> 
> Use ftp://ftp.matrox.com/pub/mga/archive/linux instead. :-)
> 

Pfff... Why. Why do you hang on to that nasty, in the face, 
click-through at one end when you're distributing freely on the other. 
Another shining example of sensible behaviour of a hardware vendor.

> > 
> > All it takes is for someone who is properly inclined to spend some 
> > quality time with the relevant hardware.
> 
> Sure. But here we're again at "* nobody cares enough". :-(

Which is the story for most of the X drivers. Activity wise, the mga 
driver probably already ranks 5th or 6th out of 44.

> What the
> users usually see is the regression in the driver. They don't care
> about the why and if this has been intentional and that there are good
> reasons for dropping support for features they simply used in the
> past. One of the results we can see now are HOWTO like this one
> 
>   http://www.tuxx-home.at/projects/mga/HOWTO_mga_Xorg7
> 
> which suggests to compile the HALlib into the mga driver !?!
> 

Yuck.

Well, if someone does fix it, he should add an X_NOTICE to MGAProbe 
as a constant reminder of how wonderful matrox is.

I'd personally choose for stripping out all support for the mga_hal 
binary from the Xorg driver, referring people straight to FB or matrox 
if unsupported features are detected or deemed likely. In my view this 
won't hamper future implementation, as enough should be known to make a 
clean start more efficient than replacing mga_hal calls and moulding or 
cleaning up afterwards.

Luc Verhaegen.



More information about the xorg mailing list