Proprietary Video Drivers

[woodsman]

Question:

What is the expected Salix method for installing proprietary video drivers?

In Slackware, the normal method is to build the package. Yet that method requires having the kernel sources installed, which Salix does not provide out-of-the-box. Thus a pre-compiled package is necessary.

Further, Salix is designed and intended for point-and-click desktop users, not geeks who want to build packages.

Salix provides a one-click tool to install proprietary multimedia support. Therefore I imagine there is no philosophical reason not to provide proprietary video packages too.

[gapan]

What is the expected Salix method for installing proprietary video drivers?

Although I'm probably not the right person to respond, as I have absolutely no PCs that require proprietary video drivers, I would say download and install from the proprietary vendor's site.

Further, Salix is designed and intended for point-and-click desktop users

If you're talking about the "full" installation mode, and if that statement means that most tasks can be accomplished through a GUI, then yes. "Basic" and "core" installation modes come nowhere close to that description though.

Salix provides a one-click tool to install proprietary multimedia support. Therefore I imagine there is no philosophical reason not to provide proprietary video packages too.

You are confusing patent-encumbered with proprietary. These are two completely different things. The only proprietary package that comes with salix is the flash plugin and I'm really hoping we can replace that one someday in the future with a better gnash or something (or flash to be obsoleted by HTML5 video).

[thenktor]

I can only speak for NVidia:

What is the expected Salix method for installing proprietary video drivers?
In Slackware, the normal method is to build the package.

sh NVIDIA-Linux-x86-1xx.xx.xx-pkg1.run
No idea why I would want to build a package for it.

or flash to be obsoleted by HTML5 video

Hehe, are you dreaming?

[JRD]

Hehe, are you dreaming?

Microsoft aksed for joining the W3C group for SVG...So maybe HTML5 Video + SVG + JS (SMIL) could totaly replace Flash !!

[thenktor]

Would be good

[tasodan]

I can only speak for NVidia:

What is the expected Salix method for installing proprietary video drivers?
In Slackware, the normal method is to build the package.

sh NVIDIA-Linux-x86-1xx.xx.xx-pkg1.run
No idea why I would want to build a package for it.

For removing and reinstalling the kernel module easily when you'll update the kernel:

Code: Select all

removepkg nvidia-kernel
installpkg  nvidia-kernel-190.42_2.6.X.Y-mynewkernel-x86_64-1td.txz

and for removing and installing a new driver (and its kernel module) easily when you'll update the xorg-server:

Code: Select all

removepkg nvidia-driver nvidia-kernel
installpkg nvidia-driver-NEW.DRIVER-x86_64-1td.txz nvidia-driver-NEW.DRIVER_2.6.X.Y-mynewkernel-x86_64-1td.txz

These are the txz packages (version 190.42) I've built for x86_64 and kernel 2.6.29.6 (thanks to slackbuilds.org):
http://people.salixos.org/tasodan/x86_6 ... ia-driver/
http://people.salixos.org/tasodan/x86_6 ... ia-kernel/
http://people.salixos.org/tasodan/x86_64/l/libvdpau/

and this is the slackbuild you can use to create your own kernel module:
http://people.salixos.org/tasodan/x86_6 ... SlackBuild

[thenktor]

For removing and reinstalling the kernel module easily when you'll update the kernel:

Code: Select all

rm -rf /lib/modules/$OLDKERNELVERSION
sh NVIDIA-Linux-x86-1xx.xx.xx-pkg1.run

and for removing and installing a new driver (and its kernel module) easily when you'll update the xorg-server:

Code: Select all

sh NVIDIA-Linux-x86-1xx.xx.xx-pkg1.run

[tasodan]

the classial way, with the installer, is easy too (but only for nvidia, not for ATI), but I prefer the txz/tgz packages because I like manage all and know all packages installed on my system with pkgtool: pkgtool (and gslapt) "doesn't see" a package .run installed.

[woodsman]

Thanks for the responses.

I think installing a package is much cleaner than running rogue *.run scripts. The challenge is on the backside when people want to update or remove the software. Package management renders the removal and updating process more seamless and less intrusive. I shudder every time I read an online article where the author instructs readers to run config, make, and make install. How do such people maintain their systems?

My thoughts are that end-users should find the proprietary video drivers in the Salix repositories and final CD. As the kernel sources (usually) remain static between releases, providing video driver packages is straightforward. In my Slackware environment where I have to build those packages, I use a naming convention in the package name that informs me of both the kernel and driver version number. A Salix package could do the same. For example:

nvidia-driver_185.18.31_2.6.27.7_smp_1
nvidia-kernel_185.18.31_2.6.27.7_smp_1

That naming convention would help Salix users know which package to download and install. Users would need to learn that the kernel version in the package name is the most important criterion. Yes, the nvidia drivers are updated frequently. There is no reason why several packages cannot be offered on the CD and repositories. If a user has problems with one version then try another. For example, recently I built and tested the 190.42 version. They worked --- sort of. My system was very slow. I reverted to 185.18.31 and my system was snappy again.

Related to this conversation, I'm wondering how Salix would have installed on my home theater PC (HTPC). In that system I have an Asus M3N78-EM motherboard with on-board video. Hardly bleeding edge but not an old board either. Yet the generic nv driver does not support the chip set on that motherboard. Development on the nv driver has dwindled as people invest more energy in the nouveau driver. Regardless, when I tested Slackware 13.0 this past summer as a candidate for my operating system for my HTPC, I could use only the vesa drivers and the proprietary nvidia drivers.

I would have had the same results had I tested Salix 13.0.x. I would have encountered more work too. First I would have to download the kernel sources package. Second I would have to build the package. I don't envision many point-and-click users finding that process palatable. Most people come from the Windows world and they know enough that sometimes they have to insert a CD to install special drivers. They would expect something similar in a package management system. Point, click, download, install. They are happy. Any Salix user who uses a motherboard not supported by the generic nv driver will be frustrated. I have read many similar reports with the ATI drivers. Hence my recommendation to include the proprietary drivers as a package in the repositories and on the final CD.

Just an idea.

[JRD]

I agree with you about building packages for the nvidia drivers. Do I understand that you offer you help in this area?
Be careful, there must be numerous packages to build and maintain:
- 3 generations of nvidia proprietary drivers as regularly nvidia drop some cards.
- 2 processors target (486 and x86_64).

About putting them on the CD, I don't think so because it's proprietary drivers and we try to provide a free system. If you want to remain free you could always use vesa if your material is not supported by the free nv driver. It's your personal choice to use a proprietary driver.

So, are you offering your help in building these packages ?