[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: segmentation fault with NVIDIA 32bit part



On Tue, Oct 6, 2009 at 9:46 PM, lee <lee@yun.yagibdah.de> wrote:

> Then there would need to be only two packages: vdpau for those who
> need it, and the rest (which could suggest vdpau which could tell you
> which cards can use it).

Doing that would probably not be possible, given the nature of this
particular component. nvidia's drivers have always had a kernel-space
component and a user-space component (the user-space component is
nvidia-glx, the kernel is nvidia-kernel-source or variations thereof).
Not having nvidia's drivers completely opem makes the process more
complicated, since other drivers (intel, for example) have begun to
put some of their code in the kernel proper, but essentially from the
user's perspective it's a unified driver that exists totally in
userspace.

What complicates the matter further is that the kernel space part of
the driver has to match the kernel you run. If you're on stable or
testing then you might not have new versions of the kernel just
popping up, but if you change the kernel, you have to rebuild the
module. In some respect ubuntu automates this process - and perhaps
debian does as well; I've not actively used nvidia since switching to
intel back in December. But for instance, my virtualbox has a kernel
space part and that gets automatically updated as part of the upgrade
process any time the kernel changes. (And on karmic, new revs of the
kernel are somewhat frequent.)

But in general, separation of components is not uncommon. Sometimes
documentation is separated from the executable, or a development set
is separated from the libraries. That's to save on space, and not
everyone who has a particular library needs the development component
automatically installed.




-- 
thanks for letting me change the magnetic patterns on your hard disk.


Reply to: