ubuntu bulletproof x

[Douglas McClendon]

Adam Jackson wrote:
> On Sat, 2007-09-01 at 16:03 -0500, Douglas McClendon wrote:
>> Adam Jackson wrote:
>>
>>> If I were being cynical, I'd say a large part of the reason they'll be
>>> moderately successful at this whole 'bulletproof' thing is due to work
>>> I've already put in to fixing autoconfiguration within X itself, and
>>> that the press releases are just so much propaganda.  Don't get me
>>> wrong, Fedora sucks at self-publicity, we should do better, but all I
>>> see in that project is prettier UI and not technical correctness.  If
>>> you do it _right_, you don't ever have to admit failure.  Asking for the
>>> inf file is admitting failure.
>> I suspect you'll tell me why I'm wrong-  But aren't there (a significant 
>> number of) situations where autodetect fails, and in fact due to 
>> hardware limitations can't succeed, but the process of the user 
>> specifying the monitor type, and info, from the driver CD, will cause 
>> success?
>>
>> Even if those situations account for 1/10,000 users, those are precisely 
>> the cases that need to be covered to market something as "bulletproof".
>>
>> Now of course, it won't solve the problem of the user getting confused 
>> and using the wrong CD for the monitor...
> 
> 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)

If that truly is *NEVER* a possibility, then my main speculative 
argument, was wrong.

You make it sound as though monitor .inf files *NEVER* contain available 
resolution information.  This sounds odd to me.  Please verify my 
understanding of that as well.

-dmc




> 
> In either case, asking for the windows CD won't tell you what you want
> to know.  It will tell you sync ranges, when what you _want_ to know is
> desired resolution and display type (as in, CRT, LCD, beamer, whatever).
> Afterwards you can validate that against the sync ranges from the INF
> file if you want, but really, either it'll work or it won't, and asking
> for the CD won't make it work better.
> 
> It's a red herring, is my point.  It's a non-feature.  It's like going
> to buy a Ferrari and the salesman keeps talking about how great the
> cupholders are.  They might be great, truly exemplary, but they're not
> really what you're interested in.
> 
> - ajax
>