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.
-denis
More information about the fedora-devel-list
mailing list