> You shouldn't need to set the dot clocks--the CRT, unless it is a > very old one, should respond to an EDID query and supply the correct > display-timing info back to the driver.
Not necessarily. At one of my jobs, we make a turnkey appliance that typically connects to a user- (or at least dealer-)supplied monitor, potentially with a locally-sourced cable. We've had multiple issues in the field with recent versions (built atop NetBSD 8.0 and 9.1) traced to cables that don't connect the pins necessary to carry the EDID info. So, even if the monitor is capable of it, the host might not see EDID. Of course, you can also squint your mind a different way and see the problem as being the switch from the "computer generates signal, it's the monitor's responsibility to display it" paradigm to "monitor tells computer what kind of signal to generate, it's the computer's responsibility to obey" paradigm. I ran into this bigtime when trying to connect my SS20s to flatscreens - each end thought it had control over the details of the video timing. (I eventually managed to get the SS20 to generate something the flatscreen would handle, but it took fiddling. Yet another case of technology advancing to the point where it becomes difficult or impossible to do what used to be easy.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B