There is a lot confusion about this project (Bumblebee). This article (based largely upon a mailing list post by Lekensteyn), contains a history of the Bumblebee concept and its development. It's meant for those who want to get a better understanding of this project and to clear the confusion over the difference between it and other projects supporting Optimus hardware.
In late 2008, vendor products featuring the first NVIDIA "switchable graphics" implementation started to appear. These were followed a couple of years later, in early 2010, by Nvidia's more refined Optimus technology.
When talking of Optimus, the first thing to do is to actually describe what this is, and perhaps the best source for that is the nVidia description of their own technology:
As the notebook industry continues to grow, consumers are trying to find the best compromise between battery life and performance. With the increasing popularity of HD media, gaming, and GPU powered applications, the number of GPUs included in notebooks continues to increase. While integrated graphics has historically delivered good battery life, it has failed to deliver the graphics and GPU performance end users demand. As a result, a few years ago NVIDIA developed a technology dubbed “switchable graphics” which allowed the end-user to choose which display adaptor would be used. In essence, this technology brought the best of both worlds, as it offered the battery life of an integrated graphics solution and the performance of a discrete GPU. Unfortunately, there were limitations to the technology resulting in the end user having to execute a fairly involved procedure to harness the most from the platform, resulting in only 1% of users ever switching between the two graphics systems. With NVIDIA‟s new Optimus technology, users can now experience the full performance benefits of a discrete GPU with the battery life of an integrated graphics solution. NVIDIA Optimus automatically, instantaneously, and seamlessly optimizes the notebook to offer the best performance or best battery life depending on the application. And it simply works.
... under Windows 7.
Indeed, while many recent notebooks with an Intel i3/i5/i7 processor also come equipped with a discrete nVidia card and use the nVidia Optimus technology to provide improved graphics performance while minimizing the impact on battery life, this software solution is, unfortunately, only available in Windows 7 and later.
In the beginning, people did not realize what kind of hardware they owned and became frustrated when old installation methods did not work any longer. Linux distributions were not prepared for this and issues like broken 3D acceleration and lower resolution began to occur after installation of the nvidia driver. In some cases users would even be left with a black screen.
So, Linux users of nVidia Optimus hardware cried for a solution.
Dave Airlie (Red Hat), nouveau driver and kernel developer, wrote an article on his blog showing his first proof of concept of hybrid graphics working on Linux, calling his project "Prime" (see the FAQ for the etymology of the project's name). Prime is the long term solution for supporting hybrid graphics under Linux. However, due to the complexity of the problem ("to make this as good as Windows we need to seriously re-architect the X server + driver"), it won't be ready for most users for a while; currently estimated to be available sometime in the later part of 2013.
This meant that, in the meantime under Linux, end users of Optimus capable Hardware would be left unsatisfied, or "out in the cold" so to speak.
In May of 2011, Martin Juhl announced on the hybrid graphics mailing list a workaround (he called it a "solution", but we prefer to speak of it as a "workaround") and varying success with it was reported. Juhl would initially name this workaround "Prime-NG" (assumingly short for Prime Next Generation). However, since Juhl's code actually was not even remotely close to a real solution, in contrast to the case with Airlie's "Prime", he renamed this work to "bumblebee". (see the FAQ for the etymology of the project's name).
The bumblebee project proceeded to pursue further development and the user base grew. With this, the number of code contributors increased as well. The project caught much attention after the famous rm -rf /usr bug which has been spread on Reddit. Some new features appeared and an online database was added to bumblebee, containing user-submitted configurations (and at a later stage, ACPI calls).
At first, users occasionally contributed to the code, but eventually at some point, ArchangeGabriel and Lekensteyn became more active in the project's development than Martin (a.k.a. MrMEEE). Similarly, Samsagax, whom had also always been present, increased his involvement.
Given that overall project development was being slowed down by the fact that contributors were working in a code repository for which only the owner (Martin) could approve changes, and also because of disagreements with MrMEEE's actual development practices, several of the developers felt a new approach was needed. Consequently, at the end of July 2011, ArchangeGabriel and Lekensteyn proceeded to setup a new project team (Bumblebee Project). This team is focused on developing a stable and reliable version of Bumblebee with clear separation of a development and stable branch to avoid prior mistakes like removing an important folder.
MrMEEE decided not to take part in this project and, instead, continued developing upon his own under a project name of "Ironhide" (See the FAQ for the etymology of the project's name), which also, initially, brought about the removal of support for distributions other than Ubuntu. We, on the other hand, continued with the name "Bumblebee", and use TBP/Bumblebee (TBP = The Bumblebee Project) to distinguish from the legacy MrMEEE/bumblebee project.
Unfortunately, this schism initially may have lead to the belief that Bumblebee was dead and/or that Ironhide is better or even "deprecates" TBP/Bumblebee. That simply was never the case.
We decided to rewrite the old MrMEEE/bumblebee codebase which contained some design flaws. A lot issues on https://github.com/MrMEEE/ironhide/issues are a result of misconfiguration of ACPI calls. We established a new development architecture, a managed organization and started to rewrite everything from scratch. During this process, we got rid of the online database. Although the old configuration database sometimes just "works", it was quite horrible (it downloads unconfirmed scripts which can contain even malicious or incomplete code). The Bumblebee Project team decided not to enable such a feature by default because we are focused on stability and do not want to give users a bad experience. On the whole, our approach allowed for a more secure, offline installation.
Initially, we've not provided support for power management using ACPI calls because of the risk on breaking a system and created a page explaining why ACPI calls have been removed and what risks were associated with wrong calls.
Possible side-effects of misconfigured ACPI calls are:
Below is a story which may make you understand better why we've removed ACPI call support. It has been copied from a conversation on #bumblebee on Freenode.
Okay, let's assume a building with dirty windows. You'd like to see more sun and therefore asks a worker to hire someone to get that job done. The worker has never learned how to clean a dirty window properly, but guess that a rock might be the right way to do it. He asks a kid to try cleaning the window with a rock. Now, different things may happen:
- the window gets scratched and it even gets more darkly
- the window breaks and nothing blocks the sun anymore
In the first case, it has gotten worse. That's the "Module not found" horror and suspend/ lock up issues. In the second case, you won't guess that something is wrong because you achieved your goal: the sunshine is better. Anyway, the right solution is obviously cleaning the window with a cloth but not before the window is repaired, which is our current task.
The ACPI call methods are rocks. The kid is just a messenger, the
module. That worker is the Bumblebee developer team.
Starting with 2.4, we added back support for Power Management due to popular request and users who were sure that they had proper ACPI calls. At that time we haven't finished reading over 700 pages from the ACPI specification and therefore warned that we won't give any support if users experienced problem with it.
After some more research on ACPI, and thanks to the users submitting their ACPI
tables, we gathered enough knowledge and information, so that Lekensteyn was
able to create a new module superseding
At the same time, Samsagax started to rewrite the project in the C programming language which has more flexible and powerful features. This development (again targeted at security and stability) was taken over by Thulinma who finished it and yielded a new version, Bumblebee 3.0 "Tumbleweed". The end result: better support than has ever existed for Optimus under Linux, with the key parts being automatic power management. The development of this program was done under the name "bumblebeed" which refers to the name of the daemon, hence the codename "Tumbleweed".
As you can see, we've not been sitting down idling, and we're not going to do so now, because we still have a lot of things we want to put in Bumblebee: HDMI output support, VDPAU and alternatives backend, an graphical configuration interface, ...
This story will end one day with a matured release of PRIME in the Linux kernel and/or other technologies like Wayland providing support for Optimus which will make Bumblebee obsolete.
While Ironhide is the work from one man (Martin) and receives no code review from other developers, the Bumblebee Project team has several developers using varying distributions. The main contributors (in random order) are:
Hopefully you now get a better overview of TBP/Bumblebee and the difference with Martins projects.
We would like to thank Martin Juhl for the initial release of bumblebee which gave us at least an idea how to get the NVIDIA card to work.
Last edited by Cyril Duez,