Getting black screen when connected with x11vnc

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.

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.

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.

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