Bumblebeed -> Bumblebee about bumblebee

[ArchangeGabriel]

Yes, this is the place for a bigger discussion in fact.

• The name : Keeping Bumblebee looks fine for me. However, I'm facing an increasing number of people that read on the net that Bumblebee is deprecated (but that's MrMEEE one) and has been replaced by IronHide. What could we do :
  • Change the name ? Doesn't look to be a good idea as most of our structure is using Bumblebee in its name (GitHub organization, Launchpad, twitter, ...). Obviously all can be changed, but not easily.
  • Make a big communication plan on Bumblebee Project as a replacement of former Bumblebee (MrMEEE one), being very precise, concise, and clear. As MrMEEE looks to have dropped support for IronHide, maybe we can get his help on redirecting users from IronHide and the old Bumblebee to TBP.
• What about GitHub repo ? Are we going to delete the old bumblebee one, merge this one in Bumblebee, keep both ? What about issues, wiki, ... in all cases ?
• What about packaging ? That's depending from system, but maybe a general scheme could be a plus. Are we going to have bumblebee a meta package depending on bumblebeed, bbswitch, virtualgl, ... and a optional package for nvidia ? Something else ?
• What would be our communication about the transition from 2.4 Bumblebee to Bumblebeed ?
• ...

My opinion : to come later, want to read some other questions and ideas before.

[Lekensteyn]

I currently use TBP/Bumblebee to distinguish from the deprecated MrMEEE/bumblebee.

• Repo: good point, I initially thought of renaming Bumblebee to Bumblebee-old (or Bumblebee-2.4) and moving the bumblebeed repo to TBP/Bumblebee, but in that way issues are lost. So, TBP/Bumblebee is to be kept. Let's close the issue tracker here and stick to the one on TBP/Bumblebee.
• Repo (code) options:
  • keep separate repos, but empty TBP/Bumblebee and add a README for redirection?
  • empty TBP/Bumblebee and move all code from TBP/bumblebeed to TBP/Bumblebee?
  • move TBP/Bumblebee's master to master-2.4 and move the TBP/bumblebeed's repo to TBP/Bumblebee master
• Packaging: bumblebee could contain the core files (binaries, bumblebee.conf, xorg.conf.*) which then depends on the driver package. How to handle the default driver depends on the distribution. Nouveau works, but only if you've a very recent nouveau package and kernel, so the default driver decision is up to the packager. Required dependencies: virtualgl, drivers. Optional, but recommended: bbswitch

Communication

Code name "Tumbleweed" as in Bumblebee 3 "Tumbleweed". The 3 is important to mark the new code base. Because "tumbleweed" sounds like "bumblebeed", it was chosen as a code name.

Documentation is important, we first must update our wiki articles and README files. After that, we can spread the new version via:

• [email protected]
• Twitter
• Facebook
• http://hybrid-graphics-linux.tuxfamily.org/index.php?title=Main_Page
• Ask Ubuntu answer (I'll update that)
• Forums and wikis (localized forum, e.g. http://forum.ubuntu-nl.org, http://wiki.ubuntu-nl.org, http://ubuntuforums.org, http://wiki.ubuntu.com)

[ArchangeGabriel]

Effectively, I've forgotten to talk about version number, it indeed looks obvious that it would be 3.0.

• Repo : Renaming Bumblebee to Bumblebee-old (more relevant than Bumblebee 2.4 as it would also contain former version code) and then bumblebeed to Bumblebee looks fine to me. This way, a lot of links in the Web will still be acurate as pointing to the latest version. Moving the code is an alternative, but I'm fearing issues with git history as we had before with moving from MrMEEE bumblebee to TBP one. The purpose of moving code rather than renaming issue is to keep issues and Wiki in the Bumblebee repo, not to have them moved to a Bumblebee-old one. However, I'm thinking that this may be the moment for cleaning a lot the wiki and issues :
  • Wiki pages may be copied into Bumblebeed easily, and maybe corrected, re-written, and re-arranged this way.
  • Issues may be sorted during importation. There are currently different types of issues :
  • New features one : some are done (nouveau support, C bumblebee version, ACPI/Power Management, ...), some are now irrelevant (support for OpenSuSE or Fedora, as there isn't "distro" support anymore, ...), a lot are still to do and maybe re-written during the transfert to synthesize their content to be more concise, ...
  • Bug ones : A lot of bugs will be irrelevant (acpi_call, cardon/cardoff, ...), some are related to how we were handling PM and suspend in the old versions, and all others one are often months old, and deleting all of them inviting users to test the new version and create a new issue there if still facing the problem will help to sort rapidly bugs.
  • Discussion ones : Some are still usefull, some not, but as new features, those usefull should be synthesized before we go further.
  • Others : People just telling it's working on their machine, ...
    I'm will be happy to help a lot in transfering issues if needed, I feel a little useless since we switched to C, a language that I didn't know, and doesn't have the time to learn right now.
• Packaging : Ok, so that would be up for each distro packages maintener. For Ubuntu, I'm proposing to use nvidia+bbswitch as nouveau is particularly old and the patch for vga_switcheroo will probably take a very long time to be on this distro. I won't discuss the details here, maybe we should discuss these in IRC or on bumblebee-ppa.
• Communication : Ok for the means, I will personnaly update Twitter, Ubuntu-Fr (both Wiki and forums), and if you want I may also mail to the hybrid graphics lists. Also, if everyone agree, I will contact MrMEEE and Avillela on updating different pages to redirect everyone to TBP instead of old bumblebee and IronHide. Only one great question : don't you think that Tumbleweed will interfere with the new openSuSE 12 version ?

[Samsagax]

Ok, here is how I see this:
Bumblebee is the name of the project that brings support to Optimus/Hybrid graphics so doesn't matter how it's parts are named (bumblebeed, bbswitch, being the main components). So I would keep "separate" repos for bbswitch and bumblebeed and keep TBP/Bumblebee one as the repo putting those two together for distribution, documentation and public issue tracking.

Packaging should not be a problem as we are using autotools and is fairly easy for anyone to make a package under such conditions, providing the good parameters are passed to configure script.

Communication: I have no relevant ideas on that matter

[ArchangeGabriel]

Ok, that's an POV for Bumblebee repo, so you would copy bumblebeed and bbswitch in it. You didn't not said what you would do of the present code (keeping it behind the new or moving it to another repo), but that doesn't matter as I'm having a concern with the global idea.

Is bumblebee supposed to be installed by end-users from git ? If not, it has no sense to keep bumblebeed apart. Even else, all the bumblebee code is currently only in the bumblebee repo, the main difference between Bumblebee and Bumblebeed repo structure is that the first one is providing an installer structure. So, if we're going to make bumblebeed installable from git repo for end-users, we're going to do so. So that IMO, bumblebeed should be changed to bumblebee (either by moving code or renamin repo, that's an other discussion) and the current content should be changed to bumblebee-old.

Next, bbswitch is IMO to be kept apart as we've done with acpi_call.

[starks]

On 12/31/2011 11:53 AM, Peter wrote:

To avoid confusion, we should stick with "bumblebee" instead of "bumblebeed". We can keep the filenames (bumblebeed.c) intact, but there are possibly still references to the bumblebeed program which should be renamed to bumblebee. Thoughts?

---

Reply to this email directly or view it on GitHub:
https://github.com/Bumblebee-Project/bumblebeed/issues/15

I agree with preserving the bumblebee name for referring to the entire
body of work.

The hybrid graphics community has enough misconceptions and confusion as
it is. Let's not introduce more.

[Thulinma]

I agree with Bumblebee -> Bumblebee_old and Bumblebeed -> Bumblebee, while keeping filenames as they are.
It seems to be the least confusing option to me :-)

I personally would say need for specific installer support is no longer necessary - it's simple enough for users that want to poke around with bleeding-edge code, and everybody else should just install pre-build packages for their distro :-)

[Samsagax]

Installation is no longer an issue, so we should not provide per-distro support anymore (at least not directly).

I would keep the present codebase (2.4) as a deprecated (historical) branch inside the Bumblebee repo. Then I would copy both bumblebeed and bbswitch repos inside master branch of Bumblebee repo.

Then we should deprecate/delete all irrelevant branches and start over the branching model with the new codebase.

[ArchangeGabriel]

Samsagax : That's why I'm not for your solution : I would like to keep all branches on Bumblebee-old, which will be confusing unless renaming them all by appending -old, which will then be horrible with 20 branches in the repo.

Also, as the content from bumblebeed is really different from the old content, I think it has no sense to keep them in the same repo. One proof is that you've created bumblebeed as a separate repo instead of a Bumblebee repo branch.

I am outside to the project, but:

• Repo: I'm agree with Samsagax, why not use branch system of git? But according to ArchangeGabriel, what about old-issues. Have you planned to continue to support for bumblebee 2.x? Otherwise you can simply remove issues and update wiki. And you can just tag master branch with 3.0 for example.
• Packaging: I think you mustn't include per-distro code in bumblebee or bbswitch, because it's the role of packagers. So you can remove(or simply deprecated) opensuse-dev and fedora-dev branches for examples.
  I think too, you must create one repo per distro for installation (like bumblebee-ppa and bumblebee-AUR).
  In fact, in this repo you can include per-distro code, like :
  • Detection of ldpat (see this issue on bumblebeed for example)
  • Dkms support when installing bbswitch module
• VirtualGL : Version 2.3 has been released recently, and it fixes somes bugs like full OpenGL 4.2 Core Profil support, so do you think it's always important to provide an virtualgl updated snapshot?
• What about others repos : acpi_call, acpi_ww, bumblebee-ui, etc?

[ArchangeGabriel]

If we're making this discussion publicly, that's because we welcome outside opinion. So, yours is welcome.

About Packaging, I think we're all OK, that should be in one repo per distro.

About VirtualGL, this version is already available in Bumblebee PPA, and will still be for Bumblebee 3.0. We will pursue to test new snapshots in the testing PPA and send them to the stable after some tests. However, providing VirtualGL is a packager task. So, that may depend on the distro you use. What I've said above is the our Ubuntu behavior, but you may expect Arch to follow the same rules.

About acpi_call & acpi_www, these are two deprecated repo, as we won't be using them anymore, so we will just let them fall to the end of the repo list. It's good to keep the code, it doesn't cost anything and maybe usefull somewhere in the future.

About bumblebee-ui, that's a pending project, the current code is crappy, but that's still a basis.

[Lekensteyn]

acpi-www is not worked on anymore, it was meant for keeping a database of ACPI tables but it's not necessary at the moment.

Sam was assigned with the task of moving the repo. To avoid breaking links, we shouldn't rename the repo because bugreport links are posted everywhere.

[Samsagax]

Ok, then here is the plan of action:

• Tag bumblebeed/bbswitch release (3.0 for bumblebeed, 0.2 (?) for bbswitch)
• Rename Bumblebee to Bumblebee-old
• Rename bumblebeed to Bumblebee
• Migrate relevant wiki pages to Bumblebee
• Migrate relevant issues from Bumblebee-old to Bumblebee
• Deprecate (close with notice) Bumblebee-old issues and point to new or new-to-come issues in Bumblebee.
• Release tarballs and packages for both Bumblebee and bbswitch.
• Announce all web-wide about our codebase change.
• Release a well-written FAQ about the project.

[Lekensteyn]

• Bumblebee tag: v3.0?
• bbswitch is already tagged at 0.2 and is a separate repo
• Wiki pages can be copied by checking out from the wiki git repo and then pushing it to the other one. To avoid duplicate / outdated information, the old wiki should be closed.
• Tarballs will be available from the tag
• Possibly release and upgrade notes?

[ArchangeGabriel]

To avoid breaking links, we shouldn't rename the repo because bugreport links are posted everywhere.

That's not a problem IMO, as most of them will be useless, and breaking links will probably make people aware of the change. By the way, this operation is reversible, so in case of huge unexpected problem, there is a wayback.

About wiki migration, we would there have to make sure to properly link issues. That's why I won't make a copy of it, but a triage. I may do it if needed, as for issues. And indeed, we need to close the old wiki, as we did for MrMEEE's one.

I've got a question about the wiki, should I drop the ACPI page ?

And effectively, we need release notes. Upgrade for people coming from IronHide, we should make it seamless for people from TBP/Bumblebee.

And tag 3.0

[Lekensteyn]

The wiki can be accessed through git: https://github.com/Bumblebee-Project/Bumblebee/wiki/_access
I've just (forcibly) pushed the contents of the old wiki to bumblebeed. After migration, please check all pages. As for ACPI, I'd just add a notice on the top that the page is kept for historical reasons. The information on it may still be useful to others.

[ArchangeGabriel]

Not sure it's necessary to keep it. That's just a public tracker of the table I've gathered. Since we're not having an easy way to make them accessible for now, that's not really usefull.

[Samsagax]

I was transferring only the relevant pages, but then @Lekensteyn smashed out my work by overwriting the entire wiki :'(

Could that be reverted and I'll continue to rewrite the wiki according to bbswitch/bumblebeed combination?

[ArchangeGabriel]

Dunno. Can't find an easy way to revert, what you can do is to save your work somewhere else, then delete bumblebeed wiki and restore your work.

[Lekensteyn]

That issue has been solved already using the dashboard of github. When something is deleted, it is not really deleted. If you know the commit ID, you can access it.

[Samsagax]

Done :)

Started Wiki review

[ArchangeGabriel]

I've dropped the two ACPI pages (understand : ACPI on Bumblebee and bumblebeed), as the're not usefull anymore (we're not gathering and analysing tables this way any longer), that I didn't updated them for a while, and as we started requesting more informations, collected datas are not in the good shape.

EDIT: I did just saw Lekensteyn made a change, I will keep only this part.

[ArchangeGabriel]

So, I've updated both, with bumblebee one sending people to Launchpad bug, and bumblebeed one prepared for people having laptop on which bbswitch doesn't work.

By the way, that's not finished at all, just a draft.

[LiamDawe]

Just to chime in on this on how confusing everything is;

I currently use Ironhide as i thought it was the more active and supported one I was wrong.

I am switching back to this project as i see you are full steam towards 3.0!

You guys need to update your Launchpad page or have some sort of actual website, this github is so confusing i bet new users have no idea where to go to actually get the project installed. Proper instructions need to be laid out.

[ArchangeGabriel]

That's preciselly the purpose of this issue. We're preparing a great communication plan, please be sure that we want to get out of the current confusing situation.

[LiamDawe]

I'm glad because it's all a big mess right now. I have used it before but I'm still not sure where to go for the correct and properly maintained packages for Ubuntu. It's the fact that the launchpad page doesn't even include the PPA info - I would add that in ASAP to save people having no idea how github works to get at it.

[Lekensteyn]

Well, it shouldn't be hard to find the PPA for Bumblebee: https://launchpad.net/~bumblebee#ppas
Thanks for your feedback, we appreciate it. I've updated the homepage at https://launchpad.net/~bumblebee. Feedback on the new homepage is welcome.

[starks]

The biggest challenge to ending the confusion is the Ubuntu bloc. Not to disparage such an important Bumblebee user base, but they are by the largest source of said confusion. There is an echo chamber of outdated and dangerous information that keeps getting parroted without correction.

I didn't realize how bad it was until the Ubuntu Precise hybrid graphics planning team wanted to base their solutions around Ironhide and its power management.

We need a massive social media blitz. r/linux and r/ubuntu on Reddit are great places to start. Coordinating with Timo and the rest of the Ubuntu-X team can help ensure that outdated notions don't land in popular distros.

https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-hybrid-graphics

[ArchangeGabriel]

Here is a list of the points we need to speak about in our communication plan (TBP=The Bumblebee Project) :

• History of the project : MrMEEE\bumblebee has been forked into two projects, MrMEEE\IronHide and TBP\Bumblebee. The first one is developed by MrMEEE only (or was, we're waiting for a clear statement from MrMEEE about that), the second by everyone else. Why this situation, what is going to happen now and in the future ? A strong basis is @Lekensteyn history on the hybrid-graphics mailing list, available here : https://lists.launchpad.net/hybrid-graphics-linux/msg02031.html. We need particularly to tell about the paypal account.
• The storyline of our repos : what are acpi-www or bumblebee-ui ? Explain what happened with Bumblebee->Bumblebee-old and bumblebeed->Bumblebee. Particularly, where are old issues, explain why they were all closed (useless one, important ones being migrated to the new issue tracker), where to create new ones, and a word about the Wiki.
• What's new in 3.0 (please add things here, I'm not having an exhaustive changelog at all) :
  • Fully rewritten in C (what does that bring ?)
  • Automatic power management
  • Suspend fixed
  • ...
• Maybe we should list all main features that are in Bumblebee even if older too ?
• How to install Bumblebee 3.0 :
  • Ubuntu : use our PPA (stable normally, testing if you want)
  • ArchLinux : AUR (stable or git)
  • Fedora : anything here ?
  • openSuSE : and here ?
  • other distros ?
  • instructions for a manual installation
• Explain the new power management behavior :
  • enabled by default
  • automatic
  • how to check if it's working
  • and what if it doesn't ? How to report it, what infos to provide ?
• known bugs:
  • CRT/DFP: how to detect this problems (full symptoms, i.e. term output error + Xorg.8.log error), how to solve it (change xorg.conf.nvidia line).
  • glx errors: mostly problems with nvidia replacing mesa glx (Xlib: extension "GLX" missing on display ":0".). How to solve it easily ? If I remember quite well, the solution (for Ubuntu) is something like that :
    sudo apt-get purge nvidia*
sudo apt-get install --reinstall xserver-xorg-video-intel libgl1-mesa-glx libgl1-mesa-dri xserver-xorg-core
sudo dpkg-reconfigure xserver-xorg
sudo update-alternatives --remove gl_conf /usr/lib/nvidia-current/ld.so.conf
  • nvidia issues: driver too old (Optimus laptop involves recent material, so there is a need to have updated driver) -> on Ubuntu mostly, maybe we should strongly recommend to use x-swat PPA in installation instructions. Other problem, mismatch between module and kernel API, the solution is I think to re-install the nvidia driver (on Ubuntu, sudo apt-get install --reinstall nvidia-current) and reboot.
  • any other known error
• Instructions for bugreport : how to do it, where, what infos to provide, what format ? We should replace our current bugreport mail by the new gmail one (so that LP mailing list won't be /dev/null for non-LP users).
• FAQ on some important points :
  • Can I use only my nVidia card (globally no, but few laptops give that option in their BIOS, maybe list them) ?
  • Can I run my whole system using the nVidia card (no one succeeded AFAIK, but some where able to start an X server only on the nVidia using optirun) ?
  • Why do I need to launch applications using optirun in a term ? Isn't there an easier way to do so ?
  • nvidia-settings doesn't work (it tells me I'm not using the card) ? Why ? How to fix it (in fact, just optirun nvidia-setting -c :8) ?
  • Can't use my HDMI output, is it related (most probably, we need to work on this, highly requested feature) ?
  • How to check nVidia card performances ? They seems low... (In fact, VirtualGL is dropping frame over 60 fps to avoid useless computation. We need to provide some option to configure VirtualGL to allow max perfs, a little work on VirtualGL configuration will allow that, a rewrite of it to suit perfectly our need too). How can I benchmark my nVidia card to compare to the Intel one ?
  • How can I help you ?
  • How can I suggest ideas or request features (IMO, best way to do so is to set up a gmail that forward to LP. Will come back on that point later) ?
  • How can I make a donation to you ? (We yet have to discuss together on this point).
  • What is bbswitch ?
  • How to use nouveau instead of nvidia or nvidia instead of nouveau ?
  • What configuration options are available ?
• Documentation for advanced users :
  • How does Bumblebee work ?
  • How does bbswitch work ?
  • How to use vga_switcheroo ? (Tell about what are the problems currently)
  • What about windump ?
• Documentation for developers :
  • How to build packages ? What is needed ?
  • What are the coding standards you're using ?
  • How does the git model work ?
  • How do you choose version number ?
  • What strings need to be changed when releasing a new version (for example, if the version number is hardcoded) ?
  • ACPI
• List of our means of communications :
  • GitHub (repos, issues, Wiki)
  • Mailing lists (hybrid graphics one for everyone, bumblebee one for developers). About that point, I think we should have three gmail adresses forwarding to dev mailing list, one for issues (does already exists), one for ideas/suggestions (and if we accept them, we may then create an issue here to track implementation) and one for general communication/questions, each adding a clear title (i.e. [Issue], [Communication] and [Suggestion]). We may subscribe corresponding LP account to our mailing list, but this way we won't be asked for approval.
  • Twitters : there are two, a news one, @Team_Bumblebee, and a git commit one (will need to change what commits are displayed there), @Bumblebee_Git.
  • Launchpad page : We should update the content to provide usefull informations (but I want to keep the introduction).
  • IRC : #bumblebee for users and #bumblebee-dev for developers, both on Freenode.
• What others means we could involve too :
  • r/linux, r/Ubuntu, r/ArchLinux, ... A communication on reddit is often a massive communication
  • @avillela can use the hybrid graphics blog, update the hybrid-graphics launchpad
  • http://hybrid-graphics-linux.tuxfamily.org/index.php?title=Main_Page
  • Ask Ubuntu answer (Lekensteyn will update that)
  • Forums and wikis (http://ubuntuforums.org, http://wiki.ubuntu.com, nvidia linux forum, but don't know if we can write about bumblebee there), localized forum, e.g. http://forum.ubuntu-nl.org, http://wiki.ubuntu-nl.org, (I will do Ubuntu-fr parts).

If there is anything missing, please add it below, I will update this post.

[starks]

Linux blogs/tabloids like H-Online and Phoronix will be worth contacting.

@ArchangeGabriel : For the bug Xlib: extension "GLX" missing on display ":0", you can see on the changelog of the latest nvidia beta drivers, that it's fixed!

[ArchangeGabriel]

No. The issue fixed is with NV-GLX. Not GLX.

[Thulinma]

Idea @ libGL errors - we can most likely detect this and tell the user what is going on.

Simply run ldd on glxgears, find the line mentioning libGL, follow all symlinks until you reach the real file. Check filename. If it contains any combination of more than 2 digits following each other without a period in between, it's most likely nvidia. The xorg files themselves probably have some recognizable strings in them (like "nvidia") if the binaries are searched and could be detected similarly.

We can't automatically "fix" this issue, but we can detect the problem and tell the user what they need to look at.

EDIT: Also, if I'm not mistaken, the lastest nvidia beta drivers make it so the LD_LIBRARY_PATH of optirun'd binaries is no longer required to be able to run them. Would have to test that, though.

[ArchangeGabriel]

So, everything is quite OK for releasing, last points to do :

• import issues from Bumblebee(-old), I'm currently doing this.
• review changelog and press release (that concerns all of you) done
• prepare package and test them, especially verifying that update from 2.4.1 works seemlessly done

Then, spread the world with our press release, and particularly the following means of communication :

• GitHub (repos, issues, Wiki) done
• Mailing lists (hybrid graphics) done
• Twitter: @Team_Bumblebee done
• Facebook (http://www.facebook.com/pages/Bumblebee-Project/292915584089408, danger89 will take care of this) (added by ~L) done
• hybrid graphics Launchpad page & blog (ask @avillela) done
• bumblebee launchpad page done
• IRC : #bumblebee, make it the topic done
• r/linux, r/Ubuntu, r/ArchLinux, ... A communication on reddit is often a massive communication
• maybe a message at http://hybrid-graphics-linux.tuxfamily.org/index.php?title=Main_Page
• Ask Ubuntu answer on Optimus (Lekensteyn will update that) done
• Forums and wikis (http://ubuntuforums.org, http://wiki.ubuntu.com done, nvidia linux forum, but don't know if we can write about bumblebee there), localized forum, e.g. http://forum.ubuntu-nl.org, http://wiki.ubuntu-nl.org, (I will do Ubuntu-fr parts).
• www.phoronix.com done
• www.geeks3d.com done
• omgubuntu.co.uk - TIp has been sent ~L

[ArchangeGabriel]

For issues, I've made a first triage of relevant issues and marked them with "Review for 3.0" as label.

Please comment on each of them if I should summarize them in a new issue on this tracker, of if I should just forget them.

@ArchangeGabriel : I think you can talk about bumblebee 3.x in www.geeks3d.com (a big blog about 3D cards) and www.phoronix.com too.

[ArchangeGabriel]

Yes, I had forgotten phoronix, but that was in my mind.

Thank you for Geeks3D, I know this blog, in fact I even know someone who knows JeGX. But I did not think of it for our press release, so thank you.

Added both.

[starks]

The official Nvidia message board and Nvnews Linux board should be
targeted as well.

[ArchangeGabriel]

That is something I've asked above, are we authorized to post about Bumblebee there ?

[starks]

Why not? I do it all the time.

Nvnews is ground zero for reminding Nvidia how terrible their stance
towards Optimus on Linux is.

The half-dozen Nvidia staffers who post there do see the messages. All
they are capable of is saying "lol post an official nvidia driver bug
report".

We have to keep hammering them like the Nouveau guys did. Nvidia had
to acknowledge the existence of Nouveau in their drivers, so FLOSS
efforts aren't for naught.

[ArchangeGabriel]

Ok then, I was just fearing that they weren't allowing to speak of project trying to help users facing nvidia lacks.

[starks]

We should use the release as an opportunity for data-gathering on the muxed and muxless AMD PowerXpress 4.0 systems.

Sandybridge+Radeon and Llano+Radeon support is respectively non-existent and broken on Linux.

[ArchangeGabriel]

We're not missing datas in fact, there are already a lot of submissions on LaunchPad.

However, the biggest problem is that we do not have any laptop using such platforms to develop on them. Maybe that can be the purpose of donations : help us collect enough money to buy one.

[Samsagax]

El mié, 18-01-2012 a las 10:44 -0800, Bruno Pagani escribió:

We're not missing datas in fact, there are already a lot of submissions on LaunchPad.

However, the biggest problem is that we do not have any laptop using such platforms to develop on them. Maybe that can be the purpose of donations : help us collect enough money to buy one.

---

Reply to this email directly or view it on GitHub:
https://github.com/Bumblebee-Project/bumblebeed/issues/15#issuecomment-3550960

We just need some users with those cards to join out project. Just in
the same way we gathered together. The only difference between them and
us, is them started later.

[Samsagax]

Unless there is some other task undone, we should close this now.

Congratulations to all, for this beauty :)

[Thulinma]

Well, the switch has been made and press releases have gone out, so I'd say this can be closed now :-)