Sì, scoperto!
Per attivare l'output VIRTUAL del driver Intel, è necessario creare un 20-intel.conffile nella directory di configurazione di Xorg ( /usr/share/X11/xorg.conf.din tratto Debian, scoperto leggendo /var/log/Xorg.0.log)
Section "Device"
Identifier "intelgpu0"
Driver "intel"
Option "VirtualHeads" "2"
EndSection
Il mio /etc/bumblebee/xorg.conf.nvidia è il seguente:
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
Alcune spiegazioni: ha bisogno di una sezione "Schermo", altrimenti tenta di utilizzare il dispositivo Intel dichiarato in 20-intel.conf (che abbiamo appena aggiunto prima, oh mio ...). È inoltre necessario "AllowEmptyInitialConfiguration" per rimanere in grado di iniziare con optirun quando non è collegato alcun monitor esterno.
Con questa configurazione e l'avvio intel-virtual-output, sono stato in grado di accedere alla mia porta HDMI. Yeehaa !!!
Risoluzione dei problemi: se optiruno intel-virtual-outputnon funzionano, dare un'occhiata a /var/log/Xorg.8.log(calabrone crea un server X con display: 8 utilizzato internamente).
Note che ho letto in diversi luoghi che KeepUnusedXServerdevono essere impostati su truee PMMethodad nonea /etc/bumblebee/bumblebee.conf, non ho fatto che e funziona benissimo. Se lo faccio, funziona, ma poi la GPU discreta rimane accesa anche dopo essere uscito da un'applicazione optirun o aver ucciso l'output virtuale-intel, che non volevo.
Altre note Qualcos'altro che mi ha fatto sbattere la testa sul muro stava disattivando Nouveau e avviando il server Intel X: deve essere fatto da flag passati al kernel, specificati nei parametri di GRUB. In /etc/defaults/grub, ho la seguente riga:
GRUB_CMDLINE_LINUX_DEFAULT="quiet blacklist.nouveau=1 i915.modeset=1 gfxpayload=640x480 acpi_backlight=vendor acpi_osi=! acpi_osi=\"Windows 2009\""
(attenzione alle virgolette e alle citazioni di escape).
Alcune spiegazioni: evita il caricamento di nouveau (che è incompatibile con il server Nvidia X) e dice al driver Intel di passare alla modalità grafica proprio all'avvio. Se non lo fai, il server Intel X non può avviarsi e ricade su un vecchio server VESA con rendering 3D sul lato CPU. I acpi_xxxflag sono richiesti su questa macchina specifica per superare un bug del BIOS che lo fa in crash quando si va in modalità grafica con la GPU discreta disattivata. Si noti che è specifico per questo particolare notebook (workstation portatile HP ZBook), potrebbe non essere necessario o differire per altri laptop.
Aggiornamento (6 dic 2017) Con l'ultima distribuzione Debian (Buster), "915.modeset = 1 gfxpayload = 640x480" non è necessario. Per rimuovere nouveau, avevo anche bisogno di creare un file nouveau.conf in /etc/modprobe.d con "blacklist nouveau", quindi ricreare il ramdisk con "update-initramfs -u". Riavvia e assicurati che "nouveau" non sia più caricato con "lsmod | grep nouveau".
Aggiornamento (17 dic 2016) Con l'ultimo xorg-server (1.19), sembra esserci un problema in una funzione RandR che gestisce Gamma quando usato con intel-virtual-output. Ecco la procedura per patchare Xserver e farlo funzionare:
sudo apt-get build-dep xserver-xorg-core
apt-get source xorg-server
modifica hw / xfree86 / modes / xg86RandR12.c Riga 1260, inserisci "return" (in modo che la funzione xf86RandR12CrtcComputeGamma()non faccia nulla)
dpkg-buildpackage -rfakeroot -us -uc
cd ..
sudo dpkg -i xserver-xorg-core_n.nn.n-n_amd64.deb
(sostituisci n.nn.n-ncon la versione corretta), riavvia e Yehaa !! funziona di nuovo! (ma è una soluzione rapida e sporca)
L'aggiornamento ha presentato una segnalazione di bug (era già noto ed è stato appena corretto):
https://bugs.freedesktop.org/show_bug.cgi?id=99129
Come ho capito:
installato xserver-xorg-core-dbge fatto gdb /usr/lib/xorg/Xorg <xorg pid>da un'altra macchina tramite ssh.
Aggiornamento (11 gennaio 17) Sembra che il bug sia stato corretto negli ultimi pacchetti Debian.
Aggiornamento (24 gennaio 18) Quando si desidera collegare un proiettore per fare una presentazione e è necessario configurare tutto subito prima di iniziare (intel-virtual-output + xrandr), può essere stressante. Ecco una piccola sceneggiatura che fa il lavoro (dichiarazione di non responsabilità: molto margine di miglioramento, riguardo allo stile ecc ...):
# 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
aggiornamento (10/07/2019)
Una "correzione" per il nuovo crash: scrivi ciò che segue in uno script (chiamalo bumblebee-startx.shper esempio):
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/
(sostituisci PCI: nn: nn: n con l'indirizzo della tua scheda NVidia, ottenuto con lspci)
Eseguire questo script da una finestra di terminale come root ( sudo bumblebee-startx.sh), tenere il terminale aperto, quindi optirune intel-virtual-outputil lavoro come previsto (nota: a volte ho bisogno di correre xrandroltre a rendere lo schermo / videoproiettore rilevato). Ora non capisco perché lo stesso comando sia partito da crash di calabrone, così tanti misteri qui ... (ma almeno dà una soluzione temporanea).
Come ho capito: ho scritto uno script 'wrapper' per avviare l'xserver, lo ha dichiarato come XorgBinary in bumblebee.conf, l'ho fatto salvare la riga di comando ($ *) in un file, ho provato alcune cose che coinvolgono LD_PRELOADing una patch sull'XServer per risolto il crash in osLookupColor (non funzionava), ma quando ho provato a lanciare manualmente la stessa riga di comando, ha funzionato e ha continuato a funzionare senza la mia patch (ma ancora non capisco perché).
Aggiornamento 15/11/2019
Dopo l'aggiornamento, ho riscontrato un sacco di sfarfallio, rendendo il sistema inutilizzabile. Risolto aggiungendo il parametro del kernel i915.enable_psr=0(in /etc/defaults/grub, quindi sudo update-grub). Se lo desideri ora, PSR significa "aggiornamento automatico del pannello", una funzione di risparmio energetico delle GPU Intel (che può causare sfarfallio dello schermo).