> Ok, let's see... we'd need: > > - Maybe 12 bits for the dot clock > - 12 bits for the h res > - 12 bits for the v res > - 4 bits for each of the v and h fp, bp, and sync (24 total) > > So, you're saying that you want a header with 60 pairs of pins on it? > Actually, I'm sure this is an underestimate.
Ummm..., no. If you look at the syntax of the modeline statement in /etc/X11/XF86Config, settinng the horizontal resolution takes 4 numbers of at least 11 bits each. One for the number for displayed pixels per row, one for the total number of dotclocks per scan line, one for the number of dotclocks from beginning of line to beginning of sync pulse, and one for the number of dotclocks from beginning of line to end of sync pulse. Ditto for the vertical resolution. And unless you want to paint yourself into a corner and only support the current generation of high-resolution monitors, you'd better make that 12-bit numbers, not 11-bit. So setting the horizontal and vertical scanning takes 96 bits, before you even consider the number of bits required to set the dotclock rate and the miscellaneous bits for sync format. (Contrary to what I said earlier, I forgot to multiply by 2.) And if you don't have all that, then you can't set all possible arbitrary modes, pure and simple. And half-measures would be pointless. So it looks like around 120 bits will be required to be sure of driving all possible monitors. That certainly wouldn't be a standard feature of a plain vanilla desktop graphics board. It would be a requirement for a specialized high-end board, though. So, the question becomes how to implement it. A piggyback add-on board or a different main board using jumpers would be the most versatile and goof-proof, and probably the easiest to set up. No test equipment required, just a manual and a pair of tweezers. On the other hand, storing the mode bits in a serial EEPROM would be the cheapest, take the least board space, and probably could fit into the artwork for a standard product, but there would have to be a well-thought-out way to configure the EEPROM -- probably with the aid of a self-booting CD or floppy running on a generic PC. And that method would have to work without relying on the board under test to generate a usable display on a monitor. Which means it would appear as a PCI device, but not a graphics board, while being configured. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
