Oui, découvert!
Pour activer la sortie VIRTUELLE du pilote Intel, vous devez créer un 20-intel.conffichier dans le répertoire de configuration Xorg ( /usr/share/X11/xorg.conf.dsous l'étirement Debian, découvert en lisant /var/log/Xorg.0.log)
Section "Device"
Identifier "intelgpu0"
Driver "intel"
Option "VirtualHeads" "2"
EndSection
Mon /etc/bumblebee/xorg.conf.nvidia est le suivant:
Section "ServerLayout"
Identifier "Layout0"
Option "AutoAddDevices" "true"
Option "AutoAddGPU" "false"
EndSection
Section "Device"
Identifier "DiscreteNvidia"
Driver "nvidia"
VendorName "NVIDIA Corporation"
Option "ProbeAllGpus" "false"
Option "NoLogo" "true"
Option "AllowEmptyInitialConfiguration"
EndSection
Section "Screen"
Identifier "Screen0"
Device "DiscreteNVidia"
EndSection
Quelques explications: il a besoin d'une section "Screen", sinon il essaie d'utiliser le périphérique Intel déclaré dans 20-intel.conf (que nous venons d'ajouter avant, oh mon ...). Il a également besoin de "AllowEmptyInitialConfiguration" pour rester en mesure de démarrer avec optirun lorsqu'aucun moniteur externe n'est connecté.
Avec cette configuration et ce démarrage intel-virtual-output, j'ai pu accéder à mon port HDMI. Yeehaa !!!
Dépannage: si optirunou intel-virtual-outputne fonctionne pas, jetez un œil à /var/log/Xorg.8.log(bumblebee crée un serveur X avec écran: 8 utilisés en interne).
Notes que je lis à plusieurs endroits qui KeepUnusedXServerdoivent être réglés sur trueet PMMethodà noneen /etc/bumblebee/bumblebee.conf, je ne le faisaient pas et il fonctionne très bien. Si je fais cela, cela fonctionne, mais le GPU discret reste allumé même après avoir quitté une application optirun-ed ou tué Intel-virtual-output, ce que je ne voulais pas.
Plus de notes Quelque chose d'autre qui m'a fait me cogner la tête contre le mur a été de désactiver Nouveau et de démarrer le serveur Intel X: cela doit être fait par des drapeaux passés au noyau, spécifiés dans les paramètres GRUB. Dans /etc/defaults/grub, j'ai la ligne suivante:
GRUB_CMDLINE_LINUX_DEFAULT="quiet blacklist.nouveau=1 i915.modeset=1 gfxpayload=640x480 acpi_backlight=vendor acpi_osi=! acpi_osi=\"Windows 2009\""
(méfiez-vous des citations et des citations échappées).
Quelques explications: il évite de charger nouveau (ce qui est incompatible avec le serveur Nvidia X), et indique au pilote Intel de passer en mode graphique dès le démarrage. Si vous ne le faites pas, le serveur Intel X ne peut pas démarrer et il revient à un ancien serveur VESA avec un rendu 3D côté processeur. Les acpi_xxxdrapeaux sont requis sur cette machine spécifique pour surmonter un bogue du BIOS qui le fait planter lors du passage en mode graphique avec le GPU discret désactivé. Notez qu'il est spécifique à cet ordinateur portable particulier (station de travail portable HP ZBook), il peut être inutile ou différent pour d'autres ordinateurs portables.
Mise à jour (6 décembre 2017) Avec la dernière distribution Debian (Buster), "915.modeset = 1 gfxpayload = 640x480" est inutile. Pour supprimer nouveau, je devais également créer un fichier nouveau.conf dans /etc/modprobe.d avec "blacklist nouveau", puis recréer le ramdisk avec "update-initramfs -u". Redémarrez et assurez-vous que "nouveau" n'est plus chargé avec "lsmod | grep nouveau".
Mise à jour (17 décembre 2016) Avec le dernier serveur xorg (1.19), il semble y avoir un problème dans une fonction RandR qui gère Gamma lorsqu'elle est utilisée avec intel-virtual-output. Voici la procédure pour patcher le Xserver et le faire fonctionner:
sudo apt-get build-dep xserver-xorg-core
apt-get source xorg-server
éditez hw / xfree86 / modes / xg86RandR12.c Line 1260, insérez "return" (pour que la fonction xf86RandR12CrtcComputeGamma()ne fasse rien)
dpkg-buildpackage -rfakeroot -us -uc
cd ..
sudo dpkg -i xserver-xorg-core_n.nn.n-n_amd64.deb
(remplacez le n.nn.n-npar la bonne version), redémarrez et Yehaa !! fonctionne à nouveau! (mais c'est une solution rapide et sale)
La mise à jour a déposé un rapport de bogue (était déjà connu et vient d'être corrigé):
https://bugs.freedesktop.org/show_bug.cgi?id=99129
Comment j'ai compris:
installé xserver-xorg-core-dbget fait à gdb /usr/lib/xorg/Xorg <xorg pid>partir d'une autre machine via ssh.
Mise à jour (11 janvier 17) Il semble que le bogue soit maintenant corrigé dans les derniers paquets Debian.
Mise à jour (24 janvier 18) Lorsque vous souhaitez brancher un vidéoprojecteur pour faire une présentation et devez tout configurer juste avant de commencer (intel-virtual-output + xrandr), cela peut être stressant. Voici un petit script qui fait le boulot (avertissement: beaucoup de place pour l'amélioration, concernant le style etc ...):
# beamer.sh: sets Linux display for doing a presentation,
# for bumblebee configured on a laptop that has the HDMI
# plugged on the NVidia board.
#
# Bruno Levy, Wed Jan 24 08:45:45 CET 2018
#
# Usage:
# beamer.sh widthxheight
# (default is 1024x768)
# Note: output1 and output2 are hardcoded below,
# change according to your configuration.
output1=eDP1
output2=VIRTUAL1
# Note: I think that the following command should have done
# the job, but it does not work.
# xrandr --output eDP1 --size 1024x768 --output VIRTUAL1 --size 1024x768 --same-as eDP1
# My guess: --size is not implemented with VIRTUAL devices.
# Thus I try to find a --mode that fits my needs in the list of supported modes.
wxh=$1
if [ -z "$wxh" ]; then
wxh=1024x768
fi
# Test whether intel-virtual-output is running and start it.
ivo_process=`ps axu |grep 'intel-virtual-output' |egrep -v 'grep'`
if [ -z "$ivo_process" ]; then
intel-virtual-output
sleep 3
fi
# Mode names on the primary output are simply wxh (at least on
# my configuration...)
output1_mode=$wxh
echo Using mode for $output1: $output1_mode
# Mode names on the virtual output are like: VIRTUAL1.ID-wxh
# Try to find one in the list that matches what we want.
output2_mode=`xrandr |grep $output2\\\. |grep $wxh |awk '{print $1}'`
# There can be several modes, take the first one.
output2_mode=`echo $output2_mode |awk '{print $1}'`
echo Using mode for $output2: $output2_mode
# Showtime !
xrandr --output $output1 --mode $output1_mode --output $output2 --mode $output2_mode --same-as $output1
mise à jour (10/07/2019)
Un "correctif" pour le nouveau crash: écrivez ce qui suit dans un script (appelez-le bumblebee-startx.shpar exemple):
optirun ls # to load kernel driver
/usr/lib/xorg/Xorg :8 -config /etc/bumblebee/xorg.conf.nvidia \
-configdir /etc/bumblebee/xorg.conf.d -sharevts \
-nolisten -verbose 3 -isolateDevice PCI:01:00:0 \
-modulepath /usr/lib/nvidia/nvidia,/usr/lib/xorg/modules/
(remplacez PCI: nn: nn: n par l'adresse de votre carte NVidia, obtenue avec lspci)
Exécutez ce script à partir d' une fenêtre de terminal en tant que root ( sudo bumblebee-startx.sh), garder l'air libre, puis la borne optirunet le intel-virtual-outputtravail comme prévu (note: parfois je dois courirxrandr en plus de faire détecter l'écran / videoprojecteur). Maintenant, je ne comprends pas pourquoi la même commande a commencé à partir de plantages de bourdons, tant de mystères ici ... (mais au moins cela donne une solution temporaire).
Comment j'ai compris: écrit un script «wrapper» pour démarrer le xserver, l'a déclaré comme XorgBinary dans bumblebee.conf, l'a fait enregistrer la ligne de commande ($ *) dans un fichier, a essayé des trucs impliquant LD_PRELOADing un patch sur le XServer pour corriger le crash dans osLookupColor (ne fonctionnait pas), mais quand j'ai essayé de lancer la même ligne de commande à la main, cela a fonctionné et il a continué à fonctionner sans mon correctif (mais je ne comprends toujours pas pourquoi).
Mise à jour 15/11/2019
Après la mise à jour, j'ai connu beaucoup de scintillement, rendant le système inutilisable. Corrigé en ajoutant le paramètre du noyau i915.enable_psr=0(in /etc/defaults/grub, then sudo update-grub). Si vous le souhaitez maintenant, PSR signifie `` rafraîchissement automatique du panneau '', une fonction d'économie d'énergie des GPU Intel (qui peut provoquer un scintillement de l'écran).