Detection of Monitor type (either DFP or CRT)

[ArchangeGabriel]

DFP-0 computer don't work with DFP,CRT

And even with any of the below variations :
DFP,CRT
DFP-0,CRT
DFP,CRT-0
DFP-0,CRT-0
CRT,DFP
CRT-0,DFP
CRT,DFP-0
CRT-0,DFP-0

That's something blocking...

Why could we do :

1. Use the determine monitor thing again

2. Tell the user to manually set it in /etc/bumblebee/xorg.conf.nvidia

3. Something else ? We're listening for propositions, this is a critical priority bug

[Lekensteyn]

We could grep the error from the Xorg log and log a message to bumblebee.log if needed.
In that message, we tell the user to run something like sudo bumblebee --configure=monitor and make that set the monitor.
Another option which has been proposed before: before running X, check if the ConnectedMonitor setting is modified. If not, run nvidia-xconfig if available and otherwise hope for the best.

[Samsagax]

We can file it as a known bug, tell the user to change it manually on the configuration file and meanwhile look for a better solution

The determine-monitor never seemed to work reliably so I would discard it as an option. Maybe polling the intel driver for an empty monitor should work.

[ArchangeGabriel]

Agree with Sam.

Else, in case of such error, optirun should get in Xorg.8.conf what is the correct monitor and set xorg.conf accordingly.

I like the sudo bumblebee --configure=monitor thing too, but I think this should be a part of a bumblebee-configuration file.

About nvidia-xconfig, don't do that, you won't get a working xorg.conf. Or maybe we could just run that thing, get the CRT or DFP value generated in and put in in our xorg.conf.

That may then be at install time.

[Lekensteyn]

About nvidia-xconfig, I mean using the output of nvidia-xconfig --query-gpu-info with the right library paths set, not generating the xorg.conf file

[csnv]

How about a blacklist of known laptops with DFP-0?

[Lekensteyn]

A blacklist is not a definitive solution since there will be a good chance that new laptops use DFP-0, making the blacklist outdated.

[csnv]

Is not any way to detect the display and then write it directly to the conf file?

[Lekensteyn]

There is: using nvidia-xconfig --query-gpu-info. But this needs the driver to be loaded of which we can't be sure during installation.

[csnv]

Well, if it's not detected during installation, show a message to re run configuration or something after the installation of the nvidia driver.

[ArchangeGabriel]

@Nadiyama : could you pastebin the output of xrandr --verbose please ?

[csnv]

http://pastebin.com/nerN5apz

[Samsagax]

Mhh... as I see there, maybe we can try a "catch-all" method and add "hdmi" and "vga" to the "ConnectedMonitor" option?
I'm writing nonsense.....

After reading the documentation I realized that there is a space between the two options. Have we tried that? Like:
"CRT, DFP", not "CRT,DFP"

[Lekensteyn]

Those are not valid values for ConnectedMonitor. My output (CRT-0) for xrandr --verbose is http://pastebin.com/RXYrySep

Valid values are CRT, DFP and TV. See also http://http.download.nvidia.com/XFree86/FreeBSD-x86/280.13/README/xconfigoptions.html#ConnectedMonitor

[ArchangeGabriel]

Mine is http://pastebin.com/B4bmvSH6 (CRT-0).

What I figured out is that we were looking for CRT-0 or DFP-0. But this names are specific to nVidia driver.

What we need to determine is whether the laptop screen is connected via VGA or DVI.

[ArchangeGabriel]

Excepted my two scetion HDMI1 and DP1 are having some more infos, there don't seems to have something relevant.

Unless the EDID contain this information...

However, xrandr --verbose will at least be very usefull for the future.

So, we need to find a way to determine whether the monitor is connected via VGA or DVI. If someone has an idea, please tell us !

[csnv]

It works with "DFP-0", "DFP", "DFP-0,DFP" or "DFP,DFP-0". As soon as I add "CRT" to the string, it stops working.

[Samsagax]

Have you tried adding a space after the comma? like DFP, CRT ?

[csnv]

Yes, I tried again due to your comment.

[ArchangeGabriel]

nadiyama, could you try my new fix please ? In order do do that, uninstall bumblebee then reinstall using branch master.

By the way, Samsagax, could you confirm that what I've done will work for Arch ?

[Samsagax]

@ArchangeGabriel: please join #bumblebee-dev channel

The packaging is already made for Arch. There was an issue regarding second X server taking too long to be ready but is workarounded by a configurable waiting time.

[csnv]

@ArchangeGabriel

"Bumblebee wasn't able to determine whether your monitor is CRT or DFP."

[Samsagax]

Current versions of VirtualGL have a failsafe to nvidia drivers not detecting the connected monitor. They fake a CRT if your machine has it. We can just leave "DFP" as the default ConnectedMonitor option provided we all use a VirtualGL version > 2.2.9

[ArchangeGabriel]

nadiyama, if you can, please uninstall bumblebee and install the 2.3.1 version.

Then, could you try for us to edit the xorg.conf.nvidia file and remove the line with ConnectedMonitor and see if optirun works with this change ?

Thank you !

[csnv]

It doesn't work without that line.

[ArchangeGabriel]

Thank you for this information.

So Sam was right, VirtualGL only fakes a CRT monitor, not a DFP one, so, we're already doing the best thing.

Closing... If someone want to detect this and set it, then re-open this issue.

[ArchangeGabriel]

VirtualGL appears to be unable to fake CRT for some people (at least 3 people reported that).

We should investigate on why and find a solution or set it.

[ArchangeGabriel]

Why does that f***ing issue close itself...

[Lekensteyn]

Perhaps because it was references in the git commit message.

[ArchangeGabriel]

Task here : figure out how to determine link type (VGA or DVI) without using nvidia tool.

An idea maybe see how nvidia-xconfig determines it, but I'm afraid it is a closed source binary...

[Lekensteyn]

That nvidia-xconfig uses /dev/nvidiactl for determining that but hell... that is closed source stuff :(

[kgbricola]

I face a similar issue, but here it doesn't work with DFP. It works with CRT.

[ArchangeGabriel]

Yes, we are aware of that problem, that's why this bug is still open.

[ArchangeGabriel]

That's something blocking... VGL appears to fake a CRT in some conditions, but never a DFP, so that was defaulted to DFP, however some users are complaining that it isn't working without changing it to CRT.

Why could we do :

1. Use the determine monitor thing again

2. Tell the user to manually set it in /etc/bumblebee/xorg.conf.nvidia, which is what we do currently.

3. Something else ? We're listening for propositions, this is a critical priority bug

[gnetwork-git]

just an idea... can the nvidia-settings options output be used to write options to xorg.conf.nvidia?
i read the info at http://http.download.nvidia.com/XFree86/FreeBSD-x86/280.13/README/xconfigoptions.html#ConnectedMonitor and linked pages, and it all looks possible to write config for 2 x-screens or 2 monitors. i havent tested, as i dont know the workings of bumblebee and what mods it makes to original xorg files.
LLStarks efforts look good...

[Lekensteyn]

LD_LIBRARY_PATH=/usr/lib/nvidia-current /usr/lib/nvidia-current/bin/nvidia-xconfig --query-gpu-info can be used for retrieving the PCI Bus ID, but it requires the nvidia driver to be loaded. Of course we can just load the driver, but that's not going to work if nouveau is already loaded and used by the active X server. One of the reasons why we're looking for alternatives which do not depend on this behavior.

[gurketsky]

VGL appears to fake a CRT in some conditions, but never a DFP

Why do we use DFP then, if it is never reported? What else does VGL report in those cases?

Also what's the reason to use "CRT, DFP"? I think that only works with twinview, I'm not sure if it should work without that.

I'd like to add a 4) What about trying first with "DFP" if it fails, try it with "CRT", if that fails the user should choose the option and then set the correct config?

Just a couple of points/questions:
What else could be the difference? How does VGL generate the faked device? Maybe a look in the code should help here. Maybe the difference is between devices which are muxless and devices which use multiplexors or are they all muxless? Maybe it has to do with what adapter is "the primary one" (sorted by pci bus id?)? Is there a list which notebooks need DFP and which need CRT to look up that kind of stuff?

[Lekensteyn]

See post 1 of this issue why we use DFP. Actually, I read over the twinview thing on ftp://download.nvidia.com/XFree86/Linux-x86_64/280.13/README/xconfigoptions.html and thought it was trying the connections in order.

The primary display controller is always the intel one right? Because that's the one used by default and only if more power is neede, the nvidia card will be used.

[gurketsky]

Sure so on some machines it is DFP and on other machines it is CRT. Are the specs available from the machine in post 1?

I have no glue if the primary controller has to be the intel one, but I think so. Also on my notebook it is possible to deactivate the intel gpu completely in the bios. I'm not sure if that option has something to do with it. The off course the nvidia is the primary one.

[gurketsky]

Maybe it does, I have no glue, but I think it only works when twinview is enabled ... maybe someone could check that? But do we enable twinview? I doubt that ...

I couldn't check that, here it doesn't work if I specify more than on option and twinview is disabled.

[ArchangeGabriel]

@gnetwork-git: That's what we were doing before, but there are too much problem with this solution.

@gurketsy: About CRT,DFP we were thinking it was trying to connect in that order, and our tests were "corrupted" by the fact we wasn't knowing a CRT monitor was detected anyway.

About Muxless, every Optimus computer is supposed to be muxless, so that there isn't an option in the BIOS. Intel chip is ever the primary one in this situation.

The difference between DFP and CRT was explained above: it's the way your monitor is connected to your graphic card; it's DFP if it is a DVI link, and CRT if it is a VGA one.

So, we already found sames machines (Card, ref, ...) using either CRT or DFP. That's why we need to find a relevant way to determine whether type of link we have.

However, while busy for already a month, I forgot a lot of things, and particularly the fact that I have already given the solution your proposing.

We decided to write a X.org error catcher for bumblebee that will try to fix known issues itself (so here test DFP and CRT if it fails).

[gurketsky]

About Muxless, every Optimus computer is supposed to be muxless, so that there isn't an option in the BIOS. Intel chip is ever the primary one in this situation.

Where do you got that information from?
I have an optimus laptop and the bios option is available. (It disables the intel card completely, I tried that with success, only the nvidia card shows up in that case!) Though I think it is muxless.

[ArchangeGabriel]

muxless=you can't disable the intel card at all.

Are you sure your computer is having the Optimus technology ? What is it's marketing reference ?

Because I'm absolutely sure of what I said, it cames from nVidia tech article on Optimus: Optimus means muxless hybrid graphics.

[gurketsky]

It is an ASUS UL30J Series. It has bios version UL30JT 216, VBIOS 1930.I11UL30JT.006, EC Version 202c200001.

Yes, some stickers are around like "NVIDIA® OPTIMUS™ TECHNOLOGY", so if no one faked them, I think it has optimus.

There is a Bios option called "Boot VGA Controller Selection For" which could be "Windows 7/Vista" or "Other". Other means the intel card is disabled. The manual doesn't show this option, but I could make a picture if you don't believe me.

[ArchangeGabriel]

I know this model, that's the one I was wanting to buy before the U33Jc was anounced.

As far as I remember from article I've read at this time, ULx0Jts from Asus were not really Optimus, because they were a transitional step between what Asus did before and Optimus. For example, I think you may be able to use vga_switcheroo on this model. But it is effectively tagged with Optimus, as nVidia supports it.

[ArchangeGabriel]

Now moved to #21 in the new tracker.