On Mon, Aug 28, 2006 at 06:23:15PM -0700, James Richard Tyrer wrote:
> Timothy Miller wrote:
> >On 8/27/06, Jack Carroll <[EMAIL PROTECTED]> wrote:
> >>The DDC injection box sounds like a very interesting solution to
> >>one class of configuration and test problems. It's probably a
> >>useful test tool in its own right, for checking out the system's
> >>behavior with DDC codes. Am I right in thinking that it's not a
> >>general solution to configuring all possible arbitrary modes
> >>directly from timing specs or modeline-style data?
> >
> >I think EDID is able to specify detailed timing numbers. What would
> >be missing?
>
> http://www.vesa.org/Public/EEDIDguideV1.pdf
>
> http://en.wikipedia.org/wiki/EDID
>
> It appears to have all the ability of an X modeline:
<big snip>
I finally got around to taking a look at these references. A few
thoughts...
The EDID format is pretty complicated, with all the options it
offers. But I2C is something else altogether. It's been some years since I
read anything about the I2C electrical interface, but as I recall, its
complexity goes beyond the realm of the outrageous into the diabolical. Not
something we should be eager to implement ourselves.
Nevertheless, there's a pretty strong argument for giving OGC1 the
ability to grab EDID from the monitor and pass it to the BIOS, as one of
the card's basic features.
The pragmatic way to implement I2C might be to look around for a
microcontroller that has a built-in I2C port. Let that talk to the I2C PROM
in the monitor, and pass the data in a more digestible protocol (such as
parallel or SPI) to the TRV10. There are better things to do with the TRV10's
high-speed logic than re-implement a horribly complicated low-speed protocol
that's only used during initialization -- and that kind of low-end embedded
microcontroller is really, really cheap. I know there's a desire to avoid
adding microcomputers to the board, but doing I2C off-chip could save both
money and development time. The same microcontroller might be used in the
external DDC tool.
One good thing abut I2C is that it's a one-wire signal channel.
Coping with the problems of such aggressive pincount reduction is why the
protocol has to be so complicated. But it means that only one jumper has to
be moved, to reroute the signal from the DVI connector to a test tool
header.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
