Graphic drivers - Goals & Ideas
Thorsten Leemhuis
fedora at leemhuis.info
Tue Sep 9 19:43:17 CEST 2008
On 08.09.2008 17:41, Stewart Adam wrote:
>
> I'd like to make installing, using and updating the GPU drivers as easy
> as possible for the end user, so let me know what you like or dislike
> about the below. Based on the the last discussion (Naming of the nVidia
> drivers in RPMFusion), these are the things we're aiming for WRT GPU
> drivers and rpmfusion:
Looks good in general; nevertheless some comments below ;-)
> - Parallel-installable drivers
>
> - A new, easy to use livna-config-display that will get rid of the
> Xgl/AIGLX stuff and instead, suggest the recommended driver for your
> card.
Just wondering: Why do you use the word "suggest" here? Why not make it
"just work automatically" for ordinary users (which seems to be what you
are up to according to later parts of this mail)?
> As well, users will be able to override which driver is currently
> being used (ie, "I want to use legacy series 71xx instead of 96xx" when
> 96xx was autoselected based on the GPU)
This maybe could be done via an "advanced" menu or something like that.
Maybe the whole app should better be slitted differently:
- one command line and GUI app to enable or disable the proprietary
graphic drivers. Maybe we could use it for ath5k vs. madiwifi as well.
Maybe it could look similar to the tool from ubuntu maybe? Anyway:
that's more then enough for 98% of our users
- one app to select which driver is being used (or other advanced
features) for experienced users
> - 5 nVidia branches: legacy (71), legacy (96), stable (173), stable
> (177) and beta
>
> I thought a bit about how we could implement these and came up with a
> few other things to discuss:
>
> - Package naming: I like what Thorsten has suggested
FWIW:that was on freeworld-graphics a few months ago iirc
> and we have the
> drivers named by version, and then create metapackages which will track
> the appropriate versions. As a bonus, this also makes the name easier to
> remember. At the moment, "nvidia-legacy" would track
> xorg-x11-drv-nvidia-71 and xorg-x11-drv-nvidia-96. "nvidia-stable" would
> track xorg-x11-drv-nvidia-173 and xorg-x11-drv-nvidia-177. Any final
> words on this?
Where is the beta here? There are iirc "stable" 177 drivers for the
latest GTX-200-cards right now (177.13) as well as a 177 beta (177.70).
> - By tracking all stable/legacy/beta drivers at once, the initscripts
> can autoselect the best driver and hopefully that will reduce the number
> of times users are left without X because a driver dropped support for
> some GPUs. But, if this does happen (for example when nVidia released
> the 103 series driver as stable and moved 96 to legacy), we should
> announce this on an rpmfusion ML, the wiki's News page and I'll try to
> get it out on FedoraForum as well.
I dislike the "reduce the number of times users are left without X
because a driver dropped support for some GPUs" -- that number should
not be reduced, that number should not exist at all. And that's afaics
possible with the scheme you outlined, as you can make the new "legacy"
drivers and new stable drivers depend on each other; then the script can
magically select the right driver.
> - For autoselection of the appropriate driver, I'm leaning towards a
> small databank of each GPU's PCI ID and the required driver which the
> initscripts could parse and base their decision off of that. Is there
> anything easier/simpler that I looked over?
Maintaining such whitelists is hard and painful. Blacklist might be a
whole lot easier.
E.g. normally just look up hte pciid of the graphics card and choose the
newest driver that supports it. For situations like now (177.13 only
recommended only for newest graphic cards, 173 for the others modern
ones) create a temporary blacklist. That less maintenance work and more
fool-proof.
> If everyone likes what's mentioned here then I'll start working on the
> new RPM spec files and redoing the GUI bits of livna-config-display.
BTW, what will be the new name for livna-config-display?
CU
knurd
More information about the rpmfusion-developers
mailing list