Ttgjyuk

I'm trying to run an x11vnc server so that someone can connect remotely to my computer, but I'm having trouble getting it to work. I'm using Ubuntu 14.04 and testing the VNC server by using Vinagre to connect on localhost. I get a login prompt and it accepts the password, but then I just get a black screen. This doesn't seem to be an uncommon problem but I've tried tons of solutions I've found through Google and none of them have worked for me. The x11vnc log doesn't give any indication of errors so I don't know where to begin to figure out what is wrong.

My x11vnc command:

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

The x11vnc log:

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

My current ~/.vnc/xstartup (I've tried a bunch of variations):

#!/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 &

There are some contradictions in your post. x11vnc does not read ~/.vnc/xstartup and does not usually connect to -display :1.

Usually, you have a standard X11 server already running on your screen, and it is on display :0. It shows your gnome desktop on the monitor. You then run x11vnc to copy what is on this real display to a remote connection.

Perhaps you mean to use tightvncserver which creates a new non-visible framebuffer in which it draws, and also copies to a remote. It reads ~/.vnc/xstartup.

If the active virtual terminal is different from that one the X server runs at (e.g. what seems to be your case: You are testing from the same computer, but your vnc viewer runs in a session on another VT than the X server you want to connect to) it does not work. (I just had similar problems, not able to VT-switch anymore but wanting to get to interact with my running X session.)

It is explained there: http://www.karlrunge.com/x11vnc/faq.html#faq-linuxvc. Quote:

Q-108: I use Linux Virtual Terminals (VT's) to implement 'Fast User Switching' between users' sessions (e.g. Betty is on Ctrl-Alt-F7, Bobby is on Ctrl-Alt-F8, and Sid is on Ctrl-Alt-F1: they use those keystrokes to switch between their sessions.) How come the view in a VNC viewer connecting to x11vnc is either completely black, doesn't update, or pixels messed up unless the X session x11vnc is attached to is in the active VT?

This seems to have to do with how applications (the X server processes in this case) must "play nicely" if they are not on the active VT (sometimes called VC for virtual console.) That is, they should not read from the keyboard or mouse or manage the video display unless they have the active VT. Given that it appears the XGetImage() call must ultimately retrieve the framebuffer data from the video hardware itself, it would make sense x11vnc's polling wouldn't work unless the X session had active control of the VT.

There does not seem to be an easy way to work around this. Even xwd(1) doesn't work in this case (try it.) Something would need to be done at a lower level, say in the XFree86/Xorg X server. Also, using the Shadow Framebuffer (a copy of the video framebuffer is kept in main memory) does not appear to fix the problem (last checked 2007.)

If no one is sitting at the workstation and you just want to remotely switch the VT over to the one associated with your X session (so x11vnc can poll it correctly), one can use the chvt(1) command, e.g. "chvt 7" for VT #7.

I got around this by adding my password in the profile before hitting connect vs responding to the popup after hitting connect.

There's also a field there for a user name which threw me because I hadn't seen any reference to a user name on the host setup, but I left that blank, just added the password, and that did it.

Be real, be sober.