Dave Airlie wrote:
On Thu, 2007-08-30 at 13:49 +0000, igknighted@xxxxxxxxx wrote:
I think the main purpose is for people who are using proprietary
drivers (maily nvidia) and have kernel module breakages. Also for
those messing around with other settings manually (trying to get a
multi-button mouse working, for example). For those not used to linux
I can see how this could let them get online in order to get help.
But I also think it is poorly implemented. Why not ask the user when
they update xorg.conf if their previous one worked, and then if they
want to save it as a fall-back in case the new one fails. This way
you don't end up any worse off if it fails. You'd have to make the
name of the backup well known enough for those manually editing the
file to save the backup properly (xorg.conf.bak seems fairly standard
for this, yes?), but I feel like most users who would need this would
be using Ubuntu's GUI xorg.conf tool, and that could be built right
in.
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."
"
-dmc
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
