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

[mykrowatt at comcast.net]

 -------------- Original message ----------------------
From: "Timothy Miller" <theosib at gmail.com>
> On 9/8/06, mykrowatt at comcast.net <mykrowatt at comcast.net> wrote:
> 
> >    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?
> 
> This work can be done anywhere.  BIOS, kernel driver, X11 driver.
> Perhaps in multiple places at different times.
> 
> I think the major issue of contention was whether or not we could do
> this before ANY sort of driver (or BIOS code) had started up.

   I was rather startled at the idea that a system that relies on the graphics display for a debugging and configuration console could rely on software executing on the host for its own initial configuration, without creating a chicken-and-egg deadlock -- at least in the early stages of system integration.  However, you have actual experience with this sort of thing, so I have to defer to that.
   We may yet find that it would be worthwhile to write an application note for the TRV10, on using a low-end microcontroller to initialize on non-x86 embedded systems and maybe present a simple text-mode ABI.
 
> In any of these cases, it's only a small amount of additional software
> to read either DDC or SPI, convert them to timing numbers, and feed
> them to the video program compiler.

   One of the things I like about X modeline format for this purpose is that it represents the numbers as text.  So there isn't a built-in size limit, as there is in DDC format.  We obviously couldn't do that in a DIPswitch board, of course; we'd be providing a specific number of switch bits.  I _think_ 12 bits is long enough for each integer, but should we plan for 13 or 14 to future-proof it?
   A tool with a microcontroller in it would be able to interpret a literal X modeline statement, and generate a video program for direct loading as an EEPROM image.