Não consegue ativar o HDMI em um laptop (que possui otimus / bumblebee)

Estou tentando usar a saída HDMI em um PC (HP ZBook) com Debian (stretch). Eu configurei o Bumblebee, ele funciona bem (glxinfo e optirun glxinfo relatam as informações esperadas e testei shaders GLSL complicados que também funcionam conforme o esperado).

Agora eu gostaria de poder conectar um projetor de vídeo no HDMI. Eu li aqui [1] que a saída virtual intel pode ser usada para configurá-la quando o HDMI está conectado na placa NVidia (usando uma saída VIRTUAL que pode ser manipulada pelo xrandr). No entanto, o intel-virtual-output diz:

 no VIRTUAL outputs on ":0"

Quando o faço xrandr -q, não há nenhuma saída VIRTUAL listada, tenho apenas:

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)

Minha versão instalada do xserver-xorg-video-intel é: xserver-xorg-video-intel_2.99.917 + git20160706-1_amd64.deb

Atualização (sábado, 09 de dezembro de 2016) Atualizei o Debian e agora o X trava quando o segundo monitor está ativo quando inicio alguns aplicativos (por exemplo, xemacs). Sentou. 17 de dezembro de 2016: Sim, descoberto! (atualizou a resposta).

Atualização (quarta-feira, 27 de setembro de 2017) O método funciona em 99% dos casos, mas na semana passada tentei um beamer que só aceita modos 50Hz e não conseguia nada além de 60Hz (por isso não funcionou). Alguém sabe como forçar modos 50Hz?

Update (Tue 01 de outubro de 2019) Argh! Quebrado novamente: depois de atualizar o X e o driver da NVidia, o optirun agora falha ( /var/log/Xorg.8.logdiz falha no Xorg, OsLookupColor + 0x139). Atualização (07/10/2019) Foi encontrada uma correção temporária (resposta atualizada).

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

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