[Xorg] MGA patches

[Ryan Underwood]

On Thu, Jul 22, 2004 at 08:50:15AM -0400, Alex Deucher wrote:
> 
> I can add this to my list as well, although I need to get my xorg tree
> building first (stupid imake) ;-)

Yeah, I haven't built Xorg yet either.  Actually, it was only recently
that I noticed that developers are hanging out here now instead of on
the XFree86 lists.

> > > This patch is more comprehensive, and adds support for the G-series
> > > Maven chip.  Through the Maven, it enables DDC and DPMS on the second
> > > head of a G400 as well as TV cable detection.  This is the first steps
> > > towards removing the dependency on the mga HAL library; from here we
> > > will have to figure out how to do mode setup through the Maven chip, but
> > > the current features seem compelling enough to me to request it to be
> > > included as-is.
> > >
> > > I've been running both these patches on my system for at least a month
> > > without any problems.  However, I seem to have some problems getting
> > > other people to test them.
> > 
> > This is pretty exciting.  What concerns do you have about this code at
> > this point?  Would any testing on a G400 singlehead help, and if so is
> > there any specific testing you would want done?

Unfortunately, this stuff is only for dualhead cards.  However, if you
were to procure a dualhead upgrade (or a DVI upgrade) I would be
extremely interested in the results.

I haven't any concerns about the current code except that it doesn't
break people's systems which are already working fine with mga_hal.
Eventually I want to ease out of mga_hal being a requirement at all.
I'm tired of dealing with the occasional really strange problems that I
can only chalk up to its presence.

Now that we can talk to the maven chip/cell, we can do mode setup for
monitor, TV, or DVI.  I have no idea how to detect a DVI port yet except
by using the PINS excrement that the BIOS leaves behind.  In fact, I
need to update the code to handle the newest PINS revisions found in the
newer cards, because that's the only way we can determine the hardware
capabilities.  (This stuff may not be externally detectable, only
flashed into the bios at the factory)

However, we can easily detect the TV cable and so do TV-based mode setup
when it is attached.  That mode setup code is yet to be written because
I just moved and haven't gotten my AV rig set back up yet (but you can
see your cable detected or not detected in the server log, yay!)

I could work on the second head mode CRT mode setup right now.
Unfortunately, it's really hard to do driver hacking on the same box I
use for day to day work.  I'd like to get another dualhead Matrox card
to put in my playground machine (which currently only has a single head
G400) but I can't afford it in the near future.  If anyone has a G400
DH, G400Max or G450 laying around that is available for medium term
loan, let me know.
 
> when I get my xorg tree in shape I can try this on my G550.  the only
> thing is, I only have 1 monitor with a vga connector.  my other one is
> DVI only.  What's odd is that when I use DVI only, the monitor works
> fine.  when I add the other monitor the server seems to go crazy. 
> perhaps you patch will help.

I think not.  Like I said, no mode setup at the moment so we're still
stuck with mga_hal.  The code can be written based on all the matroxfb
reverse engineering that Petr Vandrovec has already done (and has no
problems granting permission for X driver usage, if one felt the need to
flat out copy the code).

> One concern:  do your general i2c
> changes affect any other drivers?  I don't want to break anything else
> by accident.

The only change I recall is exposing a I2C function through the I2C
client structure.  I had to write custom functions to access the
Maven because it seems to have some strange ideas regarding the I2C
protocol.

-- 
Ryan Underwood, <nemesis at icequake.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20040722/cb5c9fb1/attachment.pgp>