[Openchrome-users] DVI-02 funkiness

[Philip Prindeville]

Some of the issues with the read timings on the
DVI-02 rev B (Sil164) went away when I replaced
it with a DVI-02 rev C (VT1632).

I'm not sure if that means that the I2C code isn't
solid in the Openchrome tree, or if the card requires
odd-ball timing that isn't documented anywhere
(perhaps Jon can ask around)... or if the card is
simply poorly designed.

Was wondering... Thomas and Dave... can the
Openchrome driver be modified to use the sub-
module DVO API?

(Dave: the source tree is at: http://svn.openchrome.org/svn/trunk )


The idea being that the encoder/transmitters can be made
modular, and released more often... as well as being used
"mix and match" with different GPU's (since it's possible
to have a VIA GPU with a SIL encoder, etc).

One shortcoming of the current DVO API is highlighted
by the way that the via_vt162x.c code is structured: a
generic detect routine probes a chip from the chip
family...  but the remaining vectors in the API init,
mode-valid, mode-sense, save-regs, restore-regs,
power-on/off, etc. are then chip-specific.

The "I830I2CVidOutputRec" structure is just a global
static...  I suppose there's no reason why the "detect"
routine can't populate the rest of the structure's
vectors, right?

Thomas:  what methods are required to add support
for TV encoders?  DACSense...  ModeI2C (not sure
what exactly this all does... it seems to do various
things)...  ModeCrtc...  am I missing anything?

We could expand the API to support both DVO/TMDS
transmitters and TV encoders... perhaps adding a
discriminator to the structure that says what sort
it is... (i.e. to allow for variant subclasses)
*
*-Philip*


*