@Romu : Non, Bumblebee t'installe le pilote nvidia à sa sauce. Il le télécharge dans les dépôts, l'installe, puis modifie l'installation (il n'est pas condidéré comme actif). Si justement, à tenter de faire les choses à la main, tu perds forcément l'accélération graphique sur une des cartes (soit intel soit nvidia). Ça vient de l'architecture du serveur X.
Pour simplifier : 1 carte graphique -> 1 driver -> 1 affichage -> 1 xorg.conf. Soit Xorg est configuré pour Intel, soit il est configuré pour la carte nvidia.
Normalement, pas d'affichage = pas de serveur X (ça ne démarre pas, ça n'est pas fait pour).
Le problème d'Optimus c'est que seule la carte Intel est reliée à l'affichage. La carte nvidia ne l'est pas. Le système est conçu pour que les deux cartes partagent leur tampon graphique, leur mémoire (appelé "pbuffer", il me semble). Comme ça la carte Intel reste toujours en charge de l'affichage, puisque c'est la seule effectivement reliée à un affichage (ensemble des sorties vers l'écran).
Sous Linux, en l'état actuel, nos drivers sont incapables de gérer ce partage de mémoire tampon. La carte nvidia, non reliée à un affichage et non configurée reste alors un poids mort qui chauffe et consomme de l'électricité pour rien. Il a fallu trouver une solution alternative.
1er problème : démarrer un serveur X sur la carte nvidia, sachant qu'on est obligé d'avoir un serveur X par carte graphique, et une carte graphique par serveur X, et que normalement, ça ne fonctionne pas s'il n'y a pas d'affichage.
Bumblebee se charge de maintenir deux configurations séparées pour les bibliothèques openGL et le xorg.conf : celle par défaut, pour la carte intel, et celle pour la carte nvidia dans un répertoire spécifique géré par bumblebee, et un petit hack pour lui faire croire qu'elle a un affichage pour démarrer un deuxième serveur X.
En installant des drivers nvidia à la main (des dépôts, ou pire encore, du site de nvidia), tu écrase la config et les bibliothèques utilisables par la carte Intel avec celles de la carte nvidia (incapable de fonctionner toute seule DANS TOUS LES CAS). Donc tu casses l'affichage (biblis et xorg.conf).
2ème problème : afficher des applications accélérées par la carte nvidia dans un environnement accéléré par la carte Intel. C'est là que virtualGL intervient. Il intercepte les instructions openGL destinées à la carte nvidia, effectue le rendu sur cette carte, et renvoie le résultat au serveur X tournant sur la carte Intel. C'est peu efficace (perte de perfs) mais ça fonctionne à peu près dans la plupart des cas.
3 ème problème : la gestion de l'énergie : là on fait appel à bb-switch (anciennement acpi_call). L'idée c'est d'envoyer une commande ACPI à la carte Nvidia pour l'éteindre complètement lorsqu'on ne l'utilise pas : pas de consommation électrique, pas de dégagement de chaleur.
Bumblebee, c'est tout ça, et c'est plutôt complexe (avec en plus une ensemble se sécurités pour vérifier que rien ne tourne sur la carte nvidia avant de l'éteindre, gérer la mise en veille etc).
Tenter de s'en sortir à la main est une perte de temps et le plus sûr chemin pour casser sa config, puisque développer bumblebee a déjà nécessité tout ce boulot juste pour avoir quelque chose qui fonctionne (sans être optimal, la vraie solution serait un driver adapté).
Bref, hors Bumblebee, tout ce qu'on peut trouver sur optimus sur Ubuntu est inutile : les scripts acpi_call sont dépassés, voire dangereux (problèmes de reconnaissance de la carte nvidia), et dans tous les cas, à quoi bon désactiver définitivement la carte nvidia quand bumblebee ne la démarre que sur demande explicite ?