enabling DDC in the face of broken monitors

[Philip Prindeville]

Mike A. Harris wrote:

> 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.



All true.  What I meant was that people eventually figure out a way
to work around a broken monitor.  After all, that's what we do right
now...  so we won't be any worse off in that case, and when the
DDC/EDID is correct, things will magically work much better.


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


Well..  That may be true for other reasons.  Windows drivers look
at the shipped .inf files, or the .inf files fetch off the internet.

They are heavily invested into the Windows market:  it's a large part
of their sales share.  But assuming they weren't:  shipping bad EDID
information would be a real hit for them.

>> Why isn't it more generic?  Isn't that the point, after all?
>
> On another front...  Why is the DDC stuff as per-driver as it is?
>
> 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 guess I thought that the card driver located the DDC mechanism,
and then called into the generic DDC guts to do the I2C signalling
to actual start the transfer, parse the results, etc.

>
>
>> 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.


Another reason to use LCD monitors.  ;-)

Well, 'Options "noDDC"' will remain a workaround for a long time
to come.


>
> 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".


Ok....  so... we should come up with a .inf file parser... :-(

I guess a larger problem is that the various Lini that support
"yum" (or whatever) couldn't make use of more frequent
updates of id information (such as /usr/share/hwdata/pcids.txt on
Fedora, etc).

If this information were pushed out with reasonable
frequency (say weekly or better), then we could give various
hints about new hardware (such as, "ignore edid info coming
from this monitor because it's a liar and stick to VESA modes").

-Philip