[Open-graphics] Re: Jumper count to disconnect DDC from DVI connector

[mykrowatt at comcast.net]

 -------------- Original message ----------------------
From: Jon Smirl <jonsmirl at gmail.com>

> If the monitor doesn't support DDC then there is nothing hooked up to the
> DDC pins on the DVI connector.

   That's not always the case.  One of the uses of the DDC tool in OGP development work is to override the data from a monitor that does support DDC.

 
> Another solution is for the external box to come with a small DVI breakout
> cable that plugs into the DVI port and splits off the DDC pins and passes
> the rest through. That would be the easiest solution since there is no
> need to provide another external connector.

   The project definitely has a requirement for a breakout cable, at least as a development tool.  However, it isn't going to just "come with" the external box.  Building that kind of cable right, so it doesn't degrade the analog signals, and doesn't let ESD in or RFI out, calls for specialized skills and tooling.  I've located a vendor who's willing to quote on building a custom breakout cable for OGP, and I have the task of writing up a spec, but it ain't gonna be cheap.  A stock top-quality DVI video cable goes for $50 to $75, depending on length.  That's twice the parts bill for the DDC box.  A custom cable is likely to cost considerably more.
   On the other hand, if we can bring out the DDC signals through the same header that provides the connection to the external SPI tools, we can connect it with a cheap ribbon cable that can be put together in a home workshop, or found on the shelf at local computer stores.  That's a much more attractive solution for a user who just needs to set a special video mode to break out of a chicken-and-egg deadlock.
   That's why I put some time into defining a common tool connector pinout that can be used in both the breakout cable and the back panel of the computer.  With the pinout thought out in advance, the same tool can plug in either way.  And so I had an action item from Tim, to find out how many signals would need to be disconnected on the board to let the tool override the monitor when connecting through the accessory header.


 
> All of this is has been talking about DDC2. I don't know electrically how
> DDC1 works but it is something that should be figured out. I think DDC1
> may modulate the DDC data onto either HSYNC or VSYNC signals somehow.

   I haven't looked into this either.  Presumably, if OGC1 is going to support DDC, it would be desirable to include DDC1, since that's a significant portion of the installed base.  Anybody here know anything about it?  Question: do we need a tool that can transmit arbitrary data in DDC1 format?  And if so, is it feasible to design a single tool that can transmit either DDC1 or DDC2 at will?

   And, another thought occurs to me.  Some types of SPI tool would have a lot of components in common with a DDC tool.  Since both sets of signals are going to be on the accessory header anyway (I'm willing to say that's a given), should we plan for a single tool design that can talk to both ports?

   Also, Tim, since it now seems to be settled that the host driver will have to be able to grab and interpret DDC data, which is logically similar to an X modeline though different in format, should we also give the driver the job of interpreting a more human-friendly binary modeline format from the DIPswitch version of the SPI tool?  Or was that what you had in mind to begin with?