Ne parvenez pas à activer HDMI sur un ordinateur portable (qui a optimus / bumblebee)

J'essaie d'utiliser la sortie HDMI sur un PC (HP ZBook) avec Debian (stretch). J'ai configuré Bumblebee, cela fonctionne bien (glxinfo et optirun glxinfo rapportent les informations attendues, et j'ai testé des shaders GLSL compliqués qui fonctionnent aussi comme prévu).

Maintenant, je voudrais pouvoir brancher un vidéoprojecteur sur HDMI. J'ai lu ici [1] que la sortie Intel-Virtual-Output peut être utilisée pour la configurer lorsque le HDMI est connecté sur la carte NVidia (en utilisant une sortie VIRTUELLE qui peut être manipulée par xrandr). Cependant, intel-virtual-output dit:

 no VIRTUAL outputs on ":0"

Quand je le fais xrandr -q, il n'y a pas de sortie VIRTUELLE répertoriée, je n'ai que:

Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 345mm x 194mm
   1920x1080     60.02*+  59.93  
   1680x1050     59.95    59.88  
   1600x1024     60.17  
   ... other video modes ...
   400x300       60.32    56.34  
   320x240       60.05  
DP-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
HDMI-2 disconnected (normal left inverted right x axis y axis)

Ma version installée de xserver-xorg-video-intel est: xserver-xorg-video-intel_2.99.917 + git20160706-1_amd64.deb

Mise à jour (samedi 9 décembre 2016) J'ai mis à jour Debian, et maintenant X se bloque lorsque le deuxième moniteur est actif lorsque je démarre certaines applications (par exemple xemacs). Sam. 17 décembre 2016: Oui, découvert! (mis à jour la réponse).

Mise à jour (mercredi 27 septembre 2017) La méthode fonctionne dans 99% des cas, mais la semaine dernière, j'ai essayé un vidéoprojecteur qui n'accepte que les modes 50 Hz et ne pouvait pas obtenir autre chose que 60 Hz (donc cela n'a pas fonctionné). Quelqu'un sait comment forcer les modes 50 Hz?

Mise à jour (mar 01 oct 2019) Argh! Brisé à nouveau: après la mise à jour de X et du pilote NVidia, optirun se bloque maintenant ( /var/log/Xorg.8.logdit crash dans Xorg, OsLookupColor + 0x139). Mise à jour (07 octobre 2019) Trouvé un correctif temporaire (réponse mise à jour).

[1] https://github.com/Bumblebee-Project/Bumblebee/wiki/Multi-monitor-setup

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).