[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: ubuntu bulletproof x



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]