Como obter o Evolution para rodar em VNC no Debian / Wheezy (ou posterior)?

Question

Por muitos anos tenho tido o hábito de, quando fora de casa, voltar a usar o VNC-ing (por ssh) na minha "máquina doméstica" e rodar o Evolution (por e-mail, contatos, etc.) em um ambiente tightvncserver.

Isso funcionou bem quando a máquina em casa estava executando o Debian / Squeeze, mas agora ele foi atualizado para o Wheezy, tentando iniciar o Evolution nas saídas da sessão do servidor VNC:

Xlib:  extension "GLX" missing on display ":1".
Failed to connected to any renderer:
XServer appears to lack required GLX support

O tightvncserver não suporta o GLX não é uma surpresa, mas o Evolution está se movendo para um backend do GL (através do uso do kit de ferramentas "clutter"?). (Só para deixar claro: o Evolution funciona absolutamente bem na área de trabalho; a máquina tem drivers nvidia via DKMS.)

Quais são as perspectivas de trabalhar em torno disso? Estou pensando nas linhas de:

• Existe uma opção de linha de comando para o Evolution que corrigirá isso?
• Existe alguma maneira de obter suporte GLX em um servidor VNC? (Alternativas para tightvncserver que suportam isso?)

Note que eu costumo ser VNC-ed em links de alta latência / baixa largura de banda; Eu tentei executar o Evolution remotamente no X11 antes e não é uma boa experiência; O VNC funciona muito melhor.

Soluções amigáveis para o Debian (apt-get -able) preferidas.

    

Answer 1

Eu vejo que no Debian9 ("stretch") algo chamado tigervnc-standalone-server apareceu . Isso parece incluir algum suporte ao OpenGL (note que o desk é uma dependência). Eu não tive problemas em instalá-lo em uma nova instalação do Debian9 e ativá-lo em um desktop VNC-capaz (qualquer cliente VNC) independente (não "screen scraped") rodando o Gnome (sem mexer com arquivos .Xsession necessários) que parece não tem problemas em executar evolução ou glxgears. Nenhum virtualgl necessário ou mesmo instalado na máquina. Muito agradável! (Embora eu suspeite strongmente que esta solução esteja provavelmente usando a renderização SW, enquanto que com o virtualgl eu estava usando a GPU; para aplicativos de desktop 2D em CPUs modernas, isso é ótimo).

Observe que o servidor tigervnc não aceita conexões remotas (não-localhost) por padrão (embora exista uma opção de linha de comando para sobrescrever isso); isso é suposto para (sensatamente) encorajá-lo a usar tunelamento ssh!

    

Answer 2

Eu lutei com o mesmo problema ao tentar fazer com que o qtcreator trabalhasse sobre o vnc e, eventualmente, descobrisse por que ele não estava funcionando e como consertá-lo;

link

Você não precisa do VirtualGL e pode até ser pior do que as alternativas. Importante, você pode fazê-lo funcionar apenas usando pacotes Debian padrão.

O VirtualGL é para aceleração de hardware do lado do aplicativo-servidor. GLX é para aceleração de hardware do lado do servidor x. Ao usar o VNC, normalmente, o servidor de aplicativos e o x-server estão na mesma máquina, junto com o servidor vnc, portanto, não há muita diferença entre o VirtualGL e o GLX.

O problema é que os dois servidores vnc mais comuns tightvncserver e vnc4server são ambos servidores x-proxy com seu próprio x-server interno que não suporta GLX. Você ainda pode fazer aplicativos 3D trabalharem com eles, mas é necessário usar a renderização de software do lado do servidor de aplicativos antigo, o que significa que você precisa do libgl1-mesa-swx11 instalado no seu servidor de aplicativos e isso entra em conflito com a renderização de hardware normalmente instalada versão libgl1-mesa-glx.

Alternativamente, você pode instalar um servidor x normal com hardware de suporte GLX e usar o x11vnc, que é um vncserver que captura um servidor x real.

Seria bom se alguém escrevesse um novo servidor x-proxy com suporte GLX apropriado usando o libvncserver (usado pelo x11vnc). O tightvncserver e o vnc4server estão ficando um pouco crostosos.

    

Answer 3

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 .