nvidia proprietary driver package

[ArchangeGabriel]

I've open an issue tracker on this repo to have a common place for sharing ideas about packaging.

First thing to be disscussed here is the nvidia driver package. We currently depend on nvidia-current. But...

There is also nvidia-current-updates (which is quite supported inside Bumblebee), and the new nvidia-experimental, which appends the version number: it currently exists nvidia-experimental-304 and nvidia-experimental-310.

Problems:

• those packages seems to have different modules name (nvidia, nvidia-current, nvidia-current-updates, and, not tested but guessed, nvidia-experimental-304, nvidia-experimental-310).
• they also seems to use different library paths (which lead only nvidia-current to be supported in fact).
• they are all in conflict which each others, but bumblebee-nvidia depends on nvidia-current, so that's the only one that can be installed right now.

However, I know that at least some users want to be able to choose the one they want within this list, and not be forced to use nvidia-current.

What do we have to do in order to support all those variations ?

[Lekensteyn]

• The module is named "nvidia_experimental_304" instead of "nvidia_current" according to debian/dkms.conf.
• The package provides and conflicts "nvidia-current" and "nvidia-current-updates" according to debian/control. Because it provides "nvidia-current", I see no dependency issue.

Other than editing the module paths, I see no issues. Currently, the Ubuntu package of Bumblebee is already patched to handle these crazy module paths, but now it is getting worse. If the package is from now on called "nvidia-experimental-XXX", then we can use globbing to find out the new paths.

[ArchangeGabriel]

The issue on dependencies is that bumblebee-nvidia installs nvidia-current, and when you try to install an other one, it uninstall nvidia-current, and bumblebee-nvidia by the way. But maybe that's a weird dpkg/apt behaviour.

[Lekensteyn]

Is that really happening right now? Isn't dpkg smart enough to see that nvidia-experimental-XXX provides nvidia-current?

[ArchangeGabriel]

Yeah, it's really happening, I tested it my self. If you try to install an other driver than nvidia-current after having installed bumblebee+nvidia, it's uninstalling nvidia-current and bumblebee-nvidia (because depending on the former one) before installing the new nvidia package, without reinstalling nvidia-current. However I didn't check wether resinstalling bumblebee-nvidia afterwards does work or not, I guess so, but I'll make some tests to be sure of all results.

[Marzal]

I have done some testing and I can't make bumblebee work with anything else than bumblebee-nvidia -> nvidia-current

Ubuntu 12.10:

bumblebee-nvidia -> nvidia-current = OK

Install nvidia-current-updates force uninstall of nvidia-current and bumblebee-nvidia = Desktop black screen without menus.

With nvidia-current-updates installed (no desktop) try to install bumblebee-nvidia forces uninstall nvidia-current-updates but Desktop is usable again.

[Lekensteyn]

@ArchangeGabriel can you have a look at this? I don't see why nvidia-current gets installed if it is provided. Maybe it is because of the explicit version dependency (>= 260.....)? Could it work if we use nvidia-current (>= 260...) | nvidia-current-updates instead? Or drop the nvidia-current version dependency altogether since this is already satisfied on raring, quantal and precise.

[ArchangeGabriel]

@Lekensteyn I've told you that before, dpkg has a weird behaviour with this. I will try several possiblities (including those you're proposing) to make this work.

[amonakov]

There is dpkg log and package headers at: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-experimental-310/+bug/1085044

The reason it doesn't work as intended seems to be due to the fact that nvidia-experimental-310 package lists nvidia-current in "Conflicts:" section (in addition to "Provides:"). Jeez.

[Walther]

A comment from the Launchpad bug that could make sense, from Dave Gilbert:

"
http://www.debian.org/doc/debian-policy/ch-relationships.html says:
'If a relationship field has a version number attached, only real packages will be considered to see whether the relationship is satisfied (or the prohibition violated, for a conflict or breakage). In other words, if a version number is specified, this is a request to ignore all Provides for that package name and consider only real packages. The package manager will assume that a package providing that virtual package is not of the "right" version. A Provides field may not contain version numbers, and the version number of the concrete package which provides a particular virtual package will not be considered when considering a dependency on or conflict with the virtual package name.[52]'

So I'd agree with Jibel that Bumblebee is trying to do something that won't work; so it is Bumblebee's bug.

Having said that; what Bumblebee wants to do is reasonable - i.e. make sure it has at least a particular version of the nvidia driver; I just don't see there is a way to do that.
"

OTOH, I don't know much about these things, just want to get this fixed asap, and willing to help :)

[ArchangeGabriel]

Ok, thanks for those informations, I was lacking time to investigate but you've bring the solution.

So only Lucid is concerned with a driver older than 260 currently, however this release doesn't any other flavour of nvidia driver (no -updates version). I will remove version dependency on newer release, and only let this for Lucid. Will try do so today or tomorrow at worse.

[Walther]

Gee, glad to be of help! Willing to test the new version as soon as it hits the repository, thanks for support, keep up the good work

[Walther]

Hm, any progress? At least I haven't seen an update to bumblebee to appear yet in the repos

[ArchangeGabriel]

Sorry, I was more busy than I first though, and I've just updated the package. So they're waiting on testing for building, and I will copy them to stable when done.

[zole052]

with nvidia experimental :/
zole052@zole052-lap:~$ optirun glxspheres
[ 152.202015] [ERROR]Cannot access secondary GPU - error: Could not load GPU driver

[ 152.202108] [ERROR]Aborting because fallback start is disabled.

[Walther]

Confirmed, on nvidia-experimental-310 and newest bumblebee, bumblebee-nvidia
walther@affogato:~$ optirun glxspheres
[ 5701.891785] [ERROR]Cannot access secondary GPU - error: Could not load GPU driver

[ 5701.891877] [ERROR]Aborting because fallback start is disabled.

[ArchangeGabriel]

Yes, this is because nvidia-experimental is not supported currently in Bumblebee.

Could you please provide the output of lspci -v -s 01:00.0 with nVidia card ON, and modinfo on the nvidia driver ?

@Lekensteyn I'm guessing it will be something like nvidia-experimental-304, nvidia-experimental-310, ... Should we hardcode each of them in the fallback patch or do you have a better idea for them ?

[Walther]

This is what I get, though I'm not sure if the Nvidia card is ON as you specified (no setting in BIOS to force either way)

walther@affogato:~$ sudo lspci -v -s 01:00.0
01:00.0 3D controller: NVIDIA Corporation Device 1140 (rev a1)
Subsystem: ASUSTeK Computer Inc. Device 1507
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at f6000000 (32-bit, non-prefetchable) [size=16M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
Memory at f0000000 (64-bit, prefetchable) [size=32M]
I/O ports at e000 [size=128]
Expansion ROM at f7000000 [disabled] [size=512K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Capabilities: [b4] Vendor Specific Information: Len=14 Capabilities: [100] Virtual Channel Capabilities: [128] Power Budgeting
Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>

walther@affogato:~$ modinfo nvidia_experimental_310
filename: /lib/modules/3.7.0-4-generic/updates/dkms/nvidia_experimental_310.ko
alias: char-major-195-*
version: 310.14
supported: external
license: NVIDIA
alias: pci:v000010DEd00000E00sv_sd_bc04sc80i00*
alias: pci:v000010DEd00000AA3sv_sd_bc0Bsc40i00*
alias: pci:v000010DEd_sv_sd_bc03sc02i00_
alias: pci:v000010DEd_sv_sd_bc03sc00i00_
depends:
vermagic: 3.7.0-4-generic SMP mod_unload modversions 686
parm: NVreg_Mobile:int
parm: NVreg_ResmanDebugLevel:int
parm: NVreg_RmLogonRC:int
parm: NVreg_ModifyDeviceFiles:int
parm: NVreg_DeviceFileUID:int
parm: NVreg_DeviceFileGID:int
parm: NVreg_DeviceFileMode:int
parm: NVreg_RemapLimit:int
parm: NVreg_UpdateMemoryTypes:int
parm: NVreg_InitializeSystemMemoryAllocations:int
parm: NVreg_RMEdgeIntrCheck:int
parm: NVreg_UsePageAttributeTable:int
parm: NVreg_EnableMSI:int
parm: NVreg_MapRegistersEarly:int
parm: NVreg_RegisterForACPIEvents:int
parm: NVreg_CheckPCIConfigSpace:int
parm: NVreg_RegistryDwords:charp
parm: NVreg_RmMsg:charp

[zole052]

lspci -v -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 520MX](rev a1) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Device 1762
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at db000000 (32-bit, non-prefetchable) [size=16M]
Memory at c0000000 (64-bit, prefetchable) [size=256M]
Memory at d0000000 (64-bit, prefetchable) [size=32M]
I/O ports at d000 [size=128]
Expansion ROM at dc000000 [disabled] [size=512K]
Capabilities:
Kernel modules: nvidia_experimental_310, nouveau, nvidiafb

modinfo nvidia-experimental-310
filename: /lib/modules/3.5.0-19-generic/updates/dkms/nvidia_experimental_310.ko
alias: char-major-195-*
version: 310.14
supported: external
license: NVIDIA
alias: pci:v000010DEd00000E00sv_sd_bc04sc80i00*
alias: pci:v000010DEd00000AA3sv_sd_bc0Bsc40i00*
alias: pci:v000010DEd_sv_sd_bc03sc02i00_
alias: pci:v000010DEd_sv_sd_bc03sc00i00_
depends:
vermagic: 3.5.0-19-generic SMP mod_unload modversions 686
parm: NVreg_Mobile:int
parm: NVreg_ResmanDebugLevel:int
parm: NVreg_RmLogonRC:int
parm: NVreg_ModifyDeviceFiles:int
parm: NVreg_DeviceFileUID:int
parm: NVreg_DeviceFileGID:int
parm: NVreg_DeviceFileMode:int
parm: NVreg_RemapLimit:int
parm: NVreg_UpdateMemoryTypes:int
parm: NVreg_InitializeSystemMemoryAllocations:int
parm: NVreg_RMEdgeIntrCheck:int
parm: NVreg_UsePageAttributeTable:int
parm: NVreg_EnableMSI:int
parm: NVreg_MapRegistersEarly:int
parm: NVreg_RegisterForACPIEvents:int
parm: NVreg_CheckPCIConfigSpace:int
parm: NVreg_RegistryDwords:charp
parm: NVreg_RmMsg:charp

[ArchangeGabriel]

Ok, thank you, the issue is the one I was thinking about.

So just wait for Lekensteyn for coming with a shiny idea, else I will hardcode this driver in the patch.

[Lekensteyn]

@ArchangeGabriel Hardcoding the version numbers is not a nice solution that will work in the future. What about giving instructions to the user so he can change KernelDriver in bumblebee.conf? That configuration file exists for a reason. If a user installs nvidia-experimental, he is accepting the risk.

Any chance that Ubuntu is going to provide a modprobe.conf alias for nvidia-experimental-xxx?

[Marzal]

I think WebUpd8 has made a How-to for this scenario: https://plus.google.com/u/0/101912980608854649615/posts/Y74VXb7HRAW

gksu gedit /etc/bumblebee/bumblebee.conf

• on line 22, make sure "Driver=" is set to "nvidia", like this:
  Driver=nvidia
• change the "KernelDriver=" (on line 47) to "nvidia-experimental-310", like this:
  KernelDriver=nvidia-experimental-310
• change "LibraryPath=" (on line 51) to "/usr/lib/nvidia-experimental-310:/usr/lib32/nvidia-experimental-310", so it looks like this:
  LibraryPath=/usr/lib/nvidia-experimental-310:/usr/lib32/nvidia-experimental-310
• change the "XorgModulePath=" (line 54) to "XorgModulePath=/usr/lib/nvidia-experimental-310/xorg,/usr/lib/xorg/modules" so it looks like this:
  XorgModulePath=/usr/lib/nvidia-experimental-310/xorg,/usr/lib/xorg/modules

I haven´t tested it but no one complaints in the comments.

[Lekensteyn]

@Marzal Those instructions are correct, I forgot to mention the solution here since it is just a matter of reading the comments in the configuration file.

[ArchangeGabriel]

Ok, at this time I finally went into only relaxing nvidia-current version number dependency. I'm going to add info on the ppa page about using nvidia-experimental-nnn and will now consider this issue as closed.

[ArchangeGabriel]

@Lekensteyn BTW, since LibraryPath and XorgModulePath have to be adjusted for nvidia-current-updates in bumblebee.conf, do we need to keep it in the fallback probe patch ? Or maybe we should had the feature requested by Thulinma, i.e. auto-detect LibraryPath (and XorgModulePath then).

What do you think about that ? What should Bumblebee auto-detect and set, what should be at the sole discretion of the user ?

[corneacraneo]

I modified the bumblebee.conf to accept the nvidia-experimental-XXXX, and an optirun command does work. But, a primusrun command doesn't. I don't get to find a similar primus.conf file :(

[ArchangeGabriel]

You have to edit primusrun script to adjust libGLa and LD paths.

[corneacraneo]

After writing my issue, I got the answer here: http://steamcommunity.com/app/221410/discussions/0/846938350770109358/#c846939071079333610
Thanks for your quick answer, too. 👍

[ArchangeGabriel]

@Lekensteyn So, LD_PATH auto-detect or patch removing ?

[ArchangeGabriel]

It was decided to remove the patch for now on. An option could be to autodetect the driver at daemon start through an udev rule for example.

[ArchangeGabriel]

@Lekensteyn Could we do something on this ? If I understand well, we're having more and more nvidia driver flavor on Ubuntu, all with different module names and library paths...

How could we properly detect which one to use, or is there a wrapper fo all of them ?

[Lekensteyn]

Oh, damn that is right. Now that the kernel module name is solved, we still have the paths (ModulePath and LibraryPath) that needs to be updated... checking things (I am on IRC in a minute).

[ArchangeGabriel]

Other problem: bumblebee.conf file for blacklisting modules does not blacklist all these new flavors...

[starks]

nvidia-313 works just fine with Bumblebee if you set the conf files right

[Lekensteyn]

@ArchangeGabriel can you try my changes in the bumblebee-3.1-proposed branch? (mainly the init thing). It should work, but I have not tested it since I am not using Ubuntu.

@starks Yes, if you set the conf files right, but now there exist nvidia-310, nvidia-experimental-304 and whatnot. I have changed the initscript to "fix" this for ease of maintenance.

[ArchangeGabriel]

Fixed by @Lekensteyn in bumblebee-3.1-proposed (except for blacklisting, which we do manually).