[mythtv-users] Component video adapters

[Mike Isely]

On Thu, 9 Dec 2004, Cory Papenfuss wrote:

> > I'm curious about these cheaper adapters though.  To do YPbPr video means
> > an electrical conversion is required, which is what the 9A60 does.  But
> > these adapters mentioned above may be different.  Is it that the Radeon
> > 8500 (and related boards) already have the needed conversion circuits and
> > that the adapter just provides the mechanical plug conversion?  That would
> > explain why the adapter only is rated to work with specific ATI cards.
> > And if that is the case, then I imagine there is some kind of driver
> > aspect to this to get the card to generate YPbPr compatible signals -
> > which I guess is why another poster here suggests that the adapters listed
> > above currently don't work in Linux.
> >
>  	Strictly speaking, a video card output is nothing more than three
> DACs.  Whether the digital data that's sent to them is RGB or YPbPr
> doesn't matter, so it probably primarily a driver issue.  There are some
> slight hardware requirements on the video card (DAC max voltage,
> sync-on-[GY], etc), but the "circuitry" isn't really necessary as it is
> in the A960.  Remember that MPEG *is* YUV... the color transformation to
> RGB and back to YUV shouldn't even have to be done.

Makes sense.  I hadn't thought of that.  So aside from multiplexing the
H&V sync, the rest of the problem is just a matter of transforming the
frame buffer contents.  Doh!


>
> > modes are supported by the HDTV monitor (since there's no way for EDID
> > data to be located in that case).  Anyone have any experience with this or
> > a pointer to documentation about it (beyond the PDF listed on the svideo
> > page)?
>
>  	Why not?  IIRC the monitor ID info is sent as a serial bitstream
> on one of the pins.  Why can't the driver be "told" it's a HDTV with the
> adapter?  Seems reasonable.

The component video cable has no allowance for the clock & data signals
needed for EDID which is what I was refering too.  Thus the monitor itself
can't tell the driver anything.  But I see now that perhaps this adapter
might possibly have an 8051 in it with an on-chip I2C transceiver.  Then
the dip switches are just a few discrete inputs to some GPIO pins on the
8051 and the rest of the solution amounts to just a software issue in the
8051...

  -Mike


-- 
                        |         Mike Isely          |     PGP fingerprint
    POSITIVELY NO       |                             | 03 54 43 4D 75 E5 CC 92
 UNSOLICITED JUNK MAIL! |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                        |                             |