Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Primus support & Bumblebee 4.0 #319

ArchangeGabriel opened this Issue · 25 comments

5 participants


Some logs from our discussion about this:

Work is on common-primus branch.

I will list the new features soon.

Work remaining:

  • revert my last commit on the three
  • fix issues in primus

Some questions:
1) Based on this 7fb2a82, this and this, how should we package primus ? Sould we hardcode some default path at compile time like it is done right now, plus eventually some thing in the primus script, or move everything to daemon side (I think that even the primusrun script is useless in this situation, since everything is set by the daemon, that can even make the final call, right) ? I personaly prefer the second option.

2) How is currently managed the fact that primus only start X on a GL call ?


See this related issue too: #241


Hmm, isn't this already done with 3.1? Regarding (2), when is loaded, primus is activated and then asks the daemon to start X.


Indeed, most work is done, this is just a question of inversing default and packaging primus. We don't need to install primusrun right, just libs?


At the moment primusrun is needed, but changing optirun to not need it is easy.


There is still a difference between optirun and primusrun: primus starts X only when OpenGL is actually needed (i.e. when is loaded). optirun OTOH starts X and if that fails to run, it will also not start the program.

(optirun doesn't need primusrun indeed)


@Lekensteyn: That were the kind of things I was asking above. So currently, we rely on primus package too, but that could be changed (and IMO, should). However, optirun does not behave like primus in this case. We need to decide wether this is a feature or not.

For some program like firefox, I think it's a good thing for power usage that the server only shows up when running an accelerated content.

However, is this a problem that the program start if the server may not be started when needed because of a configuration problem or something else? Could we make it crash at that time?


I'm fine with staying dependent on primus. The primus package itself is architecture-independent and can depend on both primus-libs-ia32 and primus-libs-amd64 (or whatever it is called).

primus starts X when the libGL is loaded. I have just tried primusrun firefox and it looks like Firefox loads immediately. When the daemon is not available, Firefox does not start. I guess that answers your question?


I have just tried primusrun firefox and it looks like Firefox loads immediately. When the daemon is not available, Firefox does not start.

That's not what I'm seeing. Here, firefox does start (and works!) if the daemon is not available, but the WebGL support is hosed (obviously).

Also, it appears that it loads libGL once at startup in a separate process to probe OpenGL capabilities, so that secondary X is started and then shut down immediately.

I think we can improve the current approach by LD_PRELOAD'ing a library that will poke the daemon immediately at startup, terminate if it's not available, and retrieve configuration values otherwise (but not start the secondary X server yet). Then primus can use that library to get configuration values and start the secondary server.

Such library could also be used in hybrid-screenclone.


Is all this going to be solved with #363?


Heh, I forgot to reply after my machine locked up. lockdep+nvidia does not play well...

When primus is loaded, it exits the program right away when the daemon is unavailable.

connect: No such file or directory
primus: fatal: failure contacting Bumblebee daemon

When the daemon is available, but the display could not be opened (or if the Xserver did not start), it also exits.


Ok, so about this, #363, and primus packaging, this is what could be done:

  • make primusrun retrieve settings from the daemon and only package it once, but still package it for reasons @amonakov mentionned in #363.
  • have optirun being able to work without primusrun

For the last point, we may have two options:

  • we can make it work just like primus does, so only turn the card on when needed and save power.
  • or we can let it as it is now, for people who don't want to have X stopping/starting each time they need it while using a particular software, and provide a third "bridge", primusrun, that use the so-named script.

In the first one, they are still some changes to do before merging #363, in the second case it's just about adding a third bridge and packaging.


IMHO adding this "lazy" start to optirun is independent of the pull request. Current behaviour is to always start the 2nd X when using optirun (with any bridge), and this isn't changed by my patch. Of course, I could add an additional change implementing, for example, a "primus-lazy" bridge which shares the detection function, and performs the X startup before calling run_primus - but that's a new feature independent from no longer depending on primusrun.


Uhm, the other way around of course... primus-lazy does not start X. Something like this:
Of course, this would need updating the documentation, it's just a draft.


Indeed, #363 could be merged, since it does not change anything to loading X server behavior.

For primus-lazy, @amonakov suggested a clean approach to that thing:

I think we can improve the current approach by LD_PRELOAD'ing a library that will poke the daemon immediately at startup, terminate if it's not available, and retrieve configuration values otherwise (but not start the secondary X server yet). Then primus can use that library to get configuration values and start the secondary server.

Else we may just use primusrun while not loading X directly in bumblebee.


As discussed yesterday with @Vincent-C I would like to make a release soon. Outstanding commits:

The following commits can safely be picked:

The following changes the default configuration and needs a special release note:

  • 5acbb38 Make primus the default again on develop.

This one needs an additional udev rule:

These are trivial changes:

  • 327ddfc Suggest "AllowEmptyInitialConfiguration" (#373)
  • 8244297 scripts/systemd: remove scheduling policy (closes GH-445)

Overall, these are not big changes. The most noticable is probably defaulting to primus, followed by modprobe -r. I propose version number 3.3. Any other outstanding issues? Documentation is severely out of date too.


Sorry for having been away so long…

I have at least two other minor changes I never took the time to commit (been very busy, and even changed my computer for a Dell and distro to Arch during that time), the first one is for systemd, issue #464, and the second one is a little more risky: change in xorg.conf file.

I cannot find again the issue where it was proposed (so that I can’t find the exact reasons of this, but remember that it was supposed to fix an issue and is a bit cleaner more generally), but we could consider changing “AutoAddDevice "false"” to the following:

Section "InputClass"
    Identifier  "IgnoreDevices"
    MatchDevicePath "/dev/input/event*|/dev/input/mouse*|/dev/input/js*|/dev/input/mice"
    Option      "Ignore" "true"

This can either be put in both xorg.conf files, or replace the 10-dummy.conf file (which would be better, but need to be widely tested before, since I don’t want to face the same issue we fixed in 3.2.1).

Also, I would propose renaming of xorg.conf.n* to n*.xorg.conf, so that editors and similar things properly detect them as configuration files (which is not the case currently, for example when editing with vim).


And indeed, documentation all over there (Ubuntu/Debian and probably even Arch wiki, GitHub wiki, docs file) must be updated, will try to take a look at that.


We may also look at the need of a screen section in nvidia xorg.conf file, see here: #580 (comment)


Is #604 going to be fixed by the modprobe changes?


The xorg conf snippet would need some testing to avoid some headache, for a quick release I would skip it unless it fixes a real issue.

For the xorg.conf file, the filetype is not conf, but xf86conf. Only files such as xorg.conf and */xorg.conf.d/*.conf are known as such. You could add this to your vimrc:

au BufNewFile,BufRead /etc/bumblebee/xorg.conf.* setf xf86conf

The system config dir should not be loaded if a custom conf dir is given, this is at least the behavior on Arch.

#604 (and possibly others) should indeed be fixed by the modprobe change.


How is modprobe change going to help with #604?

I suggest not rushing the modprobe change into a release if there's confusion and lack of testing and discussion. The other changes look far safer.


Do we know if the suggested xorg.conf snippet in #580 actually fixes the problem reported in that bug? I recall seeing that issue discussed on IRC a few times with some users reporting that it didn't work for them.


I’ve started cleaning and sorting again the issue tracker, hope to finish that today. Before releasing, I would like my above xorg.conf change to be tested (will ask for that on the french forum), since we don’t seem to be in a fast release emergency anymore.

Also, I would like to update documentation, I’m going to use this thread to add note about things to do.

To be added in documentation:

ACPI Warning: \_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140724/nsarguments-95)
ACPI Error: Field [TMPB] at 282624 exceeds Buffer [ROM1] size 262144 (bits) (20140724/dsopcode-236)
ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEG0.PEGP._ROM] (Node ffff88041f07db40), AE_AML_BUFFER_LIMIT (20140724/psparse-536)
@ArchangeGabriel ArchangeGabriel self-assigned this

I’ve been looking at setting "AllowEmptyInitialConfiguration" by default but it makes NVIDIA to detect the CRT/DFP link when one exist again, and I remember that with switched fully to "UseDisplayDevice" "none" because it makes the secondary X server to start a bit faster and configuring display in this case is useless. So we should indeed let this as it is currently and add documentation on online support about this.

I’m still waiting for more returns on the xorg.conf ignore device change, but didn’t get any negative ones as of today.


OK, so except for documentation updates, the only thing I’m not sure about is nvidia-uvm handling. I need to recheck what we planned to do and verify it will work everywhere.

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.