Bug#610021: /#610022: fglrx-glx fails to install in parallel with nvidia-glx

[Andreas Beckmann]

On Sunday, 16. January 2011 20:24:17 Patrick Matthäi wrote:
> Am 16.01.2011 14:49, schrieb Ronny Standtke:
> > reopen 610022
> >
> >> Sorry, not possible
> >
> > This is not true, it is definitely possible. Several parties have already
> > developed solutions for this problem, see the following both messages of
> > the discussion on the Debian Live mailinglist mentioned in the initial
> > bug report: http://lists.debian.org/debian-live/2011/01/msg00065.html
> > http://lists.debian.org/debian-live/2011/01/msg00066.html

Let me describe how the new nvidia non-free packages work for squeeze:
(I implemented and tested these changes.)

There are three new packages libgl1-nvidia-alternatives, 
libgl1-nvidia-alternatives-ia32, libgl1-nvidia-alternatives-ia32 that do the 
diversions of OpenGL libraries (from libgl1-mesa-glx, ia32-libs, *-dev) and 
create alternatives of the diverted files. The diversions are created/removed 
by dpkg triggers whenever the diverted packages are (un-)installed.

The nvidia packages Depends: on the lib*-nvidia-alternatives package for the 
library they provide, install the "new" library in a private library 
directory (/usr/lib/nvidia) and add an alternative (with higher priority than 
the diverted library from mesa).

There are currently a lot of Conflicts defined to make sure only one of 
nvidia-graphics-drivers, nvidia-graphics-drivers-legacy-173xx or 
nvidia-graphics-drivers-legacy-96xx can be installed at a time. (legacy-71xx 
is no longer supported with current Xorg.) Most of these Conflicts should not 
be necessary since there are no more file name conflicts for the libraries.

There are file name conflicts for nvidia_drv.so (the Xorg driver module) 
libglx.so (the replaced Xorg module) and nvidia.ko (the kernel module which 
may exist for any number of distribution and custom kernels at the same time) 
and I currently have no solution how to solve these to allow installing both 
nvidia-graphics-drivers as well as one (or two) legacy versions at the same 
time. Could we rename them eventually? Alternatively (at least for the xorg 
modules) we could set up one more set of alternatives.

...

About configuring xorg for the nonfree drivers: There is a compile time option 
for Xorg that makes it read PCI ID lists from /usr/share/xserver-xorg/pci/ 
and auto-select drivers modules of corresponding file names if a matching 
device was found in the system. This flag was active for some tome in the 
Debian Xorg packages, but is no longer enabled. IIRC it was related to 
defining PCI_TXT_IDS_DIR.

The nvidia-glx* packages ship a nvidia.ids file in that directory (but it's 
not used by current xorg).


> >> So by installing fglrx it is also not possible to use
> >> another 3d accelerated gpu driver anymore.
> >
> > It is, you just need to use update-alternative.

And it does work for nvidia-glx :-)

> The xorg/mesa team has to play with us then. I also don't think, that
> using the alternative system is the right way, because:
>
> 1) building against the fglrx libgl implementation is a bad idea

Agreed. Therefore nvidia-graphics-drivers* does not provide any libGL.so 
symlink. Instead the libgl1-nvidia-alternatives package diverts the libGL.so 
link provided by libgl1-mesa-dev and creates an alternative (via triggers) 
pointing to the diverted libGL.so - so at link time always the mesa opengl 
library will be used. For picking up the correct library at package build 
time, a shlibs file redirecting to libgl1-mesa-glx is being used.
(I.e. in short - no building/packaging of opengl programs without 
libgl1-mesa-dev installed).

> 2) users may get strange problems/crashes, if they install different
> drivers (fglrx+free-drivers / nvidia+fglrx / nvidia+free drivers etc).

Packages and alternatives should cooperate and have safe defaults - and 
bug-scripts that list all possible breakers :-)

> 3) It is no alternative, it is a diversion, because it is needed!

It is alternatives. The diversions are only needed until we can convince the 
mesa maintainers to ship their library in /usr/lib/mesa and install a primary 
alternative. (I haven't tried and I'm not sure if we really want to propose 
this).

> 4) for fglrx it would just be a little step for live booting, fglrx
> still needs a xorg.conf with some options (like defaultdepth)

nvidia-glx currently needs the following minimal xorg.conf to be used (since 
there is no autodetection)

Section "Device"
        Identifier "GPU"
        Driver "nvidia"
EndSection

> I understand your position and it is a good idea to add fglrx to live
> cds, but I don't see any good solution (without ugly workarounds) to
> implement it, yet.

Something I can offer to the fglrx maintainers is to generalize the 
diversion/alternatives packages so that it supports fglrx, too. This should 
be not too difficult. But eventually we should rename the packages (something 
that contains "xorg" and "non-free" perhaps?) and move the location of the 
diversions to remove the references to nvidia.
I can also help getting the diversions migrated properly and the alternatives 
set up.

Does fglrx have some "legacy" versions, too, or does the current driver 
version still support all cards that were ever supported by fglrx?

> Maybe it would be better to install the {fglrx,nvidia}-glx package on
> probing?
>
> I am CCing the xstrike force, maybe they have got some 50 cent to this
> topic :)


One thing that probably won't be solved by the currently evolving free drivers 
(nouveau etc) is support for the GPGPU computation frameworks (CUDA, 
OpenCL) - therefore we will need the non-free drivers in the future, too. :-(


Andreas