Something has gone wrong.

[Aqua1ung]

Apologies for the cryptic title, but at this point in time I got no better one for this. Attempting to run TurboVNC 3.0.3 on my Clear Linux (Wayland) distro. Here's what the command line returns:

dad@DadsGram~ $ /opt/TurboVNC/bin/vncserver

WARNING: DadsGram:1 is taken because of /tmp/.X1-lock
Remove this file if there is no X server DadsGram:1

Desktop 'TurboVNC: DadsGram:2 (dad)' started on display DadsGram:2

Starting applications specified in /opt/TurboVNC/bin/xstartup.turbovnc
Log file is /home/dad/.vnc/DadsGram:2.log

which looks pretty normal to me. Here's what the log file shows:

TurboVNC Server (Xvnc) 64-bit v3.0.3 (build 20230227)
Copyright (C) 1999-2022 The VirtualGL Project and many others (see README.txt)
Visit http://www.TurboVNC.org for more information on TurboVNC

25/03/2023 15:17:34 Using security configuration file /etc/turbovncserver-security.conf
25/03/2023 15:17:34 Enabled security type 'tlsvnc'
25/03/2023 15:17:34 Enabled security type 'tlsotp'
25/03/2023 15:17:34 Enabled security type 'tlsplain'
25/03/2023 15:17:34 Enabled security type 'x509vnc'
25/03/2023 15:17:34 Enabled security type 'x509otp'
25/03/2023 15:17:34 Enabled security type 'x509plain'
25/03/2023 15:17:34 Enabled security type 'vnc'
25/03/2023 15:17:34 Enabled security type 'otp'
25/03/2023 15:17:34 Enabled security type 'unixlogin'
25/03/2023 15:17:34 Enabled security type 'plain'
25/03/2023 15:17:34 Desktop name 'TurboVNC: DadsGram:2 (dad)' (DadsGram:2)
25/03/2023 15:17:34 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t
25/03/2023 15:17:34 Listening for VNC connections on TCP port 5902
25/03/2023 15:17:34   Interface 0.0.0.0
25/03/2023 15:17:34 Framebuffer: BGRX 8/8/8/8
25/03/2023 15:17:34 New desktop size: 1240 x 900
25/03/2023 15:17:34 New screen layout:
25/03/2023 15:17:34   0x00000040 (output 0x00000040): 1240x900+0+0
25/03/2023 15:17:34 Maximum clipboard transfer size: 1048576 bytes
25/03/2023 15:17:34 VNC extension running!
xstartup.turbovnc: Creating new session bus instance:
xstartup.turbovnc:   unix:path=/tmp/dbus-l3UwAJBNK0,guid=d4d8a0434302e03338f0b17e641f48cf
xstartup.turbovnc: Using 'gnome' window manager in
xstartup.turbovnc:   /usr/share/xsessions/gnome.desktop
xstartup.turbovnc: Executing /usr/bin/gnome-session
Killing Xvnc process ID 3220

What am I doing wrong? Here are a few more details about my rig.

[dcommander]

I have no experience with Clear Linux, but my best guess is that maybe the GNOME session uses Wayland by default. A pure Wayland window manager won't work with TurboVNC, because TurboVNC is a virtual X server. Is there a separate GNOME/X11 session file? You can specify a different window manager by passing -wm to /opt/TurboVNC/bin/vncserver or setting the $wm variable in /etc/turbovncserver.conf or ~/.vnc/turbovncserver.conf. The value of that argument/variable corresponds to a .desktop file under /usr/share/xsessions, minus the .desktop extension. If there is a separate session file for GNOME/X11 (for example, /usr/share/xsessions/gnome-x11.desktop), then you can pass that value (for example, gnome-x11) to -wm or $wm. Otherwise I would suggest installing Xfce or MATE and using that with TurboVNC.

[Aqua1ung]

Thank you. It looks like Wayland is the issue. I am currently looking for a remote desktop solution that does work w/Wayland, and can also be installed on CL. Not too many choices I'm afraid.

[dcommander]

It is on my long-term radar (#18), but it would be a massive undertaking. I would need to engage with an organization that needs such a remote desktop solution, and it would probably take in excess of US$10,000 of labor in order to develop that solution around TurboVNC. (The good news is that our viewer would still work as-is. We would just need a Weston-based TurboVNC Server.) The idea is that the TurboVNC Server would become a Wayland compositor, and X applications would be supported by running the system's installation of Xwayland against our compositor. It should be possible to get 3D acceleration for free with such a solution, thus eliminating the need for a VirtualGL-like interposer.