Ubuntu and Remote Gnome Desktop with x11vnc
Status:
May 2021 - Broke it and fixed it (again) on Ubuntu 21.04, so writing up in anticipation of next time this breaks.
August 2022 - Update to include keyboard mapping fix (with left bracket & right bracket) & retested with Ubuntu 22.04 LTS
Who needs a GUI when you have a command line ?
Me !
I read the book, the blogs and the raves and rants and know I should automate all system admin activities with scripts, bits, hacks and band aids and control everything via SSH or HTTP/S. So I should never need to access the Ubuntu Gnome Desktop ever again. But I still do and while I can get by with ssh and scripts for many things sometimes I need the Ubuntu GUI and this is mostly required to be be accessed remotely.
It is surprising that there is no simple standard "out of box" way to achieve this. Rather there a number of alternate technical ways, using either:
- X11 Display Managers
- VNC servers
- X11 or Wayland "Compositors"
- Remote display protocols like Microsofts RDP, VNC and X11.
So like many things Linux you have an abundance of riches, but not simplicity. My needs are simple:
- Be able to access standard Ubuntu Gnome Desktop from MacOS (so need VNC)
- Get the same look and feel as if I was on local Ubuntu Desktop with a bog standard install (ie Gnome Desktop)
With Ubuntu 16.04 Remote Desktop Access was easy to get going "out of the box" but from 17 on it keeps getting broken in some way due to UI sub-systems changes. Here are my tips to help "fix it up again", hence writing this up "backwards" from getting diagnostic info to then setting up remote desktop.
NOTE: If you find you have problems with x11vnc and some keys not working, left bracket - '(' & right bracket - ')' in my can with Apple MacOS built in "Screen Sharing" VNC client, then see details on fixing in bottom section.
Diagnostics Tools
Over last few Ubuntu release I have found the following things have caused x11vnc to break:
- Change from X11 to Wayland Compositor
- Shift of XAUTHORITY file from ~/.Xauthority to /run/user/<UID>/gdm/Xauthority
- Change to the X11 DISPLAY used
- Change in security management of X11 server access
So here are some tools / command I have used to understand what is going on.
Find all the DISPLAY being used and the owner
The X11 display is accessed via a unix socket, which are in directory "/tmp/.X11-unix":
---
--- Use ls of directory to find the active DISPLAYS
---
# ls -la /tmp/.X11-unix/
total 16
drwxrwxrwt 2 root root 4096 May 12 13:37 .
drwxrwxrwt 21 root root 12288 May 12 22:46 ..
srwxrwxrwx 1 WHO WHO 0 May 12 13:37 X1
---
--- Changes 'X' -> ':' to get DISPLAY
---
# ls /tmp/.X11-unix | tr 'X' ':'
:1
---
--- So user 'WHO' is using display ':1'
---Since Ubuntu 17.04 there has been seperate processes and DISPLAYs for the initial login "greeter" and the user "session". This has proved problematic for x11vnc as it means you cannot have single background process that is connected to a single display.
Also the X11 display for "greeter" is not longer available once the login has completed and you are running with the user "session".
Find the gdm and gnome processes
To find the gdm and gnome processes that are running use "sudo ps -efc", where the flags are:
- e - all processes
- c - including the commmand line parameters
- f - do full format listing so you get all information, including process owner
$ sudo ps -efc | grep gnome
[sudo] password for WHO:
gdm 53167 53149 TS 19 13:56 tty1 00:00:00 /usr/libexec/gdm-x-session dbus-run-session -- gnome-session --autostart /usr/share/gdm/greeter/autostart
gdm 53268 53167 TS 19 13:56 tty1 00:00:00 dbus-run-session -- gnome-session --autostart /usr/share/gdm/greeter/autostart
gdm 53270 53268 TS 19 13:56 tty1 00:00:00 /usr/libexec/gnome-session-binary --systemd --autostart /usr/share/gdm/greeter/autostart
gdm 53396 53270 TS 19 13:56 tty1 00:00:06 /usr/bin/gnome-shell
gdm 53468 1 TS 19 13:56 tty1 00:00:00 /usr/bin/gjs /usr/share/gnome-shell/org.gnome.Shell.Notifications
gdm 53470 1 TS 19 13:56 tty1 00:00:00 /usr/libexec/at-spi2-registryd --use-gnome-session
WHO 66624 62578 TS 19 15:02 pts/0 00:00:00 grep --color=auto gnomeNotice that process 53167 does the "greeter" startup.
And for gdm ...
$ sudo ps -efc | grep gdm
root 1891 1 TS 19 11:01 ? 00:00:00 /usr/sbin/gdm3
gdm 1977 1 TS 19 11:01 ? 00:00:00 /lib/systemd/systemd --user
gdm 1981 1977 TS 19 11:01 ? 00:00:00 (sd-pam)
gdm 2043 1977 TS 30 11:01 ? 00:00:00 /usr/bin/pipewire
gdm 2044 1977 TS 30 11:01 ? 00:00:00 /usr/bin/pipewire-media-session
gdm 2048 1977 IDL 0 11:01 ? 00:00:00 /usr/libexec/tracker-miner-fs
gdm 2061 1977 TS 19 11:01 ? 00:00:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
gdm 2074 1977 TS 19 11:01 ? 00:00:00 /usr/libexec/gvfsd
gdm 2092 1977 TS 19 11:01 ? 00:00:00 /usr/libexec/gvfsd-fuse /run/user/126/gvfs -f -o big_writes
gdm 2096 1977 TS 19 11:01 ? 00:00:00 /usr/libexec/gvfs-udisks2-volume-monitor
gdm 2109 1977 TS 19 11:01 ? 00:00:00 /usr/libexec/gvfs-goa-volume-monitor
gdm 2113 1977 TS 19 11:01 ? 00:00:00 /usr/libexec/goa-daemon
gdm 2159 1977 TS 19 11:01 ? 00:00:00 /usr/libexec/goa-identity-service
gdm 2164 1977 TS 19 11:01 ? 00:00:00 /usr/libexec/gvfs-afc-volume-monitor
gdm 2170 1977 TS 19 11:01 ? 00:00:00 /usr/libexec/gvfs-gphoto2-volume-monitor
gdm 2176 1977 TS 19 11:01 ? 00:00:00 /usr/libexec/gvfs-mtp-volume-monitor
gdm 2465 1 TS 19 11:01 ? 00:00:00 ibus-daemon --panel disable --xim
gdm 2468 2465 TS 19 11:01 ? 00:00:00 /usr/libexec/ibus-memconf
gdm 2623 2465 TS 19 11:01 ? 00:00:00 /usr/libexec/ibus-engine-simple
root 3260 1 TS 19 11:01 ? 00:00:04 /usr/bin/x11vnc -auth /run/user/126/gdm/Xauthority -forever -loop -noxdamage -repeat -rfbauth /home/WHO/.vnc/passwd -rfbport 5902 -shared -display :0
WHO 3261 1 TS 19 11:01 ? 00:00:04 /usr/bin/x11vnc -auth /run/user/1XXX/gdm/Xauthority -forever -loop -repeat -rfbauth /home/WHO/.vnc/passwd -no6 -rfbport 5900 -shared -display :1
root 53149 1891 TS 19 13:56 ? 00:00:00 gdm-session-worker [pam/gdm-launch-environment]
gdm 53167 53149 TS 19 13:56 tty1 00:00:00 /usr/libexec/gdm-x-session dbus-run-session -- gnome-session --autostart /usr/share/gdm/greeter/autostart
gdm 53172 53167 TS 19 13:56 tty1 00:00:21 /usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/126/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 3
gdm 53268 53167 TS 19 13:56 tty1 00:00:00 dbus-run-session -- gnome-session --autostart /usr/share/gdm/greeter/autostart
gdm 53269 53268 TS 19 13:56 tty1 00:00:00 dbus-daemon --nofork --print-address 4 --session
gdm 53270 53268 TS 19 13:56 tty1 00:00:00 /usr/libexec/gnome-session-binary --systemd --autostart /usr/share/gdm/greeter/autostart
gdm 53311 1 TS 19 13:56 tty1 00:00:00 /usr/libexec/at-spi-bus-launcher
gdm 53316 53311 TS 19 13:56 tty1 00:00:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
gdm 53396 53270 TS 19 13:56 tty1 00:00:06 /usr/bin/gnome-shell
gdm 53453 53396 TS 19 13:56 tty1 00:00:00 ibus-daemon --panel disable --xim
gdm 53456 1 TS 19 13:56 tty1 00:00:00 /usr/libexec/xdg-permission-store
gdm 53463 1977 TS 30 13:56 ? 00:00:00 /usr/bin/pulseaudio --daemonize=no --log-target=journal
gdm 53468 1 TS 19 13:56 tty1 00:00:00 /usr/bin/gjs /usr/share/gnome-shell/org.gnome.Shell.Notifications
gdm 53470 1 TS 19 13:56 tty1 00:00:00 /usr/libexec/at-spi2-registryd --use-gnome-session
gdm 53485 53270 TS 19 13:56 tty1 00:00:00 /usr/libexec/gsd-sharing
gdm 53487 53270 TS 19 13:56 tty1 00:00:00 /usr/libexec/gsd-wacom
gdm 53488 53270 TS 19 13:56 tty1 00:00:00 /usr/libexec/gsd-color
gdm 53491 53270 TS 19 13:56 tty1 00:00:00 /usr/libexec/gsd-keyboard
gdm 53493 53270 TS 19 13:56 tty1 00:00:00 /usr/libexec/gsd-print-notifications
gdm 53494 53270 TS 19 13:56 tty1 00:00:00 /usr/libexec/gsd-rfkill
gdm 53495 53270 TS 19 13:56 tty1 00:00:00 /usr/libexec/gsd-smartcard
gdm 53496 53270 TS 19 13:56 tty1 00:00:00 /usr/libexec/gsd-datetime
gdm 53499 53270 TS 19 13:56 tty1 00:00:00 /usr/libexec/gsd-media-keys
gdm 53504 53270 TS 19 13:56 tty1 00:00:00 /usr/libexec/gsd-screensaver-proxy
gdm 53505 53270 TS 19 13:56 tty1 00:00:00 /usr/libexec/gsd-sound
gdm 53507 53270 TS 19 13:56 tty1 00:00:00 /usr/libexec/gsd-a11y-settings
gdm 53512 53270 TS 19 13:56 tty1 00:00:00 /usr/libexec/gsd-housekeeping
gdm 53516 53270 TS 19 13:56 tty1 00:00:00 /usr/libexec/gsd-power
gdm 53565 1 TS 19 13:56 tty1 00:00:00 /usr/libexec/gsd-printer
WHO 66998 62578 TS 19 15:04 pts/0 00:00:00 grep --color=auto gdmLooking closely at this you can see processes (53172) which have XAUTHORITY input, this is essential information to get access to the X11 session. So now lets get details on process which use XAUTHORITY information:
$ sudo ps -efc | grep Xauthority
root 3260 1 TS 19 11:01 ? 00:00:04 /usr/bin/x11vnc -auth /run/user/126/gdm/Xauthority -forever -loop -noxdamage -repeat -rfbauth /home/WHO/.vnc/passwd -rfbport 5902 -shared -display :0
WHO 3261 1 TS 19 11:01 ? 00:00:04 /usr/bin/x11vnc -auth /run/user/1XXX/gdm/Xauthority -forever -loop -repeat -rfbauth /home/WHO/.vnc/passwd -no6 -rfbport 5900 -shared -display :1
gdm 53172 53167 TS 19 13:56 tty1 00:00:23 /usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/126/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 3
WHO 68297 62578 TS 19 15:11 pts/0 00:00:00 grep --color=auto XauthorityTwo of these are a result of the x11vnc startup via systemd but the other is not (53172 again) and provides details on the location of XAUTHORITY token: "/run/user/<UID>/gdm/Xauthority"
This information is needed to set up your startup script.
Checking for the XAUTHORITY tokens
Before Ubuntu 17 the XAUTHORITY tokens where written to the user's home directory. This has now changed and the tokens are written to "/run/user/<UID>/gdm/Xauthority".
To see the token and owner do "sudo ls -la":
---
--- Get users who have XAUTHORITY tokens first
---
$ sudo ls -la /run/user
total 0
drwxr-xr-x 4 root root 80 May 13 14:41 .
drwxr-xr-x 42 root root 1260 May 13 16:38 ..
drwx------ 8 WHO WHO 260 May 13 14:41 1XXX
drwx------ 10 gdm gdm 320 May 13 13:57 126
---
--- And token location details
---
$ sudo ls -la /run/user/126/gdm
total 4
drwx--x--x 2 gdm gdm 60 May 13 11:01 .
drwx------ 10 gdm gdm 320 May 13 13:57 ..
-rwx------ 1 gdm gdm 98 May 13 13:56 XauthorityUID 126 == gdm and 1XXX == "The User"
We now have information required to write systemd startup scripts.
Getting Remote Ubuntu Gnome Desktop
My needs for the remote desktop are the following:
- Have the remote desktop the same as local desktop (no difference in look / feel or tools available) (i.e. the standard Gnome Desktop)
- I do not need to be previously logged in the get access to my desktop
- I can access the remote desktop via MacOS built in VNC (Screen Sharing) client
- I can access the remote desktop via SSH based jump host
- Must pre-authenticate before getting to login screen
NOTE: This post is not about the merits of any particuler VNC server, in fact as an end user I have little interest in VNC servers. I just need remote access to my desktop on a machine that I do not have physical access to most of the time.
Each of my needs imposes particular technical requirement and to meet my needs after reviewing the helpful community guidance I decided to go with x11vnc server. This hooks into the X11 display systems and exposes this as VNC desktop on TCP/IP socket.
So first you need to disable the "wayland" compositor and use the standard X11 compositor. There is not currently an Ubuntu package that provides a VNC server for a wayland compositor. There is one being developed called "wayvnc".
First step..
Disable Wayland Compositor
The first thing to do to allow remote desktop with VNC, is disable the "wayland" compositor (introduced in Ubuntu 16, I think). This is because "wayland" does not allow access to display.
To disable wayland edit: "/etc/gdm3/custom.conf"
[daemon]
# Uncoment the line below to force the login screen to use Xorg
#WaylandEnable=false
WaylandEnable=false <==== here< code>This will result in us of good old X11 compositor.
Setup your password
As per needs (5) above, the MacOS "Screen Sharing" (VNC) client requires you to authenticate before it will provide access to the remote computer. It is also generally good practice to protect your x11vnc server from access by anyone:
---
--- Use x11vnc to setup a password file
---
$ x11vnc -storepasswd
Enter VNC password:
Verify password:
Write password to /home/WHO/.vnc/passwd? [y]/n y
Password written to: /home/WHO/.vnc/passwdWith latest Ubuntu 21.04 you will find that each of the login "greeter" and user "session" gdm/X11 instances will now run under different user ids and only the user who owns the X11 DISPLAY can access it.
This means that the x11vnc process for greeter will need to run with different user id as that of the session. This also means that you will need to have passwd files for each of these users as only the owner should be able to read there own password file.
My solution to this was to copy my user generated password file to new "/home/gdm" directory and change owner go gdm:gdm and then point the login vnc process to this password file and the use session to the user's one.
This is decribed in systemd setup ...
Systemd Startup of x11vnc
To meet need (2) means I have to have remote desktop login available via VNC on reboot / startup of host.
This can be achieved by having a systemd startup script.
Since the user, DISPLAY and XATHORITY token are different for the login "greeter" and the user "session", you need either have some smart way of getting single VNC server instance to manage using the alternate DISPLAY, XAUTHORITY files or use the "hack" of having "greeter" x11vnc process on one socket and the user "session" x11vnc process on another socket.
This problem first came up in Ubuntu 18.04, but with 21.04 it has got worse as now you also have to have the x11vnc process running on the same UID as the DISPLAY owner otherwise the x11vnc process will not be able to open the display (due to permissions).
Here is my current set of systemd startup scripts to get around this (now modified to work with Ubuntu 21.04).
There "greeter" script, using the XAUTHORITY & DISPLAY information collected in "diagnotics" section above:
$ cat /lib/systemd/system/x11vnc-login.service
[Unit]
Description=Start x11vnc at startup.
After=multi-user.target
[Service]
Type=simple
User=gdm <<=== Ubuntu 21.04 need process DISPLAY owner id
ExecStart=/usr/bin/x11vnc -auth /run/user/126/gdm/Xauthority -forever -loop -repeat -rfbauth /home/gdm/.vnc/passwd -rfbport 5902 -shared -display :0
[Install]
WantedBy=multi-user.targetAnd the "user" session script, using information collected in the "diagnostics" section above:
$ cat /lib/systemd/system/x11vnc.service
[Unit]
Description=Start x11vnc at startup.
After=multi-user.target
[Service]
Type=simple
User=WHO <<=== Now the session user
ExecStart=ExecStart=/usr/bin/x11vnc -auth /run/user/1XXX/gdm/Xauthority -forever -loop -noxdamage -repeat -rfbauth /home/WHO/.vnc/passwd -rfbport 5900 -shared -xkb -display :1
#
# Or if you have a problem with keys not working you might
# need to add: -skip_keycodes CODE,CODE... flag
# See below for more details
#
[Install]
WantedBy=multi-user.targetAs can be seen to have VNC available for login you need to have socket for login and then socket for session.
The impact of this is that to use VNC remote desktop you:
- Connect to the login socket server (5902 in this example) and do login, after you login the screen will go black.
- Now close that VNC window and
- Connect to the user session VNC server (on socket 5900 in this example) and can login to your remote desktop via VNC.
In my original posting on setting up this workaround people have come up with other alternates. However with the new security of 21.04 these are likely to break as well.
I have not tested the alternates as most rely on additional scripting which I have not had time to review.
The solution I use is rather limited as it does not allow anyone to login, just the "greeter" and the specific user in the systemd script. Ideally someone should come up with a way to allow any user to get access to their remote desktop. If you need other users to have remote acces, then this would require each user to have their one defined socket to connect to.
In my case i have exclusive access to machine, so solution works for my needs. If you have direct SSH access to machine you could possibilty avoid this by using an SSH server to setup a local application proxy that you can then use to start an x11vnc instance directly (interactively) without the need for setting up the systemd services.
In my case the server I need to access is sitting behind a firewall and is only accesible via a "jump host". So here is final step in this setup.
Avoiding VNC Port Conflicts with libvirt/qemu
If the machine you are running x11vnc is also running libvirt/qemu/kvm based virtual machines then you need to make sure you avoid IP port conflicts with the auto-allocated ports that libvirt creates to provide qxl/spice VNC access to the console of the virtual machines. By default it will auto-allocate ports from 5900 (the default VNC port).
If you followed the guideance on setting up the two UI services above then this will put these services on ports 5900 (Ubuntu Desktop) and 5902 (Login screen). This conflicts with virtlib allocations.
To avoid this you need to change the libvirt port allocation range. This is handled through: "/usr/etc/libvirt/qemu.conf":
...
...
...
# Override the port for creating both VNC and SPICE sessions (min).
# This defaults to 5900 and increases for consecutive sessions
# or when ports are occupied, until it hits the maximum.
#
# Minimum must be greater than or equal to 5900 as lower number would
# result into negative vnc display number.
#
# Maximum must be less than 65536, because higher numbers do not make
# sense as a port number.
#
remote_display_port_min = 5904
remote_display_port_max = 5994
# remote_display_port_max = 65535
...
...
...
Accessing Remove Desktop via SSH jump host
Now for the final problem of how to get access to my remote desktop on a machine that is behind a firewall. The answer is either configure port forwarding in firewall or more generically setup a "jump host" that you can SSH into and then use this to act as VNC communications proxy (need (4)).
So the network topology looks likes a bit like this..
In this scenario there is VPN connection through firewall / VPN gateway, which allows access to SSH Jump Host, through which you can tunnel the VNC connection.
Taking away the VPN layer which is mostly transparent, we need to establish SSH tunnel through jump host. This is done via ssh client on MacOS terminal:
- "ssh -L 5904:<VNC-SERVER-HOST>:5900 <WHO>@<JUMP-HOST>" - for main session
- "ssh -L 5906:<VNC-SERVER-HOST>:5902 <WHO>@<JUMP-HOST>" for greeter session
This establishes local sockets on the MacOS VNC client machine, which are connected to SSH tunnel on <JUMP-HOST> which connect to the VNC Server socket on the <VNC-SERVER-HOST>.
ssh can do a lot of sophisticated stuff if you delve into it...
On the Mac you can now connect to the VNC server by selecting the "Go" menu and conecting to VNC server using URL:
- "vnc://localhost:5904" - for user session
- "vnc://localhost:5906" - for greeter
To to connect first invoke the greeter and then once logged in close this window and invoke use session.
Now if you have issues with key presses not working on your vnc client...
Fixing Keyboard Mapping Issues with x11vnc
So you should now be able to get x11vnc up and running. My main motivation for wanting to have Ubuntu UI available remotely was so I can run Eclipse IDE and LSI MegaRaid storage configuration tool.
When running Eclipse I found that I had issues with the Left & Right Bracket keys: '(' & ')'. These are pretty frequently used keys in just about every programming language. I only appear to have problem with regular '(' & ')' keys and the other braces, curly - '{' & '} and square - '[' & ']' all worked fine.
For a while I got around this by simply cutting/pasting the codes into my files, but this was very frustrating and expecially when using vi and doing regular expressions.
So I resolved to dig into the problem.
Firstly to diagnose what was going on I added keyboard debugging into my x11vnxc startup command (from "/lib/systemd/system/x11vnc.service" example above):
ExecStart=/usr/bin/x11vnc -auth /run/user/1XXX/gdm/Xauthority -forever -loop -noxdamage -repeat -rfbauth /home/WHO/.vnc/passwd -rfbport 5900 -shared -xkb -debug_keyboard -o /var/log/x11vnc.log -display :1
Now ssh into your server machine and tail the x11vnc log file. I found I was getting the following error when pressing the left and right bracket keys:
# tail -f /var/log/vncx11.log
...
...
...
07/08/2022 20:59:49 xkb_tweak_keyboard: down keysym=0x28 "parenleft"
*** found more than one keycode: 018 187 "9" "parenleft", picked this one: 187 (last down: 050)
07/08/2022 20:59:49 XTestFakeKeyEvent(dpy, keycode=0xbb "parenleft", down)
07/08/2022 20:59:49 calling XTestFakeKeyEvent(187, 1) 148.5878
07/08/2022 20:59:49 # keyboard(up, 0x28 "parenleft") uip=0 148.6884
07/08/2022 20:59:49 xkb_tweak_keyboard: up keysym=0x28 "parenleft"
UP: found via klast, i=0
*** found more than one keycode: 018 187 "9" "parenleft", picked this one: 187 (last down: 187)
07/08/2022 20:59:49 XTestFakeKeyEvent(dpy, keycode=0xbb "parenleft", up)
...
...So I modified my x11vnc to ignore the second key code.
NOTE: On standard keyboard:
- Left Bracket '(' is - <shift> '9' &
- Right Bracket ')' is - <shift> '0'
To ignore the second keycode I updated my startup script with -skip_keycodes flag:
ExecStart=/usr/bin/x11vnc -auth /run/user/1XXX/gdm/Xauthority -forever -loop -noxdamage -repeat -rfbauth /home/WHO/.vnc/passwd -rfbport 5900 -shared -xkb -skip_keycodes 187,188 -display :1Now pressing the left / right bracket works and log reports:
# tail /var/log/x11vnc.log
...
...
...
07/08/2022 21:04:48 # keyboard(down, 0xffe1 "Shift_L") uip=0 31.0964
07/08/2022 21:04:48 xkb_tweak_keyboard: down keysym=0xffe1 "Shift_L"
xxx skipping keycode: 187
xxx skipping keycode: 188
07/08/2022 21:04:48 XTestFakeKeyEvent(dpy, keycode=0x32 "Shift_L", down)
07/08/2022 21:04:48 calling XTestFakeKeyEvent(50, 1) 31.0971
07/08/2022 21:04:48 client 2 network rate 1410.7 KB/sec (21684.3 eff KB/sec)
07/08/2022 21:04:48 client 2 latency: 0.5 ms
07/08/2022 21:04:48 dt1: 0.0102, dt2: 0.0033 dt3: 0.0005 bytes: 19028
07/08/2022 21:04:48 link_rate: LR_LAN - 1 ms, 1410 KB/s
07/08/2022 21:04:49 # keyboard(down, 0x28 "parenleft") uip=0 32.6461
07/08/2022 21:04:49 xkb_tweak_keyboard: down keysym=0x28 "parenleft"
xxx skipping keycode: 187 G1/L1
xxx skipping keycode: 187 G1/L2
07/08/2022 21:04:49 XTestFakeKeyEvent(dpy, keycode=0x12 "9", down)
07/08/2022 21:04:49 calling XTestFakeKeyEvent(18, 1) 32.6489
07/08/2022 21:04:50 # keyboard(up, 0x28 "parenleft") uip=0 32.7418
07/08/2022 21:04:50 xkb_tweak_keyboard: up keysym=0x28 "parenleft"
xxx skipping keycode: 187 G1/L1
xxx skipping keycode: 187 G1/L2
07/08/2022 21:04:50 XTestFakeKeyEvent(dpy, keycode=0x12 "9", up)
07/08/2022 21:04:50 calling XTestFakeKeyEvent(18, 0) 32.7421
07/08/2022 21:04:51 # keyboard(down, 0x29 "parenright") uip=0 34.1272
07/08/2022 21:04:51 xkb_tweak_keyboard: down keysym=0x29 "parenright"
xxx skipping keycode: 188 G1/L1
xxx skipping keycode: 188 G1/L2
07/08/2022 21:04:51 XTestFakeKeyEvent(dpy, keycode=0x13 "0", down)
07/08/2022 21:04:51 calling XTestFakeKeyEvent(19, 1) 34.1283
07/08/2022 21:04:51 # keyboard(up, 0x29 "parenright") uip=0 34.2371
07/08/2022 21:04:51 xkb_tweak_keyboard: up keysym=0x29 "parenright"
xxx skipping keycode: 188 G1/L1
xxx skipping keycode: 188 G1/L2
07/08/2022 21:04:51 XTestFakeKeyEvent(dpy, keycode=0x13 "0", up)
07/08/2022 21:04:51 calling XTestFakeKeyEvent(19, 0) 34.2373
07/08/2022 21:04:51 # keyboard(up, 0xffe1 "Shift_L") uip=0 34.6724
07/08/2022 21:04:51 xkb_tweak_keyboard: up keysym=0xffe1 "Shift_L"
07/08/2022 21:04:51 XTestFakeKeyEvent(dpy, keycode=0x32 "Shift_L", up)
07/08/2022 21:04:51 calling XTestFakeKeyEvent(50, 0) 34.6726
07/08/2022 21:04:53 created selwin: 0x1c00040
07/08/2022 21:04:53 called initialize_xfixes()
...
...
...NOTE: This issue was reporting in "Virtual Box" defect - Ticket #4772 (and marked as "won't fix"), thank you for helping with "work around".
This should work until the next Ubuntu upgrade ....
Be prepared for this to break with the next Ubuntu release ...
Unfortunately the x11vnc setup tends to get re-broken on a regular basis, so be prepared for your setup to fail with each new Ubuntu upgrade release.
This is why I have documented the diagnostic tools, so you can tweek your setup and get it running again.
Hopefully in the fullness of time all this will work without having to know any of this.
Summary
This is my personal blog on using x11vnc to meet my needs.
Yes, this is a hack solution based on not having time to do something better.
It would be great is there was a well documented solution that could handle arbitary users and allow access without need to be logged in and if you look at my first posting on the within Ubuntu "self help" there are various other solution variants.
I have not had the time to verify or validate these, as they mostly use shell scripts which would take some effort to understand how they work.
In fullness of time maybe wayvnc will achieve goal of providing "out of box" remote desktop, but for now the systemd work around with two x11vnc servers (one for greeter & one for session) is likely for form basis for other solution variants.
References & Links:
"Ubuntu 18.04 LTS x11vnc no longer works" - my first posting (zebity) and diagnosis of problem, now 3 years ago and still getting new updates and suggestions....
"VNC/Servers Ubuntu Community Help" - provides useful help on alternate VNC server options, but is not fully current and so you will need to find other information
wayland - what is a compositor ... "Wayland is intended as a simpler replacement for X, easier to develop and maintain. GNOME and KDE are expected to be ported to it." .
wayvnc - in the fullness of time maybe this might be an option that works ...
ssh port forwarding - you can do a lot with ssh port forwarding...
Virtual Box Ticket #4772 - defect posting on missing key presses