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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
