ubuntu bulletproof x

[Adam Jackson]

On Thu, 2007-08-30 at 18:27 -0500, Douglas McClendon wrote:
> Dave Airlie wrote:
> > Really if you have to ask the user you've already lost....
> > 
> > The main use this gives is you can let a user try the binary driver, and
> > if it tanks, you can use the GUI to go back to the open source or vice
> > versa,
> > 
> > Really though a simple ordering like:
> > 1. Users current xorg.conf
> > 2. No x.org conf - default driver
> > 3. Try another driver in list (like fglrx or radeon)
> > 4. Try vesa.
> > 5. lose.
> > 
> > I'm not sure what asking the user in-between really gives you..
> 
> RTFA...
> 
> "
> One of the most impressive new features in Ubuntu's BulletProof-X 
> implementation is support for reading monitor settings from a Windows 
> driver CD. "Unfortunately, it doesn't work to select just any of the 
> generic monitors, so users may find they need to trial-and-error a 
> solution. Fortunately, there is a cool new feature—Add Model which 
> allows users to add a new monitor by using the Windows driver CD that 
> comes with their monitor," Harrington writes. "This uses a script to 
> parse the Windows *.inf file to get the hsync, vsync, edid, dpms, and 
> other info to update the database locally."
> "

Hilariously, they're using inf2mondb.py for this.  You know, the one msw
wrote like five years ago, that's in our hwdata CVS, and that we use to
construct /usr/share/hwdata/MonitorsDB.

The whole reason we're _not_ using this very much - and that I've
effectively stopped updating MonitorsDB - is because the inf files don't
give you useful information.  They give you sync ranges and that's about
it.  So you end up in some pretty hilarious situations, because X
prefers width over height, so even though your monitor's 1600x1200, the
sync range is big enough to fit 1680x1050, so you'll try to fit that,
and lose.

There does happen to be a variable in inf2mondb that's named 'edid', but
it's not actually the full EDID block.  It's a tuple of the EISA vendor
ID and a model number.  This, it turns out, is not useful for
configuration.  So while Bryce might have read the script with the best
of intentions, he clearly hasn't tried to use it in anger.

So yeah, hooray, they have a feature that doesn't work.  Good for them.

Now, you can get most of the way to right by just adding maximum pixel
clock to the available configuration options in xorg.conf's Monitor
section, which fixes the width problem I mentioned above.  I've (very,
very slowly) been pushing s-c-d in this direction, which is why it now
hides the big brutal list of vendor/model monitor combos and only shows
generic sizes by default, so it can (eventually) compute the sync ranges
and max pixel clock from the size and the appropriate timing formula for
the display type.  It still gets some things wrong and I happily accept
patches, in particular it won't actually write out Option "MaxPixClock"
anywhere.  But it's a way more correct approach than what the article
describes.

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.

- ajax