Sorry I took this long to give this a real read. If I understand this correctly, the maximum dotclock rate is 655.36 MHz. So far, so good. High end monitors are just coming into that range now, so the standard may be approaching the end of its useful life for some monitors, but it should still be good for everything else. I can only find 10 bits each dedicated to sync pulse width and offset. This may be OK if they're truly encoding width and offset relative to leading edge, and not from the beginning of the scan line as modeline does. It sounds like they're skimping on bits and may run out of gas soon, though. The bits are scattered around in a funny order, but the configuration interface could straighten that out. So, I could imagine two versions of an EDID-override tool: one with a microcontroller, configured through an RS-232 connector, and the other with DIP switches. It should be possible to arrange the switches and label them in silkscreen so it's easy to set them correctly without a working computer.
The next questions are how an EDID tool would connect to the TRV10 and the OGC1. Presumably, this type of tool doesn't require any modifications at all to the ASIC. But to get the tool's EDID information to substitute for whatever might be coming up the cable from the monitor, the board might need to have some jumpers or a switch to disconnect the EDID path from the monitor cable, and connect it to the tool instead. Maybe a single header could connect the ASIC to the DVI connector when the jumpers are installed, but accept the test cable from the tool when the jumpers are removed? I'd be a little leery of connecting the EDID tool in the path of the video cable, because of the possibility of introducing transmission line discontinuties going through a chain of connectors. To everybody I haven't replied to in the last 3 days, my apologies. I've been hibernating at work. -------------- Original message ---------------------- From: James Richard Tyrer <[EMAIL PROTECTED]> > Timothy Miller wrote: > > On 8/27/06, Jack Carroll <[EMAIL PROTECTED]> wrote: > >> The DDC injection box sounds like a very interesting solution to > >> one class of configuration and test problems. It's probably a > >> useful test tool in its own right, for checking out the system's > >> behavior with DDC codes. Am I right in thinking that it's not a > >> general solution to configuring all possible arbitrary modes > >> directly from timing specs or modeline-style data? > > > > I think EDID is able to specify detailed timing numbers. What would > > be missing? > > http://www.vesa.org/Public/EEDIDguideV1.pdf > > http://en.wikipedia.org/wiki/EDID > > It appears to have all the ability of an X modeline: > > 54-71: Descriptor Block 1 > 54-55: Pixel Clock (in 10 kHz) or 0 > If Pixel Clock is non null: > 56: Horizontal Active (in pixels) > 57: Horizontal Blanking (in pixels) > 58: Horizontal Active high (4 upper bits) > Horizontal Blanking high (4 lower bits) > 59: Vertical Active (in pixels) > 60: Vertical Blanking (in vertical pixels/lines) > 61: high significant bits for Vertical Active (4 upper bits) > high significant bits for Vertical Blanking (4 lower bits) > 62: Horizontal Sync Offset (in pixels) > 63: Horizontal Sync Pulse Width (in pixels) > 64: Vertical Sync Offset (in lines) (4 upper bits) > Vertical Sync Pulse Width (in lines) (4 lower bits) > 65: high significant bits for Horizontal Sync Offset (bit 7-6) > high significant bits for Horizontal Sync Pulse Width (bit 5-4) > high significant bits for Vertical Sync Offset (bit 3-2) > high significant bits for Vertical Sync Pulse Width (bit 1-0) > 66: Horizontal Image Size (in mm) > 67: Vertical Image Size (in mm) > 68: high significant bits for Horizontal Image Size (4 upper bits) > high significant bits for Vertical Image Size (4 lower bits) > 69: Horizontal Border > 70: Vertical Border > 71: Interlaced or not (bit 7) > ? (bit 6) > Stereo or not (bit 5) > Separate Sync or not (bit 4-3) > Horizontal Sync positive or not (bit 2) > Vertical Sync positive or not (bit 1) > ? (bit 0) > > And it has sync: > > 20: VIDEO INPUT DEFINITION > bit 7: 0=analog, 1=digital > if bit 7 is digital: > bit 0: 1=DFP 1.x compatible > if bit 7 is analog: > bit 6-5: video level > 00=0.7, 0.3, 01=0.714, 0.286, 10=1, .4 11=0.7, 0 > bit 4: blank-to-black setup > bit 3: separate syncs > bit 2: composite sync > bit 1: sync on green > bit 0: serration vsync > > Forgot that you also need to change the video level for sync on green. > > So, that is the format to use since it is a VESA standard. I presume > that we can find room for a 256 byte EEPROM. Don't know what the second > 128 bytes are going to be used for so perhaps we don't need them. > > I still think that we should have some basic method on the board for > starting mode (default video mode): > > 480i @ 30 > 480p @ 60 > VGA 640x480 @ ?? > Setting in EEPROM > > and a write enable for the EEPROM. > > Note, IIUC, 480p and VGA are slightly different in the non-visible part > of the signal. > > Do we also need Vertical frequency for VGA? (60, 70, 72) since some > monitors won't do 60? And, 50 which would change to PAL 50 formats. > > This would permit the user to set the board up using a borrowed VGA or > his TV (with our CD of monitor information). > > -- > JRT > > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
