> 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

Reply via email to