Sim, descobri!
Para ativar a saída VIRTUAL do driver intel, você precisa criar um arquivo 20-intel.conf no diretório de configuração do Xorg ( /usr/share/X11/xorg.conf.d no Debian stretch, encontrado lendo /var/log/Xorg.0.log )
Section "Device"
Identifier "intelgpu0"
Driver "intel"
Option "VirtualHeads" "2"
EndSection
Meu /etc/bumblebee/xorg.conf.nvidia é o seguinte:
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
Algumas explicações: ele precisa de uma seção "Screen", senão ele tenta usar o dispositivo Intel declarado em 20-intel.conf (que acabamos de adicionar antes, oh meu ...). Ele também precisa que "AllowEmptyInitialConfiguration" permaneça capaz de iniciar com optirun quando nenhum monitor externo estiver conectado.
Com essa configuração e iniciando intel-virtual-output , consegui acessar minha porta HDMI. Yeehaa !!!
Solução de problemas: se optirun ou intel-virtual-output não funcionarem, dê uma olhada em /var/log/Xorg.8.log (o bumblebee cria um servidor X com display: 8 usado internamente).
Notas Eu li em vários lugares que KeepUnusedXServer deve ser definido como true e PMMethod para none em /etc/bumblebee/bumblebee.conf , eu não fiz isso e funciona bem. Se eu fizer isso, funcionará, mas a GPU discreta permanecerá ativa mesmo depois de sair de um aplicativo optirun-ed ou de matar o intel-virtual-output, o que eu não queria.
Mais anotações Outra coisa que me fez bater a cabeça na parede foi desativar o Nouveau e iniciar o servidor Intel X: ele precisa ser feito por sinalizadores passados para o kernel, especificados nos parâmetros do GRUB. Em /etc/defaults/grub , tenho a seguinte linha:
GRUB_CMDLINE_LINUX_DEFAULT="quiet blacklist.nouveau=1 i915.modeset=1 gfxpayload=640x480 acpi_backlight=vendor acpi_osi=! acpi_osi=\"Windows 2009\""
(tenha cuidado com as aspas e aspas escapadas).
Algumas explicações: evita carregar o nouveau (que é incompatível com o servidor Nvidia X) e diz ao driver da Intel para ir para o modo gráfico logo no momento da inicialização. Se você não fizer isso, o servidor Intel X não poderá ser iniciado e voltará para um servidor VESA simples com renderização 3D no lado da CPU. Os acpi_xxx sinalizadores são necessários nesta máquina específica para superar um bug da BIOS que faz com que ele falhe ao entrar no modo gráfico com a GPU separada desligada. Observe que é específico para esse notebook específico (estação de trabalho portátil HP ZBook), pode ser desnecessário ou diferente para outros laptops.
Update (Dec 6 2017) Com a mais recente distribuição Debian (Buster), "915.modeset = 1 gfxpayload = 640x480" é desnecessário. Para remover o nouveau, eu precisava também criar um arquivo nouveau.conf em /etc/modprobe.d com "blacklist nouveau", e depois recriar o ramdisk com "update-initramfs -u". Reinicie e certifique-se de que "nouveau" não esteja mais carregado com "lsmod | grep nouveau".
Update (17 / Dez / 2016) Com o servidor xorg mais recente (1.19), parece haver um problema em uma função RandR que gerencia o Gamma quando usado com intel-virtual-output . Aqui está o procedimento para corrigir o Xserver e fazê-lo funcionar:
sudo apt-get build-dep xserver-xorg-core
apt-get source xorg-server
edite o arquivo hw / xfree86 / modes / xg86RandR12.c
Linha 1260, insira "retorno"
(para que a função xf86RandR12CrtcComputeGamma() não faça nada)
dpkg-buildpackage -rfakeroot -us -uc
cd ..
sudo dpkg -i xserver-xorg-core_n.nn.n-n_amd64.deb
(substitua o n.nn.n-n pela versão correta), reinicie e Yehaa !! funciona de novo! (mas é uma solução rápida e suja)
Atualização arquivou um relatório de bug (já era conhecido e foi corrigido): link
Como descobri:
Instalou xserver-xorg-core-dbg e fez gdb /usr/lib/xorg/Xorg <xorg pid> de outra máquina através de ssh.
Update (11 de janeiro de 17) Parece que o bug está corrigido nos últimos pacotes Debian.
Update (Jan 24 18) Quando você quiser conectar um beamer para fazer uma apresentação e precisar configurar tudo logo antes de iniciar (intel-virtual-output + xrandr), pode ser estressante. Aqui está um pequeno script que faz o trabalho (disclaimer: muito espaço para melhorias, em relação ao 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