Bug#673424: bbswitch packaging

[Vincent Cheng <vincentc1208@gmail.com>]

On Tue, Mar 19, 2013 at 3:06 AM, Ralf Jung <post@ralfj.de> wrote:
> Hi,
>
>> I suppose a better way of explaining why watching /proc/acpi/bbswitch
>> isn't reliable is by referencing the differences between how the
>> virtualgl and primus backends work. Virtualgl will always cause the
>> secondary X server to be spawned (everything is rendered on the
>> secondary X server before being displayed on the primary X server),
>> whereas primus will only offload glx calls to bumblebee, thus the
>> secondary X server will only start up when you run some sort of opengl
>> application with primus. That means that "optirun bash" or "optirun
>> xterm" will invariably turn on the secondary X server and the nvidia
>> gpu, whereas "primusrun bash" or "primusrun xterm" (or some other
>> application that doesn't use any glx calls) will not.
> However, if primusrun is invoked via optirun, then the second Xserver is
> spawned immediately - optirun itself does that before launching primusrun.

Ah, I was unaware that optirun would spawn a secondary X server
immediately regardless of whether the virtualgl or the primus backend
is used. That's certainly different from what primusrun alone seems to
do (spawn secondary X server only when needed, i.e. when glx calls are
passed along to the nvidia gpu).

> In this scenario, primusrun has the advantage of keeping the second
> Xserver "alive" even if the program forks away, since primus is injected
> in each sub-process which is launched, while optirun+virtualgl monitor
> only the initially executed process.

Yep, no need for that "optirun bash" workaround anymore. :)

Vincent