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), "sudo mkdir /etc/systemd/system.conf.d && sudo cp /etc/systemd/system.conf /etc/systemd/system.conf.d/ && sudo nano /etc/systemd/system.conf.d/system.conf" and add "DefaultTimeoutStopSec=15s" to it. Re: www.reddit.com/r/kde/comments/rpwcm4/sdd...tem_for_130_minutes/
EDIT:
3. Every once-in-awhile I'll get a black (blank) desktop.  Unsure what causes it, but seems to be related to the lighdm display manager.  Have found two ways of getting around that: a) Do a CTRL-ALT-F2 and login, then issue a "systemctl restart lightdm".  b) SSH into it and do the previous or "sudo reboot now".  Issues with LightDM hanging are sporadic for many people and computers, so it's likely nothing special about the Rpi or Debian 12.