Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Change xorg.conf file at optirun time [XorgConfFile ignored in bumblebee.conf] #373

bugi opened this Issue Apr 5, 2013 · 13 comments


None yet
5 participants

bugi commented Apr 5, 2013

The setting of XorgConfFile in bumblebee.conf is ignored.

No matter what I set it to, /var/log/Xorg.8.log says it uses the default /etc/bumblebee/xorg.conf.nvidia file.

bumblebee version 3.1-1~quantalppa on a T530

Use case: I would like to use a different xorg config file when I'm at my desk than when I'm lounging about. At the desk, I'd like to use the triple-screen setup described at https://github.com/Bumblebee-Project/Bumblebee/wiki/Multi-monitor-setup. I plan to do that by giving optirun the --config option when run in the MM setup, but use the default configs for the laptop on its own. The --config option does work.

Workaround: Make the OptimusStart.sh script fiddle with symlinks before calling out to the session manager, then change them back when that returns.


Lekensteyn commented Apr 5, 2013

Have you restarted bumblebeed after editing bumblebee.conf?

bugi commented Apr 5, 2013

Hmm, I didn't think of that. I will "service bumblebeed restart" after each re-symlinking of the conf files, and see what difference that makes.

But that raises the question of how do I tell bumblebeed to use the different bumblebee.conf without the symlinking? The upstart file, /etc/init/bumblebeed.conf, doesn't seem to allow for me to give different options to bumblebeed.

I do see that --xconf is limited to bumblebeed though, not allowed for optirun. How deep does that distinction run?


ArchangeGabriel commented Apr 15, 2013

In fact, it's only at optirun time that the xorg.conf file is used. However, it's Bumblebeed that starts the X server, so that's why we set it in the daemon.

Thus, we could probably make optirun able to specify a different xorg.conf file.

Anyway, restarting daemon after changing bumblebee.conf is mandatory and should work.

srhb commented Feb 14, 2014

Wouldn't it be sufficient to add a command line option to change the xorg-setup used? It would be a really nice feature for those of us with the occasional need for the mini displayport.


amonakov commented Feb 14, 2014

Apart from adding a new option, you'd need also to communicate the user choice from optirun to bumblebeed via the socket and do something if an X server launched with a different config is already running.

I'm curious, can you turn on the monitor connected to mini-dp after starting secondary X with "UseDisplayDevice" "none" initially via optirun -b none nvidia-settings -c :8 or optirun -b none xrandr -d :8 --auto?

srhb commented Feb 14, 2014

No, it doesn't even seem to be detected unless "UseDisplayDevice" "none" is commented out on startup of optirun.


amonakov commented Feb 15, 2014

What if you change Option "UseDisplayDevice" "none" to Option "AllowEmptyInitialConfiguration"? It should work that way.

edited to add: that option first appeared in 331.13 drivers

srhb commented Feb 21, 2014

Indeed, that does work! Marvellous!


amonakov commented Feb 21, 2014

Thanks for testing that, I've edited the xorg.conf.nvidia file to reflect that. It would be nice if somebody could take care of the wiki page.

@ArchangeGabriel, @Lekensteyn: I've made that commit on master rather than develop branch (I've realized the mistake too late); sorry about that.


Lekensteyn commented Feb 21, 2014

@amonakov Well it happened, nothing we can change about that. (We need to merge master in develop later then.)

I am not so up-to-date with the proprietary drivers, it's off almost all the time. If some user of this could update the wiki page with their experience, that would be great :)

@ArchangeGabriel ArchangeGabriel added this to the Bumblebee 4.0 milestone Apr 2, 2014


ArchangeGabriel commented Apr 2, 2014

@Lekensteyn That’s actually not exact, I’ve just reseted master to the state before @amonakov commit and cherry-picked it into master. Indeed, I should have done this a month ago, but I was very busy.


Lekensteyn commented Apr 2, 2014

Although it is technically possible to fake history, it should be avoided if possible.

@ArchangeGabriel ArchangeGabriel referenced this issue Dec 12, 2014

@ArchangeGabriel ArchangeGabriel xorg.conf.nvidia: Added "UseDisplayDevice" "none"
As the presence of both ConnectedMonitor and this one doesn't hurt, either on newer (>=304.22) and older (<304.22) driver, added this line to make Bumblebee working on some Kepler configurations.

This closes GH-199.

ArchangeGabriel commented Jan 2, 2015

Is there any drawback of setting AllowEmptyInititalConfiguration? I mean, most people won’t use it, and it should be correctly documented when we will release 4.0, so it should be OK, but if setting it as the default simplify things for affected people and doesn’t change anything for the others, we might switch.

Unless maybe they are people stuck on nvidia<313 that will get Bumblebee 4.0 update?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment