enabling DDC in the face of broken monitors

[Mike A. Harris]

Philip Prindeville wrote:
> Say it ain't so, Joe!
> 
> I think this would be a big step backwards...  It's like refusing to
> turn on the kitchen lights, because you then have to see all the
> cockroaches.  ;-)
> 
> Yeah, turning on DDC will reveal a lot of bugs, at least initially...
> but the product development cycle of monitors is fairly short,
> and eventually the bogus monitors will be retired.

Monitors last for years, so that line of reasoning is totally not
reasonable.  People want their hardware to work out of the box
without messing around, in particular if it always worked out of
the box for them in the past.

Telling them "buy a new monitor, your $1500 monitor is broken
hardware" when it worked before, is not a good way to make new
friends.


> And... market forces being what they are, the manufacturers
> building monitors that "just work" will get that reputation, and
> be rewarded...  and those that don't... Well, they'll learn or perish.

You think Dell is going to perish?  I'd put my money on the
opposite.  I'll go as far as to claim that Dell could probably
make their monitor EDID information random numbers and only
affect their sales slightly if at all.


> On another front...  Why is the DDC stuff as per-driver as it is?
> Why isn't it more generic?  Isn't that the point, after all?

For the same reason that 2D accelerated line drawing is different
on every piece of hardware out there, or other 2D or 3D primitives,
or accelerated video functionality, or pretty much anything at all
on any modern video hardware.  It is a function of the hardware,
which is programmed in a unique manner from manufacturer to
manufacturer, and from card to card, and sometimes chip to chip.

While DDC isn't a feature you generally think of "on screen" like
you might think of accelerated line drawing, nonetheless it is
handled by frobbing this, poking that, and those operations
differ on different hardware.

If it were possible to probe DDC in a hardware generic manner
reliably (No, VBE is not reliable), then all of the drivers would
do it that way.  The same can be said for line drawing or 3D, or
whatever also though.

It is the job of the X server to call per video driver functions,
which then translate the "generic" request (ie: probe DDC info)
into card specific requests (when direct programming info is
known - or to use VBE otherwise, which is unreliable).


> I've also been playing with the idea of having the DDC code
> prime the "modeline" list with manufacturer specific modes,
> and name them "Native#1", "Native#2", etc. sorted by
> highest to lowest resolution.
> 
> Thereby, a person could have:
> 
> Section "Screen"
>       ...
>       UseModes "builtin"
>       Modes "Native#1" "Native#2" "Native#3"
>       ...
> EndSection
> 
> and the configuration would just work at the highest resolution
> the monitor would support (well, and the video adapter).

Which falls apart when a single monitor out there has broken modeline
EDID data.  In theory, it could even fry the display.  I'm not
aware of one, but there are enough monitors out there with broken
EDID data that it is reasonable to assume they exist.

Even if such monitors are rare, they're not so rare when they're
shipped by one of the largest computer manufacturers in mass
volume.  Even if only 10000 users experience such a problem, that
is about 1000 bug reports to wade through from angry users who
have hardware that "just works fine in Windows, and in all previous
X releases".