Getting black screen when connected with x11vnc

Question

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 &

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

The above answer is correct:

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

In fact if you follow also the same topic in another thread they are speaking to the same issue in a different way which gives you hint on how to create a workaround: ubuntu 18.04 connect to login screen over VNC

I created the following workaround:

1. Create the file /etc/systemd/system/x11vnc.service with the following content:

   #Description: Custom Service Unit file
   #File: /etc/systemd/system/x11vnc.service
   
   [Unit]
   Description="x11vnc"
   Requires=display-manager.service
   After=display-manager.service
   
   [Service]
   #ExecStart=/usr/bin/x11vnc -loop -nopw -xkb -repeat -noxrecord -noxfixes -noxdamage -forever -rfbport 5900 -display :0 -auth guess -o /var/log/x11vnc.log
   ExecStart=/opt/x11vnc/x11vnc_switch_user
   ExecStop=/usr/bin/killall x11vnc_switch_user && /usr/bin/killall x11vnc
   Restart=on-failure
   RestartSec=2
   
   [Install]
   WantedBy=multi-user.target

2. Create the file /opt/x11vnc/x11vnc_switch_user with the following content:

#!/bin/bash

#/usr/bin/x11vnc -loop -nopw -xkb -repeat -noxrecord -noxfixes -noxdamage -forever -rfbport 5900 -display :0 -auth guess -o /var/log/x11vnc.log
#ExecStop=/usr/bin/killall x11vnc

while true
do
        echo "Checking Xorg used console..."

        CURRENT_CONSOLE=`fgconsole`
        CURRENT_XORG_PORT=`ps aux | grep Xorg | grep "vt$CURRENT_CONSOLE" | cut -d':' -f 4 | cut -c1-1`
        echo "Xorg port=$CURRENT_XORG_PORT"

        EXIST_VNC_SERVER_ON_SAME_PORT=`ps aux | grep x11vnc | grep "display :$CURRENT_XORG_PORT" | head -n 1 | cut -d':' -f 4 | cut -c1-1`

        if [ -n "$EXIST_VNC_SERVER_ON_SAME_PORT" ]
        then
                echo "VNC already run on port $CURRENT_XORG_PORT"
        else
                echo "VNC does NOT run on port $CURRENT_XORG_PORT, starting x11vnc on port 590$CURRENT_XORG_PORT..."
                /usr/bin/x11vnc -loop -nopw -xkb -repeat -noxrecord -noxfixes -noxdamage -forever -rfbport "590$CURRENT_XORG_PORT" -display :$CURRENT_XORG_PORT -auth guess -o /var/log/x11vnc.$CURRENT_XORG_PORT.log &
        fi

        echo "Waiting 1 second..."
        sleep 1
done

3. Enable the x11vnc service:

systemctl enable x11vnc.service

4. Start the x11vnc service

systemctl start x11vnc.service

The script x11vnc_switch_user simply lookup the currently active VT screen from Xorg and create a new x11vnc to the new port in case it's not yet created.

So if you connect with a VNC client to the host to port 0 and then you switch to another use, you will be able to find the new user into another port (for example 1) on the same host.

Of course it's not the best solution but works.

Please note that I'm using Linux Mint (alias Ubuntu) where Desktop Manager is of course Cinnamon, but more important it uses lightdm as login manager.

If someone else has a better seamless solution, please let me know.

Cheers,

Luca