ubuntu bulletproof x

[Douglas McClendon]

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

First, thanks for many of these recent educational responses.  Something 
like cvt I do personally find cool, though clearly it has nothing to do 
with the type of situation ubuntu-bulletproof-x is targeting.


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

This sounds like an aweful lot of situations.  I suspect my micron 
apt150t falls into more than one of them (not DVI, not vista certified, 
probably not xp certified, 'really old', who knows about about i2c 
timing and/or bios bugs...).

I'll save the details of my s-c-d fun yesterday for a bug report, but 
suffice it to say that after selecting 'generic 1024x768 lcd panel' and 
seeing that in xorg.conf, it decided to start up in 1378x768...  Not 
reproducibly though.

My point, if I even have one anymore, is that it sounds like the above 
(my situation, and what you said), are a multitude of situations where 
.inf info might come in useful.  But you did clarify below...




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

 From Richi Plana's posted .inf

"
[1280]
HKR,,MaxResolution,,"1280,1024"
"


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

I would truly love to provide a counterexample with my micron ap150t, 
but as was pointed out elsewhere in this thread, that is one example 
where the .inf truly does not exist on the face of the earth.  But if it 
did, and had something like the MaxResolution quoted above, that would 
be a valid counterexample, right?

-dmc

P.S. I honestly don't care enough about this thread to restore my copy 
of vista on my laptop (haven't had winblowz in my home for >6months) 
which has a vga-out, to see if windows can do better with that monitor 
than F7.