Após um pouco mais de pesquisa, todas as estradas parecem levar a VirtualGL (docs ), embora eu ainda tenha que tentar (instruções de configuração são um pouco ... intimidadoras ). A documentação aponta para alguns .debs , e há um ITP para o Debian .
Como alternativa, parece que pode ser possível construir um servidor tightvncserver com suporte a GLX via Mesa (por exemplo, mencionar aqui ). Isso não seria acelerado por GPU, claro (mas quanta potência de gráficos pode email precisar ???); mais preocupante é que (pelo menos da última vez que tentei), o Debian não permitiria que você tivesse mais de um conjunto de libs OpenGL instalado em uma máquina por vez, e eu não gostaria de desistir da aceleração HW para uso local .
Vou atualizar aqui se tiver algum sucesso de uma forma ou de outra; Eu certamente ainda estou interessado em qualquer outra (possível) solução / ponteiros.
Progresso: Instalar o VirtualGL através do .deb apropriado e seguir as instruções (não tão ruins quanto parecem pela primeira vez; a cobertura de várias plataformas aumenta um pouco) me leva (HW acelerado!) suporte a GLX em um servidor tightvncserver. Essa é a primeira vez que vejo isso!
/opt/VirtualGL/bin/vglrun glxgears
Aevoluçãotambémfuncionaatravésdestemecanismo,resolvendoomeuproblemaprincipal.
Noentanto,existemalgunsproblemassignificativoscomestemétodo.Elesófuncionaquandoalguémestálogadonamáquinahost(enãoquandoo"greeter" gdm3 está sendo exibido, caso em que vglrun obtém um erro "não foi possível abrir a exibição: 0"), e qualquer Uma espécie de transição de exibição (por exemplo, alguém ctrl-alt-Fn-ing para um console virtual) irá matar o aplicativo vglrun com um erro "Não foi possível ler os pixels". Bloqueio de tela parece OK embora. Para os meus propósitos, eu posso viver com isso (há outra pessoa que é a principal usuária da máquina na qual estou usando o VNCing, e eles estão sempre conectados e muito improvável de fazer algo tão técnico quanto um ctrl-alt-Fn de distância da área de trabalho), mas pode não ser ideal para outras pessoas.
Atualização : na verdade, há uma correção que permite o uso do VNC + GLX enquanto o "greeter" do gdm3 está sendo exibido. Simplesmente solte uma linha xhost +LOCAL:
perto do início de /etc/gdm3/Init/Default
. O script vglserver_config
realmente tenta fazer isso (para configurações inseguras), mas ele não sabe nada sobre os arquivos de configuração do gdm3 (ele verifica o gdm e o xdm). Embora note que o que seria melhor (e o que o script de configuração tenta fazer, assumindo que você escolheu as opções mais seguras durante a configuração, com o grupo vglusers) é ter um vglgenkey
em seu lugar, mas isso não acontece parece fazer qualquer coisa (não cria um /etc/opt/VirtualGL/vgl_xauth_key
como deveria).
Atualização: Na verdade, a criação de um /etc/opt/VirtualGL/vgl_xauth_key
para o gdm3 pode ser ativada adicionando o usuário Debian-gdm ao grupo vglusers. Mas isso apenas move o problema em outro lugar com o vglrun agora reclamando sobre ser incapaz de travar algo em / var / run / gdm3 / (que tem permissões root: Debian-gdm). Eu estou fora da minha profundidade neste momento e sem dúvida a linha xhost +LOCAL:
terrivelmente insegura terá que fazer.
Update: Acabei de atualizar essa velha máquina Debian do Wheezy para Jessie e atualizei para o virtualgl 2.5 debs do SourceForge. vglrun evolution
funciona muito bem quando o servidor está configurado com vglrun_config
.
Update: No Debian9 ("Stretch") eu mudei para o tigervncserver (novo no Debian nesta versão, acho que; através do pacote tigervnc-standalone-server) ao invés do virtualgl. Veja a outra outra resposta .