Primus support & Bumblebee 4.0

[ArchangeGabriel]

Some logs from our discussion about this: https://bumblebee.etherpad.mozilla.org/8

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 https://github.com/Bumblebee-Project/bumblebee-ppa/blob/primus-proposed/precise/primus/debian/patches/ubuntu_libgl_path.patch and this https://github.com/amonakov/primus/blob/master/primusrun, 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 ?

[ArchangeGabriel]

See this related issue too: #241

[Lekensteyn]

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

[ArchangeGabriel]

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?

[amonakov]

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

[Lekensteyn]

There is still a difference between optirun and primusrun: primus starts X only when OpenGL is actually needed (i.e. when libGL.so 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)

[ArchangeGabriel]

@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?

[Lekensteyn]

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 libGL.so immediately. When the daemon is not available, Firefox does not start. I guess that answers your question?

[amonakov]

I have just tried primusrun firefox and it looks like Firefox loads libGL.so 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.

[ArchangeGabriel]

Is all this going to be solved with #363?

[Lekensteyn]

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.

[ArchangeGabriel]

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 Do not use primusrun #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.

[RalfJung]

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.

[RalfJung]

Uhm, the other way around of course... primus-lazy does not start X. Something like this:
https://github.com/ralfjung-e/Bumblebee/tree/primus-lazy
Of course, this would need updating the documentation, it's just a draft.