Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
bugi opened this issue Apr 5, 2013 · 13 comments
Open

Comments

@bugi
Copy link

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
Copy link
Member

Have you restarted bumblebeed after editing bumblebee.conf?

@bugi
Copy link
Author

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
Copy link
Member

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
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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
Copy link

srhb commented Feb 21, 2014

Indeed, that does work! Marvellous!

@amonakov
Copy link
Contributor

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
Copy link
Member

@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
Copy link
Member

@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
Copy link
Member

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

ArchangeGabriel referenced this issue Dec 12, 2014
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
Copy link
Member

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
Projects
None yet
Development

No branches or pull requests

5 participants