Obtendo tela preta quando conectado com x11vnc

Question

Estou tentando executar um servidor x11vnc para que alguém possa se conectar remotamente ao meu computador, mas estou tendo problemas para fazê-lo funcionar. Estou usando o Ubuntu 14.04 e testando o servidor VNC usando o Vinagre para conectar no localhost. Eu recebo um prompt de login e ele aceita a senha, mas eu acabo de receber uma tela preta. Isso não parece ser um problema incomum, mas eu tentei várias soluções que encontrei no Google e nenhuma delas funcionou para mim. O log x11vnc não dá nenhuma indicação de erros, então eu não sei onde começar a descobrir o que está errado.

Meu comando x11vnc:

x11vnc -xkb -noxrecord -noxfixes -noxdamage -display :1 -auth /var/run/lightdm/root/:1 -usepw -forever -o /var/log/x11vnc.log

O log x11vnc:

11/08/2015 15:14:43 Got connection from client 127.0.0.1
11/08/2015 15:14:43   other clients:
11/08/2015 15:14:43 Normal socket connection
11/08/2015 15:14:43 Disabled X server key autorepeat.
11/08/2015 15:14:43   to force back on run: 'xset r on' (3 times)
11/08/2015 15:14:43 incr accepted_client=5 for 127.0.0.1:48227  sock=7
11/08/2015 15:14:43 Client Protocol Version 3.8
11/08/2015 15:14:43 Protocol version sent 3.8, using 3.8
11/08/2015 15:14:43 rfbProcessClientSecurityType: executing handler for type 2
11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFE)
11/08/2015 15:14:46 Enabling NewFBSize protocol extension for client 127.0.0.1
11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x574D5669)
11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFD)
11/08/2015 15:14:46 Enabling full-color cursor updates for client 127.0.0.1
11/08/2015 15:14:46 Enabling X-style cursor updates for client 127.0.0.1
11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFF)
11/08/2015 15:14:46 Using tight encoding for client 127.0.0.1
11/08/2015 15:14:48 client useCopyRect: 127.0.0.1 -1
11/08/2015 15:14:48 client_set_net: 127.0.0.1  0.0001

Meu atual ~ / .vnc / xstartup (eu tentei um monte de variações):

#!/bin/sh

export XKL_XMODMAP_DISABLE=1
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &

gnome-panel &
gnome-settings-daemon &
metacity &
nautilus &
gnome-terminal &

    

Answer 1

Existem algumas contradições em sua postagem. x11vnc não lê ~/.vnc/xstartup e geralmente não se conecta a -display :1 .

Normalmente, você tem um servidor X11 padrão já em execução na tela e está em exibição: 0. Mostra o seu desktop gnome no monitor. Você então executa o x11vnc para copiar o que está nessa exibição real para uma conexão remota.

Talvez você queira usar tightvncserver , que cria um novo framebuffer não visível no qual ele desenha e também copia para um controle remoto. Ele lê ~/.vnc/xstartup .

    

Answer 2

Se o terminal virtual ativo for diferente daquele que o servidor X executa (por exemplo, o que parece ser o seu caso: Você está testando no mesmo computador, mas seu visualizador vnc é executado em uma sessão em outro VT do que o servidor X você deseja se conectar) não funciona. (Acabei de ter problemas semelhantes, não conseguindo mudar mais o VT, mas querendo interagir com a minha sessão X em execução.)

É explicado lá: link . Citação:

  

Q-108: Eu uso Terminais Virtuais Linux (VT's) para implementar 'Troca Rápida de Usuário' entre sessões de usuários (por exemplo, Betty está em Ctrl-Alt-F7, Bobby está em Ctrl-Alt -F8, e Sid está no Ctrl-Alt-F1: eles usam esses pressionamentos de tecla para alternar entre suas sessões.) Como a visão em um visualizador VNC conectando ao x11vnc é completamente preto, não é atualizado, ou os pixels são confundidos a menos que a sessão X x11vnc está anexada está no VT ativo?

     

Isto parece ter a ver com a forma como as aplicações (o servidor X processa neste caso) devem "funcionar bem" se não estiverem no VT activo (por vezes chamado VC para consola virtual). Isto é, não devem ler a partir do teclado ou mouse ou gerenciar a exibição de vídeo, a menos que eles tenham o VT ativo. Dado que parece que a chamada XGetImage () deve recuperar os dados do framebuffer do próprio hardware de vídeo, faria sentido que o polling do x11vnc não funcionasse a menos que a sessão X tivesse controle ativo do VT.

     

Não parece ser uma maneira fácil de contornar isso. Mesmo o xwd (1) não funciona neste caso (tente.) Algo precisaria ser feito em um nível mais baixo, digamos, no servidor XFree86 / Xorg X. Além disso, usar o Shadow Framebuffer (uma cópia do framebuffer de vídeo é mantido na memória principal) não parece corrigir o problema (última verificação em 2007).

     

Se ninguém estiver sentado na estação de trabalho e você quiser apenas alternar remotamente o VT para aquele associado à sua sessão X (então o x11vnc pode pesquisar corretamente), pode-se usar o comando chvt (1), por exemplo. "chvt 7" para VT # 7.

    

Answer 3

Eu contornei isso adicionando minha senha no perfil antes de conectar conectar-se ao responder ao pop-up depois de conectar-se à conexão.

Há também um campo para um nome de usuário que me jogou porque não vi nenhuma referência a um nome de usuário na configuração do host, mas deixei em branco, apenas adicionei a senha e o fiz.

Seja real, seja sóbrio.