What is ready

• Currently there are 4 flavours of the NVIDIA driver: 177, 173, 96, 71.

  They are all compatible with Xen and work only with 2.6.26 kernels (no 2.6.24, sorry).

  They all use DKMS therefore you will have to keep the linux-headers installed.

  CUDA is now supported by default (drivers 173, 177).

  The packages can replace each other without any need to remove one driver before installing the other. All it takes is a simple “sudo apt-get install nvidia-glx-VERSION”.

NOTE: these drivers won’t be backported to Hardy. The “-envy” flavour in multiverse will be kept updated on Hardy.

Problems

xorg-server 1.5

The xserver was updated to version 1.5, which broke the ABI compatibility. As a result, drivers 96 and 71 (and fglrx) dont’ work with the new xserver and unfortunately the -IgnoreABI option of Xorg doesn’t solve the problem. This is something that only NVIDIA can solve. (177 and 173 work well)

Dist-upgrades

Currently when you dist-upgrade from Hardy to Intrepid, there is no way to update an old driver, say, nvidia-glx-new, to a driver with the new name scheme, say, nvidia-glx-173. You will have to install the driver manually with, for example, “sudo apt-get install nvidia-glx-173” (there’s no need to uninstall the previous driver, since it will be replaced by the new one).

Currently we can’t rely on dependencies to make dist-upgrades smooth. If you compare the situation in Hardy with the one in Intrepid and especially if you think that NVIDIA could add and remove the support for more models to/from their drivers in the future, you will see why relying on dependencies wouldn’t be the best choice now.

SITUATION IN HARDY:

nvidia-glx-new (169.12):
Geforce 5xxx, 6xxx, 7xxx, and a few models of the 8xxx series

nvidia-glx-new-envy (173.14.09):
Geforce 5xxx, 6xxx, 7xxx, and a few models of the 8xxx series

nvidia-glx, nvidia-glx-envy (96.43.05) in Hardy is a legacy driver which supports:
Geforce 2xxx, 3xxx, 4xxx, 5xxx, 6xxx, 7xxx up to 7800

nvidia-glx-legacy, nvidia-glx-legacy-envy (71.86.04) is another legacy driver which supports:
RIVA TNT/2, Vanta/Vanta LT, GeForce 256, GeForce DDR, GeForce2, Quadro2
Pro

SITUATION IN INTREPID:

nvidia-glx-177 (177.13):
Geforce 6xxx, 7xxx, 8xxx, 9xxx, GeForce GTX 260, GeForce GTX 280

nvidia-glx-173 (173.14.09):
Geforce 5xxx, 6xxx, 7xxx, 8xxx, 9xxx

nvidia-glx-96 (96.43.05):
Geforce 2xxx, 3xxx, 4xxx, 5xxx

nvidia-glx-71 (71.86.04):
RIVA TNT/2, Vanta/Vanta LT, GeForce 256, GeForce DDR, GeForce2, Quadro2 Pro

As Martin Pitt suggested, we could have metapackages for each card series so that, for example, if NVIDIA decides to drop the support for GeForce 6xxx from driver 177, we can make the metapackage depend on driver 173 instead of 177. This is something which we might do in the next future when the hardware database for Jockey is ready. In the meantime we have no way to see which card series a card belongs to by relying only on its pci-id. Therefore we are working on an alternative solution (see the “Plans” paragraph).

nvidia-xconfig

Please be careful if you’re planning to use nvidia-xconfig. Xorg-server 1.4.99.901 removed support for the RgbPath option but nvidia-xconfig will add the following line to the “Files” section of your xorg.conf:

RgbPath "/usr/lib/X11/rgb"

You will have to comment it out.

NVIDIA should fix this soon.

Jockey

Jockey doesn’t support the new NVIDIA drivers yet, therefore you shouldn’t use it to install the NVIDIA driver (yet). I’ll work with Martin on this so that Jockey can keep rocking as usual.

Plans

Dist-upgrades

We will handle 2 cases: dist-upgrades done through Update Manager and the ones done from the command line.

Update Manager

If any version of the nvidia driver (with the old name schemes) is installed, basic hardware detection should be performed and the appropriate driver should be installed.

Command line

If the dist-upgrade is done from the command line we can’t install the appropriate driver automatically during the dist-upgrade (you can’t call apt while apt is in use). As Martin suggested, all we can do is warn our users through debconf so that they will know what to do. I have already implemented Martin’s idea by creating “nvidia-common”, which you can find in my PPA (NOTE: this is not the final release).

How does nvidia-common work?
nvidia-common depends on 4 new packages (nvidia-VERSION-modaliases) which contain the lists of the pci-ids of the NVIDIA cards supported by NVIDIA’s proprietary drivers. Such lists are generated automatically when the packages of the drivers are built therefore, when a driver is updated, its list of pci-ids will be updated too.

My Python program will detect the pci-id of your card and find the newest driver which supports it. If you have more than 1 one card plugged in, then it will look for a driver which supports all your cards and install that if available, otherwise the newest driver will be chosen (since I guess that you would prefer using your GeForce 9xxx rather than your GeForce 2).

This check is (currently) triggered in 3 cases:
1) when nvidia-common is installed
2) when the kernel image is installed/updated
3) when the kernel headers are installed/updated

If you haven’t a driver with the old name scheme installed or if your card is not supported you won’t see any debconf dialog, otherwise you should see something like this:



How to test it on Hardy:
add my PPA to your software sources:
deb http://ppa.launchpad.net/lrm-intrepid/ubuntu intrepid main

and install only nvidia-common (revision ubuntu12 or higher) and let it install its dependencies (i.e. the modalias packages). Then disable the PPA. Do NOT install any other package. You should see a debconf screen. The same will happen if you reinstall the kernel headers or image.

Backports
The drivers will be updated in the backports repositories as they will be actually backported from Intrepid+1 to Intrepid.

Credits

Ben Collins:
gave me some tips on TLS for the drivers.

Bryce Harrington:
has been very available and has followed all the steps of the migration to the new NVIDIA drivers.

Mario Limonciello:
tested the packages and gave me a few useful tips.

Martin Pitt:
guided me through the migration and has been very available. He gave me a lot of feedback on the packages, on the new name schemes and on how we should deal with dist-upgrades. His experience has been invaluable. Furthermore he is doing all the uploads for me.

Timo Aaaltonen:
did the merge of the Debian package with my initial package (hoping that the changes could be merged back into Debian) thus providing me with a new base to work on.
Furthermore he suggested the use of a dynamic dependency on the server ABI (so that we don’t have to hardcode it in the source) like the Intel driver does.