ubuntu bulletproof x

Denis Leroy denis at poolshark.org
Tue Sep 4 15:25:31 UTC 2007

Adam Jackson wrote:
> On Mon, 2007-09-03 at 14:53 -0500, Douglas McClendon wrote:
>> Adam Jackson wrote: 
>>> Yeah, okay, force me to clarify.  Grumble.
>>> There are cases where we can't tell what monitor the user has.  They're
>>> almost completely described by "either the card can't do DDC, or the
>>> cable is broken".  The former is a vanishingly small class of hardware,
>>> voodoo1 basically.  The latter happens depressingly often particularly
>>> with projector setups.
>> So, to save you the trouble of rereading all of my posts.  Can you 
>> explicitly confirm this (which it sounds like you did, but not in a way 
>> that clearly addressed the point I tried to make half a dozen times last 
>> night).
>> Repeat after me-
>> "There is *NEVER* a situation, when the monitor fails to provide correct 
>> information, due to a broken or absent edid implementation, and which at 
>> the same time, sufficient information could be parsed from the .inf that 
>> came on the CD with the monitor, to provide the user, a reasonable 
>> experience requiring no user interaction beyond putting the cd in the 
>> drive".  (and at which time, the X driver could not have accomplished 
>> the same thing automatically without the .inf)
> Absent EDID in the sink device never happens anymore.  It's a
> requirement for Vista certification.  I'm fairly sure it was required
> for XP cert.  It's a requirement for shipping any DVI sink device.  It
> is _mandatory_.
> We can fail to get EDID, either because the cable broke the DDC pins, or
> timing bugs in the I2C code, or BIOS bugs if we're using VBE DDC, or
> it's a really old monitor, or there's a crap KVM switch in the middle,
> or phase of the moon, or whatever.
> I have not found ISOs for every OEM CD for every monitor that ever
> shipped.  I doubt I ever could.  Therefore the following claim is merely
> statistical.  However, on no OEM CD that I've ever found does the
> included INF file - or any other resource intended to be parsed by the
> machine - provide the same set of information as the EDID block for the
> monitor.  It may provide a subset.  The only subset I've ever seen is
> sync ranges.
> I'm not saying I'm happy about that.  I would love to see a
> counterexample.  But it's all the empirical evidence I have.

Just wanted to thank you for writing such informative emails. Everytime 
I read one of your emails I learn something about X, and that's awesome.


More information about the fedora-devel-list mailing list