rpi-4-debian-bookworm-6.1.54-rt15-arm64-ext4-2023-11-17-1731.img - TigerVNC?

Facing the same issue as yourself, looking for VNC connection to this "rpi-4-debian-bookworm-6.1.54-rt15-arm64-ext4-2023-11-17-1731" image, and failing.

I ended up installing X11VNC.
$sudo apt-get install x11vnc
$x11vnc

I Don't know much about it, seems to be a VNC server that connects only to active screen session rather than opening a new session.

Works with Tiger and Real VNC Clients. Regardless of the fact its sharing the main session, I stopped here as this was fine for my use and after seeing the amount of time you spent trying to do it properly I have called it quits here.

Nice BHar, thanks for sharing. Gave that a shot; sure enough it works! Awesome.

Wanted to mention that I got autologin working by editing /etc/lightdm/lightdm.conf and changing `#autologin-user=` to `autologin-user=cnc`. There's also some settings in there for VNC but they seemed irrelevant (for tigervncserver anyways.)

Cheers - I just got a blank screen this morning on VNC connection and realised that it doesn't work pre-login - so was coming back to mention it here and found your update.
"autologin-user=cnc" works perfect - thanks again.

Not sure if you have noticed a similar issue, but I need to wait about 30 seconds after boot before I see a port listening on 5900 with $netstat -pat , and am able to connect? I suppose its not a big issue.

I have set the service to startup as follows:

[Unit]
Description=Start x11vnc at startup.
After=multi-user.target

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -auth guess -forever -loop -noxdamage -repeat -rfbauth /etc/x11vnc.pwd -rfbport 5900 -shared -o /var/log/x11vnc.log -localhost

[Install]
WantedBy=multi-user.target

BHar wrote:

Not sure if you have noticed a similar issue, but I need to wait about 30 seconds after boot before I see a port listening on 5900 with $netstat -pat , and am able to connect? I suppose its not a big issue.

I think this stems from `After=multi-user.target`. multi-user.target is systemd's way of targeting the point in the boot process where a console login would have been presented. Technically this is still too early, as X isn't even loaded yet. But by the time the service runs, X is mostly started, and it should patiently wait for screen :0.0 to be created then connect to it immediately.

Here's what I'm currently using, and it seems to activate right alongside the GUI.

x11vnc -xkb # with -noxkb, shift and alt did not work in vnc
-noxrecord # intentionally disabled
-xfixes # supposedly includes some fixes
-xdamage # supposed to reduce network bandwidth, unconfirmed
-display :0 # on multi-display systems, this may need to be :0.1 or :1.0
-auth guess # not exactly sure what this does
-rfbauth /home/cnc/.vnc/passwd # this specifies where the vnc passwd file is
-geometry 1024x768 # setting the geometry here will force the vnc window to this size (regardless of aspect ratio)
Restart=always # on-failure will work, but may not restart if client purposely closes vnc (untested)
RestartSec=5 # restart slowly
OOMPolicy=kill # if out of memory, kill this service

Will have to `sudo systemctl daemon-reload` then `sudo systemctl restart x11vnc` or reboot to see the changes.

After using the above for awhile, these two things may be helpful:
1. Add "-repeat" to the x11vnc server line if using the TigerVNC client. That client doesn't understand x11vnc's key repeat sequence. Adding "-repeat" causes key repeating to work as expected with this client. Re: github.com/TigerVNC/tigervnc/issues/66
2. If x11vnc is taking 1:30 to shut down when powering off or rebooting the pi (x11vnc not closing properly), add "DefaultTimeoutStopSec=15s" to the service or similar. Re: www.reddit.com/r/kde/comments/rpwcm4/sdd...tem_for_130_minutes/
3. If THAT seems to give you a black screen at the desktop, reboot. Every once-in-awhile I'll get a black desktop; not sure why yet. SSH into it and do a "sudo reboot now".