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
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201101240248.24629.deb...@abeckmann.de
