hybrid-graphics-linux team mailing list archive

[Nuno Ferreira <nuno.f.ferreira@xxxxxxxxx>]

Hi,

Well, you convinced me, I switched back to Bumblebee :)

Unfortunately https://github.com/Bumblebee-Project/Bumblebee/issues/184

I'm looking forward to David Airlie's PRIME as it looks to be what will
be finally the definitive solution,hoping you're tracking it.

Thanks in advance for your work.

Nuno


On 01/03/2012 03:26 PM, Lekensteyn wrote:
> History goes like this:
>
> In the beginning, there was nothing. Nvidia Optimus users cried for a
> solution. Then
> came Martin Juhl with a workaround which he named Prime-NG. Since it
> was not
> even remotely close to a real solution like Prime, he renamed it to
> Bumblebee. The
> names Optimus, Prime, Bumblebee and Ironhide all come from the Transformer
> movie if anybody wonders.
>
> The workaround (he called it a "solution", but I prefer to speak of a
> "workaround") was
> announced on this mailing list (hybrid-graphics-linux) and varying
> success had been
> reported. It caught many attention after the famous rm -rf /usr bug
> which has been
> spread on Reddit (https://github.com/MrMEEE/bumblebee/issues/123).
>
> An online database has been added to it, containing user-submitted
> configurations and
> later ACPI calls had been introduced. Occasionally, users contributed
> to the code and
> finally ArchangeGabriel and me (Lekensteyn) decided that a team would
> work better
> than a single user repository as subteams could be created for each
> repository.
>
> We decided to rewrite the old MrMEEE/bumblebee codebase which
> contained some
> design flaws and got rid of the online database. This allowed for
> offline and more
> secure installation. MrMEEE decided not to take part in this project
> and instead
> removed support for distributions other than Ubuntu and continued with
> the name
> Ironide. We continued with the name "Bumblebee", and use TBP/Bumblebee
> (TBP =
> The Bumblebee Project) to distinguish from the original MrMEEE/bumblebee.
> Unfortunately, this caused a lot people to believe that Bumblebee was
> dead and that
> Ironhide is better or even "deprecates" TBP/Bumblebee. Although the
> configuration
> database is quite horrible (it downloads unconfirmed scripts which can
> contain even
> malicous or incomplete code), it sometimes just "works". The Bumblebee
> Project
> team decided not to supply with such a feature by default because
> we're focused
> on stability (see also
> https://github.com/Bumblebee-Project/Bumblebee/wiki/ACPI-Removed)
> A lot issues on https://github.com/MrMEEE/ironhide/issues are a result of
> misconfigured ACPI calls.
>
> While Ironhide is work from one man (Martin) and receives no code
> review from
> other developers, the Bumblebee Project team has several developers with
> varying distributions. The main contributors (in random order) are:
>
> - Samsagax (Arch Linux + nouveau)
> - ArchangeGabriel (Ubuntu + nvidia)
> - Thulinma (new since Bumblebee 3 (unreleased yet), Mandriva + nvidia)
> - Lekensteyn (Ubuntu + nouveau / nvidia)
>
> Support for other distros:
>
> - pvriens (Fedora, but is very busy + nvidia)
> - Ximi (OpenSUSE, but does not communicate with us whatsoever and
> won't even
>   read this rant on him I guess. + nvidia)
>
> We've not been sitting down, better ways to achieve PM has been
> searched for
> and after analyzing a lot ACPI tables, I found out that two kinds of
> calls were
> quite universal which resulted in the bbswitch module.
>
> With help of Thulinma, Bumblebee received a development boost which
> yielded
> a C daemon+client with better communication possiblities, a more
> reliable way
> to detect the server. acpi_call has been dropped (for now) as it does
> not play
> nicely with suspend. bbswitch and vga_switcheroo has been added.
>
> Hopefully you now get a better overview of TBP/Bumblebee and the
> difference
> with Martins projects.
>
> Regards,
> Lekensteyn
>
> On Tue, Jan 3, 2012 at 3:42 PM, Nuno Ferreira
> <nuno.f.ferreira@xxxxxxxxx <mailto:nuno.f.ferreira@xxxxxxxxx>> wrote:
>
>     On 01/03/2012 01:48 PM, Albert Vilella wrote:
>     > Hi,
>     >
>     > Is bbswitch and bumblebeed ready for testing and reporting back
>     to the list?
>     >
>     > Given bbswitch would put the bumblebee/bbswitch combo basically
>     on par
>     > with ironhide, I would update the
>     > http://launchpad.net/~hybrid-graphics-linux
>     <http://launchpad.net/%7Ehybrid-graphics-linux> info for testers...
>     >
>     > Cheers
>     >
>     > _______________________________________________
>     > Mailing list: https://launchpad.net/~hybrid-graphics-linux
>     <https://launchpad.net/%7Ehybrid-graphics-linux>
>     > Post to     : hybrid-graphics-linux@xxxxxxxxxxxxxxxxxxx
>     <mailto:hybrid-graphics-linux@xxxxxxxxxxxxxxxxxxx>
>     > Unsubscribe : https://launchpad.net/~hybrid-graphics-linux
>     <https://launchpad.net/%7Ehybrid-graphics-linux>
>     > More help   : https://help.launchpad.net/ListHelp
>
>     The question that comes to mind, really, is why do both projects exist
>     at the same time? Such a specific feature-set, so recent and so filled
>     with (HW/ACPI) documentation gaps.
>
>     Isn't this a good example where dispersing resources is really bad?
>
>     On a personal note, I currently use IronHide on Oneiric and previously
>     used Bumblebee on Natty, which one should I be using? LENOVO T520
>     (4243RT8) with Nvidia NVS4200M + i915.
>
>     Thanks in advance,
>     Nuno
>
>


-- 
"To be more successful is not, however, to be either completely successful with a single problem or notably successful with any large number. The success of a paradigm--whether Aristotle's analysis of motion, Ptolemy's computations of planetary position, Lavoisier's application of the balance, or Maxell's mathematization of the electromagnetic field--is at the start largely a promise of success discoverable in selected and still incomplete examples. Normal science consists in the actualization of that promise, an actualization achieved by extending the knowledge of those facts that the paradigm displays as particular revealing, by increasing the extend of the match between those facts and the paradigm's predictions, and by further articulation of the paradigm itself. 
(Thomas Kuhn, "The Structure of Scientific Revolutions", Pg. 23-24.)