On Tue, Oct 6, 2009 at 6:59 PM, lee <l...@yun.yagibdah.de> wrote: > > And nvidia-kernel-common: > > > "This package contains files shared between NVIDIA module packages."
Common refers essentially to support files., You should install the package, but it's not dependent on the driver or the version of the kernel. > nvidia-kernel-source: > > > "This package builds the NVIDIA Xorg binary kernel module needed by > nvidia-glx." For whatever kernel you have. It's tied to the specific release of the driver version, whatever that may be from testing/unstable. Since it is source, after you do a module-assistant auto-install, it'll compile that driver for the kernel you have. Since you have a non-standard kernel, there might be problems, but then again there may not be. > I don't know about vdpaul --- is that included in the nvidia > installer? vdpau is something that's special to some higher-end nvidia cards. You may not need that, depending on what card you have. The link here [1] itemizes supported cards. > Why are the package descriptions so poor, and why can't there just be > one package you install? It would be nice, but essentially you need three components, nvidia-glx, nvidia-common and nvidia-kernel-source. The first and third have to match as far as the driver revision, otherwise you get nasty messages from X. One of these should autoinstall nvidia-common since it may be dependent on the other two. But it's been sometime since I messed with nvidia (now using on board Intel graphics). > Since my card isn't even supported in testing, I'd have to get those > packages from unstable. I've tried using packages from unstable a > couple times, but the results haven't been good. Using pinning and judicious use of aptitude install <package> -t unstable when only necessary should make things easier. There have been occasions when I needed the nvidia driver from (then) unstable. This was over a year ago when I was using an nvidia card on an old 32 bit system. Once it worked like a charm, the other time I found that the driver update had (wrongly) decided to include support for instructions that my processor did not support (movaps/movups). Turns out that the driver was compiled this way, and the only recourse to get it to work was to downgrade the package to the prior version. Since I now have an amd64 I can put such frustration behind me, but it's bitten me before several times. (My prior cpu was an Athlon Tbird/1000 which had some support for mmx/3dnow, but assumptions were made occasionally that said basically any modern 386 based system would support these instructions, and support for them only arrived in later versions of the AMD platform.) And it was with some other distributions at well. -- thanks for letting me change the magnetic patterns on your hard disk. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
