Sí, descubrí!
Para activar la salida VIRTUAL del controlador de Intel, debe crear un 20-intel.confarchivo en el directorio de configuración de Xorg ( /usr/share/X11/xorg.conf.den Debian Stretch, descubierto mediante lectura /var/log/Xorg.0.log)
Section "Device"
Identifier "intelgpu0"
Driver "intel"
Option "VirtualHeads" "2"
EndSection
Mi /etc/bumblebee/xorg.conf.nvidia es el siguiente:
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
Algunas explicaciones: necesita una sección "Pantalla", de lo contrario, intenta usar el dispositivo Intel declarado en 20-intel.conf (que acabamos de agregar antes, oh mi ...). También necesita "AllowEmptyInitialConfiguration" para poder comenzar con optirun cuando no hay un monitor externo conectado.
Con esta configuración e inicio intel-virtual-output, pude acceder a mi puerto HDMI. Yeehaa !!!
Solución de problemas: si funciona optiruno intel-virtual-outputno, eche un vistazo /var/log/Xorg.8.log(bumblebee crea un servidor X con pantalla: 8 utilizados internamente).
Notas he leído en varios lugares que KeepUnusedXServerse debe establecer en truey PMMethodpara noneen /etc/bumblebee/bumblebee.conf, yo no lo hicieron y trabaja muy bien. Si hago eso, funciona, pero la GPU discreta permanece encendida incluso después de salir de una aplicación optiruned o matar la salida de Intel virtual, que no quería.
Más notas Algo más que me hizo golpearme la cabeza contra la pared fue desactivar Nouveau e iniciar el servidor Intel X: debe hacerse mediante indicadores pasados al núcleo, especificados en los parámetros de GRUB. En /etc/defaults/grub, tengo la siguiente línea:
GRUB_CMDLINE_LINUX_DEFAULT="quiet blacklist.nouveau=1 i915.modeset=1 gfxpayload=640x480 acpi_backlight=vendor acpi_osi=! acpi_osi=\"Windows 2009\""
(Cuidado con las citas y las citas escapadas).
Algunas explicaciones: evita cargar nouveau (que es incompatible con el servidor Nvidia X), y le dice al controlador Intel que vaya al modo de gráficos en el momento del arranque. Si no hace eso, entonces el servidor Intel X no puede iniciarse, y vuelve a un servidor VESA antiguo con representación 3D en el lado de la CPU. Los acpi_xxxindicadores se requieren en esta máquina específica para superar un error de BIOS que hace que se bloquee cuando entra en modo de gráficos con la GPU discreta apagada. Tenga en cuenta que es específico para este portátil en particular (estación de trabajo portátil HP ZBook), puede ser innecesario o diferente para otros portátiles.
Actualización (6 de diciembre de 2017) Con la última distribución de Debian (Buster), "915.modeset = 1 gfxpayload = 640x480" es innecesario. Para eliminar nouveau, también necesitaba crear un archivo nouveau.conf en /etc/modprobe.d con "blacklist nouveau", y luego volver a crear el ramdisk con "update-initramfs -u". Reinicie y asegúrese de que "nouveau" ya no esté cargado con "lsmod | grep nouveau".
Actualización (17 de diciembre de 2016) Con el último servidor xorg (1.19), parece haber un problema en una función RandR que administra Gamma cuando se usa con intel-virtual-output. Aquí está el procedimiento para parchar el Xserver y hacer que funcione:
sudo apt-get build-dep xserver-xorg-core
apt-get source xorg-server
edite hw / xfree86 / modes / xg86RandR12.c Line 1260, inserte "return" (para que la función xf86RandR12CrtcComputeGamma()no haga nada)
dpkg-buildpackage -rfakeroot -us -uc
cd ..
sudo dpkg -i xserver-xorg-core_n.nn.n-n_amd64.deb
(reemplace n.nn.n-ncon la versión correcta), reinicie y Yehaa !! funciona de nuevo! (pero es una solución rápida y sucia)
La actualización presentó un informe de error (ya se conocía y solo se corrigió):
https://bugs.freedesktop.org/show_bug.cgi?id=99129
Cómo lo descubrí: lo
instalé xserver-xorg-core-dbgy lo hice gdb /usr/lib/xorg/Xorg <xorg pid>desde otra máquina a través de ssh.
Actualización (11 de enero 17) Parece que el error ahora está corregido en los últimos paquetes de Debian.
Actualización (24 de enero de 18) Cuando desea conectar un proyector para hacer una presentación y necesita configurar todo justo antes de comenzar (intel-virtual-output + xrandr), puede ser estresante. Aquí hay un pequeño script que hace el trabajo (descargo de responsabilidad: mucho margen de mejora, con respecto al estilo, 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
actualización (10/07/2019)
Una "solución" para el nuevo bloqueo: escriba lo que sigue en un script (llámelo, bumblebee-startx.shpor ejemplo):
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/
(reemplace PCI: nn: nn: n con la dirección de su tarjeta NVidia, obtenida con lspci)
Ejecutar esta secuencia de comandos desde una ventana de terminal como root ( sudo bumblebee-startx.sh), mantenga el terminal, luego abierta optiruny intel-virtual-outputel trabajo como se esperaba (nota: a veces tengo que correr xrandr, además de hacer que la pantalla / proyector de vídeo detectada). Ahora no entiendo por qué el mismo comando comenzó desde accidentes de abejorros, tantos misterios aquí ... (pero al menos da una solución temporal).
Cómo lo descubrí: escribí un script 'envoltorio' para iniciar el servidor x, lo declaró como XorgBinary en bumblebee.conf, lo hice guardar la línea de comando ($ *) en un archivo, probé algunas cosas que involucran LD_PRELOAD un parche en el XServer para solucionó el bloqueo en osLookupColor (no funcionó), pero cuando intenté iniciar la misma línea de comando a mano, funcionó y continuó funcionando sin mi parche (pero todavía no entiendo por qué).
Actualización 15/11/2019
Después de la actualización, experimenté muchos parpadeos, haciendo que el sistema fuera inutilizable. Se solucionó agregando el parámetro del kernel i915.enable_psr=0(en /etc/defaults/grub, entonces sudo update-grub). Si lo desea ahora, PSR significa 'actualización automática del panel', una función de ahorro de energía de las GPU de Intel (que puede causar parpadeo de la pantalla).