Changes in 304.37 - UseDisplayDevice none

[ArchangeGabriel]

So, the new nVidia driver is nice, with a lot of new features and fixes. Also, they're now a lot of references to Optimus in the nVidia Linux documentation, and especially this one :

Option "UseDisplayDevice" "string"

    The "UseDisplayDevice" X configuration option is a list of one or more display devices, which limits the display devices the NVIDIA X driver will consider for an X screen. The display device names used in the option may be either specific (with a numeric suffix; e.g., "DFP-1") or general (without a numeric suffix; e.g., "DFP").

    When assigning display devices to X screens, the NVIDIA X driver walks through the list of all (not already assigned) display devices detected as connected. When the "UseDisplayDevice" X configuration option is specified, the X driver will only consider connected display devices which are also included in the "UseDisplayDevice" list. This can be thought of as a "mask" against the connected (and not already assigned) display devices.

    Note the subtle difference between this option and the "ConnectedMonitor" option: the "ConnectedMonitor" option overrides which display devices are actually detected, while the "UseDisplayDevice" option controls which of the detected display devices will be used on this X screen.

    Of the list of display devices considered for this X screen (either all connected display devices, or a subset limited by the "UseDisplayDevice" option), the NVIDIA X driver first looks at CRTs, then at DFPs, and finally at TVs. For example, if both a CRT and a DFP are connected, by default the X driver would assign the CRT to this X screen. However, by specifying:

        Option "UseDisplayDevice" "DFP"

    the X screen would use the DFP instead. Or, if CRT-0, DFP-0, and DFP-1 are connected and TwinView is enabled, the X driver would assign CRT-0 and DFP-0 to the X screen. However, by specifying:

        Option "UseDisplayDevice" "CRT-0, DFP-1"

    the X screen would use CRT-0 and DFP-1 instead.

    Additionally, the special value "none" can be specified for the "UseDisplayDevice" option. When this value is given, any programming of the display hardware is disabled. The NVIDIA driver will not perform any mode validation or mode setting for this X screen. This is intended for use in conjunction with CUDA or in remote graphics solutions such as VNC or Hewlett Packard's Remote Graphics Software (RGS).

    "UseDisplayDevice" defaults to "none" on GPUs that have no display capabilities, such as some Tesla GPUs and some mobile GPUs used in Optimus notebook configurations.

    Note the following restrictions for setting the "UseDisplayDevice" to "none":

        OpenGL SyncToVBlank will have no effect.

        None of Stereo, Overlay, CIOverlay, or SLI are allowed when "UseDisplayDevice" is set to "none".

So as long as everyone would be using this version (or maybe the stable release following), which we could ensure via dependencies, we could remove ConnectedMonitor and set UseDisplayDevice "none" instead. And it may even speed up Xorg start, because the driver has a lot less work to do. I'm going to try this right now on my system.

An other important change is that the module name on Ubuntu has finally changed from nvidia-current to nvidia. We should take this into account.

[Lekensteyn]

Note this line:

"UseDisplayDevice" defaults to "none" on GPUs that have no display capabilities, such as some Tesla GPUs and some mobile GPUs used in Optimus notebook configurations.

It shouldn't really be necessary to set this to make things work. Setting it will also disable any possibilities for an external monitor, so even if we change it, we have to put some comments in the xorg.conf.nvidia file.

[ArchangeGabriel]

Yes but this default doesn't work if "ConnectedMonitor" is set. So we indeed need either to remove both or set "UseDisplayDevice" "none", and anyway we have to add some comments, yea.

[ArchangeGabriel]

Ok, 304.37 is now live on x-updates, we have to discuss rapidly what we do. Anyway, we have to change Module=nvidia to Module=nvidia-current (finally they switched back to nvidia-current, and changed the module name rather than the KernelDriver's one).

Could you join on IRC @Lekensteyn so that we can discusss what we do before they will be 1k #232 issues ?

[Lekensteyn]

Do you know if adding UseDisplayDevice "none" generates a syntax error for older drivers? Also, since UseDisplayDevice "none" should prevent ports from being probed, is it safe to keep the ConnectedMonitor setting for older drivers?

I'll join after lunch.

[amonakov]

Do you know if adding UseDisplayDevice "none" generates a syntax error for older drivers?

It doesn't.

Also, since UseDisplayDevice "none" should prevent ports from being probed, is it safe to keep the ConnectedMonitor setting for older drivers?

It is safe.

[ArchangeGabriel]

You intend to put both lines ? I'm not sure if it will works for people using 304.37, will try that as soon as possible.

IMO the best is to force 304.37 as minimal dependency, but I'm waiting for you on IRC to discuss that.

[ArchangeGabriel]

Breaking News : they changed the name again. So now, it's different if you're using xorg-edgers PPA or x-updates one.

For the first one, the change is Module=nvidia to Module=nvidia-current.

For the second one, the change is KernelDriver=nvidia-current to KernelDriver=nvidia, which was what was done previously on xorg-edgers...

By the way, setting Driver=nvidia is mandatory to prevent autodetection problems within Bumblebee.

[amonakov]

Why does Module= setting matter? I don't see how it's used in bumblebee.

[ArchangeGabriel]

It's used for unloading the nvidia module. The daemon can't even start if this option is not correctly set. This was introduced because of Ubuntu, where the module you modprobe is (until 304) nvidia-current, but once loaded its name is nvidia.

Which is weird, and there is an open issue on Launchpad for it. So, apparently they choosed to change everything for nvidia (which is what is done in most distro), or nvidia-current, but they don't seem to be sure of which way to go.

We had some troubles with it, and this was the easiest way to work around it.

[amonakov]

AFAICS, in Bumblebee sources in this repository, the name to use for unloading is taken from Driver= setting, not Module=. Does packaging for Ubuntu involve applying some patches?

[ArchangeGabriel]

I'm not sure, Lekensteyn is the one that writed that all, but it should be here : https://github.com/Bumblebee-Project/Bumblebee/blob/master/src/bbconfig.c#L424

[ArchangeGabriel]

https://github.com/Bumblebee-Project/Bumblebee/blob/master/src/bumblebeed.c#L349 https://github.com/Bumblebee-Project/Bumblebee/blob/master/src/driver.c https://github.com/Bumblebee-Project/Bumblebee/blob/master/src/module.c

I think you should be able to understand with all that (I'm not having any knowledge in C, but it seems to be that parts).

[amonakov]

I did read all of that, and also bbconfig.c. That's why I'm telling you that in current bumblebee sources Module= setting is never used.

[ArchangeGabriel]

This is really strange then, because if I change it, Bumblebee can't start.

[Lekensteyn]

Clarification:

• Driver: shows up in /proc/modules, used for determining whether a module is loaded (if it happens) and unloading using rmmod
• KernelModule: filename of the module without .ko, used for loading with modprobe only.

I guess it's safe to patch the Ubuntu code to check for both KernelDriver and "nvidia" when using Driver=nvidia? Could it also benefit other distros? If necessary, I can add an --with-nvidia-fallback or something to configure to control the extra fallback probe.

[ArchangeGabriel]

Hum, there is Driver, KernelDriver and Module. Which one is used for what ?

[Lekensteyn]

Module seems to be ignored. It was added by Samsagax in 4ca50b33e1823c3ff9b28183b883467bd135ab12.

[ArchangeGabriel]

Have to check what name are used where on Ubuntu...

[ArchangeGabriel]

So for the module name to load, we have nvidia (e.g. currently for x-updates), nvidia-current (classic one) and nvidia-current-updates.

Will check what's going on once loaded.

[ArchangeGabriel]

Ok, so loaded it's ever nvidia.

About ConnectedMonitor and UseDisplayDevice, if both are set, in any order, UseDisplayDevice none is used over ConnectedMonitor with 304.37 driver. Now I have to check with older one, even if you, @amonakov, have already checked that, I want to compare outputs.

[ArchangeGabriel]

Hum in fact I'm not able to install an older one on this setup.

@amonakov, if you're able to acces an Optimus laptop with older driver, could you please past the Xorg.8.log for the four following setups : 1) Only ConnectedMonitor 2) Both, ConnectedMonitor first, UseDisplay second 3) Same as 2) but reverse order 4) Only UseDisplayDevice (weird one, just to check)

[amonakov]

I have a Kepler-based laptop with zero outputs connected to the Nvidia card. Whatever the driver version is, whatever ConnectedMonitor and UseDisplayDevice values are given (or not given at all), they are ignored by the driver. In other words, before 304.22 X would not start for me irregardless of the configuration, and with 304.22 it would start (again, irregardless of the configuration). You probably want to ask someone else for whom pre-304.22 drivers worked fine.

[ArchangeGabriel]

Indeed, you're setup is not really usefull here. I will try a live session of 12.04 to see the results.

[Samsagax]

Using Xserver v 1.12.3, nvidia driver 302.17

1) Only ConnectedMonitor 2) Both, ConnectedMonitor first, UseDisplay second 3) Same as 2) but reverse order 4) Only UseDisplayDevice (weird one, just to check)

1 - OK; as usual 2 - OK, warning on Xorg log: [ 1718.222] (WW) NVIDIA(0): Option "UseDisplay" is not used (http://pastie.org/4522685 ) 3 - OK; same as above ( http://pastie.org/4522696 ) 4 - Not working; wasn't that obvious :P ( http://pastie.org/4522685 )

[ArchangeGabriel]

So we can set both option at the same time. Nice to hear, I'm changing it right now.

[ArchangeGabriel]

Lekensteyn, could you update what's accurate (in mind: multi-monitor-setup, but they may be other ones) in the wiki about this change ?

[Lekensteyn]

I do not have a chance to test it (since all ports are wired to the intel chip, not the nvidia one), but I guess that the multi monitor setup gets broken by this.

[ArchangeGabriel]

Yes, that's why you've said this "Setting it will also disable any possibilities for an external monitor, so even if we change it, we have to put some comments in the xorg.conf.nvidia file.".

But I think that xorg.conf is not the place for such comments, and the wiki page you've written (that's you, isn't it ?) looks better for that ?

[Lekensteyn]

That wiki page acts more like a guide. Users who are going to edit the xorg.conf are better supported by direct comments rather than the online wiki (assuming they do not read documentation).

[ArchangeGabriel]

So, we should add the documentation page in xorg.conf ?

Maybe just add a line to point to the wiki, and/or comments about lines to delete...

[Lekensteyn]

Short line explaining why a certain line is necessary, the wiki contains some background information for those who want to make a multi-monitor setup.