Hi!
Sorry for the late reply. CCing rpmfusion-developers and full-quoting
message, as this discussion is relevant for RPM Fusion. Two eearlier
replies to this mail can be found in the freeworld archives and in the
attachment:
http://livna.org/pipermail/freeworld/2008-July/003115.html
http://livna.org/pipermail/freeworld/2008-July/003116.html
On 19.07.2008 18:24, Stewart Adam wrote:
Hi,
Thorsten, Nicolas and I discussed this briefly in IRC but it would be
great to have your opinion on it. The problem we're having is that
nVidia now has the "normal" mainstream driver along with 3 other drivers
which are considered "legacy", each supporting a different set of GPUs.
According to nVidia's driver selection on its website, the 177 series is
recommended only for the new GeForce 200 series GPUs. The GeForce 9000
to 5000FX series are to be used with the 173 driver, while GeForce 2/4
are to be used with the 96.* series driver and the 71.* driver is for
any older cards like Riva or TNT.
If we choose a named scheme, such as kmod-nvidia-newest and
kmod-nvidia-legacy, the problem is when nVidia releases a new driver
that drops support for older cards, those users will receive updates to
"kmod-nvidia-newest" and will be left without X.
If we choose versioned names, for example "kmod-nvidia-173", then it
would be simple to create "kmod-nvidia-177" and it would only
"Obsoletes: kmod-nvidia-173" if it retained compatibility with the same
cards. The disadvantage to this is that if a driver does drop support
for old cards, the people with new cards have to manually install the
new driver. One possibility I was thinking of was including GPU
detection in livna-config-display so that it would be able to suggest
users of the newer GPUs to upgrade.
How do you think we should name the drivers? It doesn't have to be one
of the two I mentioned above, those are just the option we had thought
of on IRC.
Some general thoughts:
* For the legacy drivers I'd like to see "legacy" in the package name
(nvidia-legacy-73xx, nvidia-legacy-96xx), as that makes things like "I'm
using legacy stuff that (1) might not support all Features and (2) might
be dropped sooner or later" obvious to the user. That is a quite
important detail IMHO.
On the other hand it has some appeal to use the same scheme for all
driver packages (nvidia-71xx, nvidia-96xx, nvidia-173, nvidia-177)
* some users in the past asked us to maintain a stable branch that is
not updated immediately when nvidia releases a new version
* other users always want the latest and greatest; they even asked us
to ship beta drivers
* some people were unhappy that we used the xorg-x11-drv prefix for
our drivers; are those people still unhappy? Should we consider to get
rid of that prefix again?
* making the driver parallel installable would be really nice for
live-media
* updates don't work for all the drivers -- users need to restart; we
need to find a way to unload the module during X-restart after a nvidia
update; that should be easy; fglrx did something like that in the past
* I don't like the GUI livna-config-display much at all; cluttered
interface and some of the things (like the Xgl stuff) are totally
irrelevant for 99,9 % of our users; that needs a major cleanup!
So maybe something like this could work to solve some of the problems:
* we ship all the driver packages with a versioned name nvidia-73xx,
nvidia-96xx, nvidia-173, nvidia-177
* make those packages parallel installable
* create a init script/app that chooses the "best" driver on bootup;
that app could even have a settings file where the user could say "use
beta drivers; prefer 177 series" or something like that; it also could
yell thinks like "you have the 173 series of drivers installed but need
the legacy drivers from the 96xx series".
But that app should never ever call yum, as network might not be
accessible during start. A lot of people also dislike if packages get
installed behind their back, so we should avoid to do that.
* create two meta packages "nvidia-all" and "nvidia" to the repo;
"nvidia-all" could track in all the drivers we offer and everything will
"just work" -- the easiest solution for ordinary users. "nvidia" could
track in the driver that is considered the "standard" one (173 now) and
all newer ones (177 right now). That could be the solution for those
users that want to avoid useless downloads for the legacy driver. The
decision which driver to use would be left up to the init script;
* having a GUI app that says "you need nvidia-73xx, nvidia-96xx or
nvidia" would be nice. It IMHO should not offer the standard and newest
drivers (173, 177), as their meaning and usage might change over time;
the script can handle that better, even if that means some useless downloads
But that GUI app IMHO should not be specific to nvidia or graphics
drivers. It would be way better if it would a bit like the proprietary
driver install and configure tool Ubuntu has. Even better: make that app
able to suggest and install add-on packages like gstreamer-plugins or
xine-lib-extras-monfree for the packages it finds installed on the
system; that would be a really cool feature :-)
* users that want to avoid useless downloads can just install
nvidia-173; they can keep both pieces if it breaks because they tried to
be smart and but are not. Of course we use proper obsoletes in newer
drivers where it makes sense to not break stuff on purpose ;-)
Does that sound like a solution that fixes some of todays and tomorrows
problems?
CU
knurd
--- Begin Message ---
Hi,
I vote for versioned names!
> If we choose versioned names, for example "kmod-nvidia-173", then it
and regarding:
> One possibility I was thinking of was including GPU
> detection in livna-config-display so that it would be able to suggest
> users of the newer GPUs to upgrade.
yes please, this way
1. livna-config-display package should not depend on nvidia drivers or any
specific drivers, it should have an a GUI and command that call yum (or
package kit) when the user asks for it
2. all drivers should be able to co-exists without conflict even for
machines that does not have the card
ie. if I install both kmod-nvidia-177 and -97 and -77, my system should
boot normally and start without a problem if I have no nvidia card but
intel!
so that it can be used on a live-usb
3. it should use udev to know which driver to suggest like this:
* if the vendor is 0x10de then it's nvidia
this command will list VGA devices:
find /sys/devices/pci* -iname 'class' | xargs grep -l -i '0x030000'
and this will list nvidia devices:
find /sys/devices/pci* -iname 'class' | xargs grep -l -i '0x030000' | sed
-e 's/class$/vendor/'
| xargs grep -i '0x10de'
you may make it like this:
find /sys/devices/pci* -iname 'class' | xargs grep -l -i '0x030000' | sed
-e 's/class$/vendor/' | xargs grep -qi '0x10de' && echo "you have nvidia"
|| echo "you don't have nvidia"
and if you pipe that to sed -e 's/vendor$/device/' you will get the device
id of the nvidia card!
and from that number you can choose best driver
or we may rely on lspci like this
lspci -n | grep -i '0300: 10de' | cut -d ' ' -f 3
it will output
10de:XXXX
where XXXX is the nvidia card id
(those shell commands can be pythonized easly)
4. livna-config display should not edit xorg.conf to add nvidia if the
module failed to load!
and trying to load nvidia.ko could be used as another way to detect the
card provided the the driver is installed
modprobe nvidia || echo "You don't have nvidia card"
___________________________________________
Freeworld mailing list: [EMAIL PROTECTED]
http://livna.org/mailman/listinfo/freeworld
--- End Message ---
--- Begin Message ---
2008/7/19 Stewart Adam <[EMAIL PROTECTED]>:
> Hi,
>
> Thorsten, Nicolas and I discussed this briefly in IRC but it would be
> great to have your opinion on it. The problem we're having is that
> nVidia now has the "normal" mainstream driver along with 3 other drivers
> which are considered "legacy", each supporting a different set of GPUs.
>
> According to nVidia's driver selection on its website, the 177 series is
> recommended only for the new GeForce 200 series GPUs. The GeForce 9000
> to 5000FX series are to be used with the 173 driver, while GeForce 2/4
> are to be used with the 96.* series driver and the 71.* driver is for
> any older cards like Riva or TNT.
I would add, the way we will fix thing highly depend on how nVidia
will support the different series.
Previously, we've only supported the series that was explicitely
supported by nVidia.
This meant some end-users wanted to have a 100.xx version because of
performances regression in newer version of the "main" driver.
My guess is that thoses users could have used the "lower" series
instead (meant 96xx) that was actually newer than the older 100.xx
series.
One note is that supported series usually fit a different range of
GPU. But sometime one GPU is supported by different series.
This is true for NV3X (Geforce FX 5x00), that was supported by
71xx(legacy) 96xx, main (today 173xx) but will be dropped in 177xx.
So the question for now, is will the 173xx series will be supported by
nVidia (it work now, but whatabout later ?) or should users of NV3X
will need to move for the 96xx series ? This is problematic for now in
the Fedora 9 case because legacies users aren't still supported.
But once it will (nVidia promised, but we are still sick to wait),
maybe we could avoid to maintain one more series in the repositories.
That's been said, changing the support range of the available series
will be a documentation regression. (end-users will need to be warned,
and they will need to read updated docs, which is a bug by itself).
And every rpm based solution with Obsoletes/Provides will lead to
switch for all, whereas some will need to stay with 173xx (or 96xx),
and others will want 177xx.
Maybe one suggestion would be to have a rpm to Requires:
nvidia-driver4chipset-NV30 and that capability be provided by the
related driver. (this is just an early remark, since i don't know rpm
will work well with multiples dependencies,... this seems hard...)
Another easier way would be to to introduce a serie number for main
(we won't have kmod-nvidia anymore but kmod-nvidia-173xx/177xx, and to
stay with the support range during the release lifetime. In this case
173xx will only obsoletes kmod-nvidia (not provides unless we want to
rename during the F-9 lifetime).
I think we are here..., since we don't know if 173 will still be
supported by nVidia (for kernel 2.6.27 .28 and so on).
This means that for F-9 to F-10 , a clean upgrade path might not be
provided; and some end-users will get unresolved dependency if they
don't have uninstalled their nvidia driver... (that could be
documented to avoid this kind of bug report, might be easier...)
Now something might be interesting point. We may need to split to
concept of having the driver (and eventually differents series)
installed with the concept to have an nVidia card present on the
system. (livecd built by end-users behind), and thus, the driver
activated on next "Xserver/system" boot.
The main problem with having differents series remains with the driver
auto-detection (which series if nVidia), and how to deal with kernel
module for each series (that are all named nvidia.ko).
But having a solution that can auto-detect the driver to use according
to the installed drivers available (and support expected) would be a
better solution for the new scheme we need to have.
Nicolas (kwizart)
> If we choose a named scheme, such as kmod-nvidia-newest and
> kmod-nvidia-legacy, the problem is when nVidia releases a new driver
> that drops support for older cards, those users will receive updates to
> "kmod-nvidia-newest" and will be left without X.
>
> If we choose versioned names, for example "kmod-nvidia-173", then it
> would be simple to create "kmod-nvidia-177" and it would only
> "Obsoletes: kmod-nvidia-173" if it retained compatibility with the same
> cards. The disadvantage to this is that if a driver does drop support
> for old cards, the people with new cards have to manually install the
> new driver. One possibility I was thinking of was including GPU
> detection in livna-config-display so that it would be able to suggest
> users of the newer GPUs to upgrade.
>
> How do you think we should name the drivers? It doesn't have to be one
> of the two I mentioned above, those are just the option we had thought
> of on IRC.
>
> Stewart
>
> ___________________________________________
> Freeworld mailing list: [EMAIL PROTECTED]
> http://livna.org/mailman/listinfo/freeworld
>
___________________________________________
Freeworld mailing list: [EMAIL PROTECTED]
http://livna.org/mailman/listinfo/freeworld
--- End Message ---
