Sim, descobri!
Para ativar a saída VIRTUAL do driver intel, você precisa criar um 20-intel.confarquivo no diretório de configuração do Xorg ( /usr/share/X11/xorg.conf.dem Debian stretch, descoberto pela leitura /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", caso contrário, tenta usar o dispositivo Intel declarado no 20-intel.conf (que acabamos de adicionar antes, oh meu ...). Ele também precisa de "AllowEmptyInitialConfiguration" para poder continuar 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 optirunou intel-virtual-outputnão funciona, dê uma olhada /var/log/Xorg.8.log(o zangão cria um servidor X com a tela: 8 usada internamente).
Notas que li em vários locais que KeepUnusedXServerdevem ser definidos como truee PMMethodpara nonedentro /etc/bumblebee/bumblebee.conf, não fiz isso e funciona bem. Se eu fizer isso, ele funciona, mas a GPU discreta permanece ligada mesmo depois de sair de um aplicativo otimizado ou matar a intel-virtual-output, o que eu não queria.
Mais anotações Outra coisa que me fez bater de 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\""
(cuidado com as aspas e as aspas escapadas).
Algumas explicações: evita carregar nouveau (que é incompatível com o servidor Nvidia X) e diz ao driver da Intel para ir para o modo gráfico no momento da inicialização. Se você não fizer isso, o servidor Intel X não poderá ser iniciado e ele voltará a um servidor VESA antigo simples com renderização 3D do lado da CPU. Os acpi_xxxsinalizadores são necessários nesta máquina específica para superar um bug do BIOS que causa um travamento ao entrar no modo gráfico com a GPU discreta desativada. Observe que, como é específico para esse notebook em particular (estação de trabalho portátil HP ZBook), pode ser desnecessário ou diferir para outros laptops.
Atualização (6 de dezembro de 2017) Com a distribuição mais recente do Debian (Buster), "915.modeset = 1 gfxpayload = 640x480" é desnecessário. Para remover o nouveau, eu também precisei criar um arquivo nouveau.conf em /etc/modprobe.d com "blacklist nouveau" e recriar o ramdisk com "update-initramfs -u". Reinicialize e verifique se "nouveau" não está mais carregado com "lsmod | grep nouveau".
Atualização (17 de dezembro de 2016) Com o xorg-server mais recente (1.19), parece haver um problema em uma função RandR que gerencia 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 hw / xfree86 / modes / xg86RandR12.c Linha 1260, insira "return" (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 pela n.nn.n-nversão correta), reinicie e Yehaa !! funciona de novo! (mas é uma solução rápida e suja)
A atualização apresentou um relatório de erro (já era conhecido e foi corrigido):
https://bugs.freedesktop.org/show_bug.cgi?id=99129
Como eu descobri:
Instalei xserver-xorg-core-dbge fiz gdb /usr/lib/xorg/Xorg <xorg pid>de outra máquina através do ssh.
Atualização (11 de janeiro de 17) Parece que o bug foi corrigido nos pacotes Debian mais recentes.
Atualização (24 de janeiro de 18) Quando você deseja conectar um beamer para fazer uma apresentação e precisa configurar tudo antes de iniciar (intel-virtual-output + xrandr), isso pode ser estressante. Aqui está um pequeno script que faz o trabalho (aviso: 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
atualização (07/07/2019)
Uma "correção" para a nova falha: escreva o que se segue em um script (chame-o, bumblebee-startx.shpor exemplo):
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/
(substitua PCI: nn: nn: n pelo endereço da sua placa NVidia, obtida por lspci)
Executar este script a partir de uma janela de terminal como root ( sudo bumblebee-startx.sh), mantenha o terminal aberto, em seguida, optirune intel-virtual-outputfuncionam como esperado (nota: às vezes eu preciso para executar xrandr, além de fazer a tela / videoprojector detectado). Agora eu não entendo por que o mesmo comando começou com travamentos de zangão, tantos mistérios aqui ... (mas pelo menos dá uma correção temporária).
Como eu descobri: escrevi um script 'wrapper' para iniciar o xserver, o declarou como XorgBinary no bumblebee.conf, salvou a linha de comando ($ *) em um arquivo, tentou algumas coisas envolvendo LD_PRELOADing de um patch no XServer para corrigir a falha no osLookupColor (não funcionou), mas quando tentei iniciar a mesma linha de comando manualmente, funcionou e continuou trabalhando sem o meu patch (mas ainda não entendo o porquê).
Atualização 15/11/2019
Após a atualização, experimentei muitas oscilações, tornando o sistema inutilizável. Corrigido adicionando parâmetro do kernel i915.enable_psr=0(em /etc/defaults/grub, então sudo update-grub). Se você quiser agora, PSR significa 'atualização automática do painel', um recurso de economia de energia das GPUs intel (que podem causar tremulação na tela).