Alternative for determining "ConnectedMonitor" for xorg.conf.nvidia

[Lekensteyn]

The nvidia blob is that stupid that it cannot always detect the correct monitor setting. Therefore something like the below must be used for determining the monitor setting:

$ /usr/lib/nvidia-current/bin/nvidia-xconfig --query-gpu-info --nvidia-cfg-path=/usr/lib/nvidia-current
Number of GPUs: 1

GPU #0:
  Name      : GeForce GT 425M
  PCI BusID : PCI:1:0:0

  Number of Display Devices: 1

  Display Device 0 (CRT-0):
     No EDID information available.

The above output came from a Clevo B7130 which has an external VGA and HDMI connector and of course an internal connector to the LCD display.

At first I thought of some hardcoded table in the nvidia driver, but then it occured to me that it seeks access to /dev/nvidiactl which is a kernel interface. Searching for "DFP" in the ACPI Spec v4 pointed me at sect. B.4.2 _DOD (Enumerate All Devices Attached to the Display Adapter).

For the above output (Clevo B7130), the \_SB.PCI0.GFX0._DOD method returns a package containing three values:

• 0x80010100 (binary 1000 0000 0000 0001 0000 0001 0000 0000)
• 0x80010300 (binary 1000 0000 0000 0001 0000 0011 0000 0000)
• 0x80010410 (binary 1000 0000 0000 0001 0000 0100 0001 0000)

An explanation of all bits can be found in table B-2 on page 699 of the ACPI Spec v4. Explanation of the above values (bits are counted from right and zero-based):

• 0 - 3: display index (which is 0 in this case)
• 4 - 7: Display Port attachment. In this case, 1 and 0 (this is possibly not useful for us)
• 8 - 11: Display Type, for my case:
  • 0001 (1): "VGA, CRT or VESA compatible analog monitor" (external VGA?)
  • 0011 (3): "External Digital Monitor (see note 1)" (external HDMI?)
  • 0100 (4): "Internal/Integrated Digital Flat Panel (see note 2)" (internal LCD?)

Notes (taken from the ACPI Spec v4, page 701:

1. An “External Digital Monitor” is an external display device attachable via a user-accessible connector standard (e.g. DFP* or DVI* Compatible Monitors).
2. An “Internal Flat Panel” is a non-detachable fixed pixel display device, including a backlight, and is internally associated, without user-accessible connectors, to the Video Chip (e.g. TFT LCD via TMDS_, LVDS_ interface).

Now, how could this be useful? I'll check it later this day.

[ArchangeGabriel]

Internal LCD = LVDS.

I will wheck what I get too, but what we need is the result from a DFP computer in order to compare.

Is someone having one in the team ?

[Lekensteyn]

We're lucky, Thulimna has an Asus K93SV which shows no CRT/DFP for nvidia-xconfig and requires the setting to be set to DFP.

I've opened a question on nvnews.net, hopefully a nvidia developer can tell us more about it http://www.nvnews.net/vbulletin/showthread.php?p=2516472

[ArchangeGabriel]

Nice, I know for sure that at there is at least one dev at nvidia that follow the Linux community carefully and even read us sometimes (that's why so many bugs we've found were corrected).

[Lekensteyn]

My machine shows output for nvidia-xconfig and it seems that the ConnectedMonitor setting is not needed for mine. (commenting it out still allows for starting X, xorg.8.log).
Could you check it for your machine? (please add the output of the nvidia-xconfig command from post 1 as well)

[ArchangeGabriel]

I'm not able to verify it right now, but I know for sure that it does work without the option, does work with DFP because it does detect the CRT and connect to it, and I've found in an old post on the other issue tracker that my output of your command is :

$ /usr/lib/nvidia-current/bin/nvidia-xconfig --query-gpu-info --nvidia-cfg-path=/usr/lib/nvidia-current
Number of GPUs: 1

GPU #0:
  Name      : GeForce G 310M
  PCI BusID : PCI:1:0:0

  Number of Display Devices: 1

  Display Device 0 (CRT-0):
     No EDID information available.

[Lekensteyn]

Thulinmas output is basically the same, it just misses the last two lines and has a 0 for Number of Displayed Devices.

I'm dumping random javascript for the _DOD call on Thulimnas laptop:

var o="\n";[0x80010100, 0x80010400, 0x80010300, 0x80010301, 0x80010302, 0x80010303, 0x80010304, 0x80010008].forEach(function(e){return o+=(
e.toString(2).split("").reverse().join("").replace(/(.{4})(.{4})/g, "$1 $2   ").split("").reverse().join("")
)+"\n"});o;

Yields:

   1000 0000   0000 0001   0000 0001   0000 0000
   1000 0000   0000 0001   0000 0100   0000 0000
   1000 0000   0000 0001   0000 0011   0000 0000
   1000 0000   0000 0001   0000 0011   0000 0001
   1000 0000   0000 0001   0000 0011   0000 0010
   1000 0000   0000 0001   0000 0011   0000 0011
   1000 0000   0000 0001   0000 0011   0000 0100
   1000 0000   0000 0001   0000 0000   0000 1000

[ghost]

For me on an Asus N53SV with ArchLinux:

uname -a output:

Linux asus 3.1.6-1-ARCH #1 SMP PREEMPT Thu Dec 22 09:11:48 CET 2011 x86_64 Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz GenuineIntel GNU/Linux

nvidia-xconfig output:

nvidia-xconfig --query-gpu-info --nvidia-cfg-path=/usr/lib/nvidia-bumblebee/
Number of GPUs: 1

GPU #0:
  Name      : GeForce GT 540M
  PCI BusID : PCI:1:0:0

  Number of Display Devices: 1

  Display Device 0 (CRT-0):
     No EDID information available.

And /etc/bumblebee/xorg.conf.nvidia

[victor@asus ~]$ sudo cat /etc/bumblebee/xorg.conf.nvidia 
Section "ServerLayout"
    Identifier "Layout0"
    Option "AutoAddDevices" "false"
EndSection

Section "Device"
    Identifier "Device1"
    Driver "nvidia"
    VendorName "NVIDIA Corporation"
    Option "NoLogo" "true"
    Option "UseEDID" "false"
#    Option "ConnectedMonitor" "DFP"
EndSection

Bumblebee works fine with and without comment Option "ConnectedMonitor" "DFP"

[Samsagax]

this is a way old issue. Should this be part of the software itself? or a packager issue?

We didn't saw any possible way arround this yet, but maybe we shouldn't put this as a blocker for v3.0. Can I remove the milestone of this issue?

[Lekensteyn]

It's certainly not a packager issue. I'll move it to 3.1 as it does not affect everyone and a debugging it is easy as well.

[Thulinma]

Especially since f57f68d - this issue is pretty moot. Even idiots will know what setting to change to what in what file, since optirun now outputs a message like:

"[ERROR]Cannot access secondary GPU - error: You need to change the ConnectedMonitor setting in /etc/bumblebee/xorg.conf.nvidia to DFP-0"

Maybe even close this issue? Or do we still want to talk about automatically setting/detecting this value somehow?

[Lekensteyn]

Let's keep it open in case there are better options available (read: automatically detect the right values). If 3.1 is about to released, this can be closed if no good solution shows up.

[Samsagax]

The thing is, at least in my case. The nvidia blob doesn't recognize the connected monitor on the card via nvidia-xconfig. Never tested after that.

[Thulinma]

Same here, Samsagax. But the method I use to detect the correct setting that is now returned by optirun, seems to work in all cases - at least all cases so far...

[ArchangeGabriel]

@Thulinma Are we setting it to CRT or DFP by default ? DFP is a better option IMO.

By the way, I would keep it open, if we find a solution, that would still be a great thing. But make it a very low priority, and don't assign it to a milestone.

[Thulinma]

@ArchangeGabriel The default is DFP. I set mine to CRT (which is wrong) so I could produce the error message you saw.

[ArchangeGabriel]

Since we catch the message, can we even set the correct parameter ourselves ?

[Lekensteyn]

Let's leave that option for Bumblebee UI, the daemon should not modify it.

[Thulinma]

Yeah, we can easily change this setting automatically, but I agree with @Lekensteyn that modifying config files automatically is a big no-no.

Idea: have optirun popup a message asking if the user wants bumblebeed to change the setting for them? A simple Yes/No dialog should suffice. This would be part of 3.1 or higher, since we obviously need the better protocol finished to support something like this...

[Lekensteyn]

Idea if we want to make it automated:

If:

• the current xorg conf is the same as config and
• the ConnectedMonitor setting is invalid
• copy the xorg conf to a temporary location (using tmpfile or sth?) and modify it

[Thulinma]

Why copy to a temp location? It would be trivial to undo the changes in this case, and there is no chance of it being a wrong setting here...

Or:
write a NEW xorg conf, to "$(oldname).alt". As in:
/etc/bumblebee/xorg.conf.nvidia -> /etc/bumblebee/xorg.conf.nvidia.alt
It will then write the changes only to this "alternative" config, and attempt to load the server using this file if and only if the normal xorg config file fails.

[Lekensteyn]

If for some reason the setting is wrongly reported, an infinite loop could occur. /etc is supposed to be read-only and should only be used by the administrator.

[ArchangeGabriel]

Just forget this idea, preventing the user is better in fact, that's good for them to learn a little !

But a good auto-detection is better.

[Lekensteyn]

It has to be done only once, so it's probably not that bad.

[Thulinma]

Well, what I suggested would not continue after the .alt version fails. So it would loop at most once before failing, even if detected wrongly.

[summer1988]

I solved the problem just backup the file "xorg.conf.nvidia" and delete it.Then restart the bumblebee and it works very well.
But I don't know why, is anybody know?

[Samsagax]

Maybe related to newer kernel module/driver not being that stupid as before?

[Lekensteyn]

@summer1988 Can you http://pastebin.com/ your /var/log/Xorg.8.log and post the link here?

[summer1988]

@Lekensteyn Here is the link http://pastebin.com/Y9866KEx about my "Xorg.8.log".

[Lekensteyn]

@summer1988 Please pastebin the log using the default xorg.conf.nvidia file.

[summer1988]

http://pastebin.com/WimnheHz I restart my computer using the default xorg.conf.nvidia file.I found the words "Invalid ConnectedMonitor request; request was for '', but the
115.433 NVIDIA(GPU-0): valid display devices are 'CRT-0'." in the log file.
Can it be the problem?

[Lekensteyn]

Edit /etc/bumblebee/xorg.conf.nvidia and change ConnectedMonitor "DFP" to ConnectedMonitor "CRT"

[summer1988]

@Lekensteyn I'll try,Thanks.

[ArchangeGabriel]

Maybe could we get ride of that thanks to #199 ?

[Lekensteyn]

I could not test that option, if it really works as advertised, yes.

[ArchangeGabriel]

I tested it myself, and some people concerned by these problem too, and it appears to work like a charm. So as soon as we can ensure that people are using a driver 304.22 or higher (in fact, I think this mean wait for stable version to hit ubuntu-x-swat), we may be able to make a lot of changes from nvidia-current to nvidia, and also we may change ConnectedMonitor by UseDisplayDevice. We should have to set 304.22 as a minimum dependency for bumblebee-nvidia.

[ArchangeGabriel]

Ok, the work here is replaced by #199 now.