Open bugi opened 11 years ago
Have you restarted bumblebeed after editing bumblebee.conf?
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?
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.
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.
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
?
No, it doesn't even seem to be detected unless "UseDisplayDevice" "none" is commented out on startup of optirun.
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
Indeed, that does work! Marvellous!
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.
@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 :)
@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.
Although it is technically possible to fake history, it should be avoided if possible.
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?
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.