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

[Timothy Miller]

On 9/10/06, mykrowatt at comcast.net <mykrowatt at comcast.net> wrote:

> > 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.

Motherboard manuals list audible beep codes for errors that occur
before the graphics card  POSTs.  The BIOS first initializes the
minimum for the motherboard to work, then POSTs the video card, then
initializes other basic stuff, then initializes all other devices.

>    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.
>

The trick will be seeing who is the first to write the code to do it.
It'll probably be quite complex to do, but some hacker will get their
hands on it and bang it out quickly enough.

Either that, or it'll be unsupported.  :)

> > 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?

How large of a monitor do we want to support?

We don't need to future-proof this.  The code that reads the DIP
switches is software.  That software can be changed.

Look at it this way:  If someone is using monitors so large that 12
bits isn't enough, they'll be spending SO MUCH on the monitors that an
extra fee to have the cards reprogrammed to support ONLY that mode
would be a drop in the bucket.  Tech Source deals with business like
this, and people always want "subsystems," where the monitors and
cards show up together, already properly configured.

For a number of reasons, if someone ever came to Traversal with an
order like this, we'd refer them to Tech Source and let them handle
all of the weird manufacturing and customer service that goes along
with a high-priced deal like that.  Traversal would sell Tech Source
the hardware and let Tech Source deal with the headaches.  :)  Every
market has headaches, and we want to minimize the number of types of
headaches we take on.