Skip to content

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

Closed
Lekensteyn opened this Issue Jan 2, 2012 · 36 comments

5 participants

@Lekensteyn
Bumblebee-Project member

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
Bumblebee-Project member

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
Bumblebee-Project member

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
Bumblebee-Project member

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
Bumblebee-Project member

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
Bumblebee-Project member

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
Bumblebee-Project member

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
ghost commented Jan 4, 2012

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
Bumblebee-Project member

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
Bumblebee-Project member

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
Bumblebee-Project member

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
Bumblebee-Project member

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
Bumblebee-Project member

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
Bumblebee-Project member

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
Bumblebee-Project member

@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
Bumblebee-Project member

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

@ArchangeGabriel
Bumblebee-Project member

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

@Lekensteyn
Bumblebee-Project member

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

@Thulinma
Bumblebee-Project member

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
Bumblebee-Project member

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
Bumblebee-Project member

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
Bumblebee-Project member

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
Bumblebee-Project member

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
Bumblebee-Project member

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

@Thulinma
Bumblebee-Project member

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
Bumblebee-Project member

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

@Lekensteyn
Bumblebee-Project member

@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
Bumblebee-Project member

@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
Bumblebee-Project member

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

@summer1988

@Lekensteyn I'll try,Thanks.

@ArchangeGabriel
Bumblebee-Project member

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

@Lekensteyn
Bumblebee-Project member

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

@ArchangeGabriel
Bumblebee-Project member

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
Bumblebee-Project member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.