installing NVIDIA non-free binary package requires manual configuration

As an nvidia-glx-legacy user please don't do this. The non-legacy nvidia binary package is installed by default so if things were defaulted to the nvidia binary driver X would (by default) appear broken to me. Also software suspend is horribly broken with the binary drivers for me and further, nvidia have yet to release patches to make it work in 2.6.16 kernels (see https://bugzilla.novell.com/show_bug.cgi?id=147009 )

At least under the current system people quickly know if the binary driver is going to be problematic because they have to enable it by hand.

If that is in fact the case then perhaps the nvidia binary driver should not be installed by default. However, I was under the impression that it had to be installed explicitly.

In any case, I am not advocating that the proprietary driver should be part of the default ubuntu-desktop installation. My criticism is that when a user installs the nvidia-glx package, it is left in a somewhat unconfigured state unlike the many other packages in the repositories that are cleanly installed and removed.

I totaly agree with Jonathon. It was discuted in the ML [1]. The best solution was to add a debconf key which ask the user if he want to "activate" to driver. The default should be "yes" and the priority should be high. like that normal users will have the driver enabled by default without any question, and power-users can still disable the driver easily.

To enable the driver, just run on the postinst of nvidia-glx a command like «nvidia-glx-config enable».

Many other configs can be added to debconf keys and applied using «nvidia-xconfig» command.

As mentioned in the thread [1] this is not the ideal solution, X should automaticaly select the right driver when starting, without any configuration, but I think that's the long-term solution. We really need a simple workaround in time for dapper !

[1] https://lists.ubuntu.com/archives/ubuntu-devel/2006-March/016138.html

By the way guys, the NVIDIA commercial driver is everything but a binary package. IF and only IF you take the time to extract their installer archive (and they do provide a convenient command-line switch to do that), you will notice that their whole driver is distributed as source code so that it can adapt to every kind of configuration without NVIDIA having to release millions of different module versions.

> you will notice that their whole driver is distributed as source code

Bloodypriest:

I'm being pedantic but it is a binary package with a bit of glue source to let the kernel try and call various functions in the binary object. If the whole thing is distributed as source, where on earth is the source to nv-kernel.o ? What about the source for the distributed libraries libGL.la libGLcore.so.1.0.* and so forth? What do all the different Xid messages mean? If you don't distribute all the source then you are anything but a source package.

That isn't to say this doesn't allow support for a wider range of kernels than a pure binary distribution - it does. However let's say the upstream kernel changes its support for how supsend to ram works. The only thing you can do now is change the glue source hooks to disable suspend to ram until NVIDIA release a new binary driver with the required support.

Currently, glue kernel source and a binary lump are about the only way to feasibly distribute binary drivers which have to run on more than one distro. This is the minimum that could be done.

The problem isn't if the driver is open source or not. The problem is that now an ubuntu user with a NVIDIA card has to manually run a command-line to activate the driver after his installation. I personnaly thinks it's unacceptable. The fix (workaround) is easy and can make the live of dapper's users easier.

Please considere to run the command « nvidia-glx-config enable » at the end of postinst !

Hope to see in the next release of the package!

Added link in
https://wiki.kubuntu.org/KubuntuDapperWhatStillNeedsAConsole

look at the livna fedora RPMs to see how this can be solved ideally (for the user):

"The Livna Nvidia and ATI driver RPMS come with a small python script, which works as an extension to system-config-xfree86. It does all the editing of the Xorg configuration file for you while installing/activating the driver.
[…]
Also, you do not need to drop out of X to perform the installation. And if you boot a kernel without Nvidia support, a boot script will automatically detect that the Nvidia kernel module is missing and revert to Xorg configuration."

http://mirrors.ircam.fr/pub/kde-redhat/apt/svn.livna.org/packages/nvidia-glx/devel/nvidia-README.Fedora
http://mirrors.ircam.fr/pub/kde-redhat/apt/svn.livna.org/packages/nvidia-glx/devel/nvidia-glx-init
http://rpm.livna.org/livna-switcher.html

http://livna.org/pipermail/freeworld/2006-October/000749.html

so what? i just said that this is how it is supposed to work for the end user (no manual configuration needed)

i understand that the livna method can't be copied 1:1 due to distribution differences, but i think it's worth a look

btw, the problem you mention is already fixed:
http://livna.org/pipermail/subversion/2006-October/004392.html

Is it so hard to add «nvidia-glx-config enable» in the postinst of nvidia-glx package ?!? I *really* don't understand why it's still not done. If there are some technical problem please tell me, otherwise please just add this command and close this bug.

Thanks.

Users of ATI video card has the same problem - installing ATI xorg-driver-fglrx drivers package requires manual configuration too :( xorg-driver-fglrx package contains fireglcontrolpanel configuration utility, but there are no menu launcher for this :(

I think same activation method - a debconf key, which ask the user if he want to "activate" to driver, should be used for xorg-driver-fglrx package too. Only command will be different:
aticonfig --initial

Should I report separate bug against xorg-driver-fglrx package ?

Btw, some time ago I've made initial script for automatic installation of video-drivers (currently supports new NVIDIA and ATI Radeon drivers), look at http://ftp.akl.lt/Linux/Baltix/install-video-drivers

I think this script could be extended to work with nvidia-legacy and other video drivers, which requires manual installing of driver packages and manual configuration.

Is this somewhat mitigated by restricted-manager in Feisty?

No mitigation if R-M isn't handling firmware correctly.

zeddock

zeddock:
To the best of my knowledge there is no firmware for the NVIDIA binary drivers (when you say firmware I assume small pieces of code that have to uploaded into the a given device before that device will function at all. An example of this is the firmware for Intel wireless cards that needs to be uploaded to the device before the driver can use the device).

So sorry!
I have two ONGOING problems in the linux/Ubuntu world... The nVidia Driver
for the 4200 and the bcm43xx firmware for the integrated wireless module. I
was confusing the two, driver versus firmware. Everything else is the same.

For instance,
R-M does not handle the nVidia driver (1.936??) correctly. So my statement
is still valid in that R-M would mitigate the real problem if it worked to
properly install the correct driver and configure xorg.conf to use it. But
it doesn't, so there is no mitigation through R-M.

Again, sorry for the mixup in my terms.
zeddock

On 9/12/07, Sitsofe Wheeler <email address hidden> wrote:
>
> zeddock:
> To the best of my knowledge there is no firmware for the NVIDIA binary
> drivers (when you say firmware I assume small pieces of code that have to
> uploaded into the a given device before that device will function at all. An
> example of this is the firmware for Intel wireless cards that needs to be
> uploaded to the device before the driver can use the device).
>
> --
> installing NVIDIA non-free binary package requires manual configuration
> https://bugs.launchpad.net/bugs/32853
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I am happy that it seems BOTH of my issues have been fixed in the latest Gusty.

zeddock

zeddock please don't talk about OT things like wireless in this bug, please keep on topic.

This bug is fixed? Does Gutsy install correctly drivers and change xorg.conf at the same time?

This bug is fixed, yes !!! \o/

Marking older components as "won't fix", since there are no plans to update the l-r-m packages for them.

As reported, this should work just fine on gutsy.