TurboVNC on Clear Linux

marioroy · March 25, 2023, 5:51am

Do you wish to remote-desktop into Clear Linux? TurboVNC works great. You’d need the package-utils bundle (providing the rpm command), x11-server, and x11-tools.

sudo swupd bundle-add package-utils x11-server x11-tools

First, there is a bug ticket for the CL team to add three missing symbolic-links. Create the symbolic links if missing.

github.com/clearlinux/distribution

Missing xorg, xorg.lst, and xorg.xml in /usr/share/X11/xkb/rules/

opened 07:52PM - 23 Mar 23 UTC

closed 10:54AM - 27 Mar 23 UTC

marioroy

bug new

The xorg, xorg.lst, and xorg.xml files are symbolic links, missing in Clear Linu…x. This may be the reason of folks reporting keyboard mapping failing in the forum. Ditto for TurboVNC not working (xkbcomp failing, resolved by making the symbolic links). ```bash cd /usr/share/X11/xkb/rules sudo ln -s base xorg sudo ln -s base.lst xorg.lst sudo ln -s base.xml xorg.xml ``` ```bash $ pwd /usr/share/X11/xkb/rules $ ls -l total 808 -rw-r--r-- 1 root root 44498 Feb 1 2019 base -rw-r--r-- 2 root root 58346 Feb 1 2019 base.extras.xml -rw-r--r-- 2 root root 46138 Feb 1 2019 base.lst -rw-r--r-- 2 root root 251261 Feb 1 2019 base.xml -rw-r--r-- 1 root root 39445 Feb 1 2019 evdev -rw-r--r-- 2 root root 58346 Feb 1 2019 evdev.extras.xml -rw-r--r-- 2 root root 46138 Feb 1 2019 evdev.lst -rw-r--r-- 2 root root 251261 Feb 1 2019 evdev.xml -rw-r--r-- 1 root root 91 Feb 1 2019 README -rw-r--r-- 1 root root 864 Feb 1 2019 xfree98 -rw-r--r-- 1 root root 1086 Feb 1 2019 xkb.dtd lrwxrwxrwx 1 root root 4 Mar 23 14:42 xorg -> base lrwxrwxrwx 1 root root 8 Mar 23 14:42 xorg.lst -> base.lst lrwxrwxrwx 1 root root 8 Mar 23 14:42 xorg.xml -> base.xml ``` The three symbolic links exists in { CentOS, Fedora, Ubuntu } (verified), and possibly other Linux distributions.

cd /usr/share/X11/xkb/rules
sudo ln -s base xorg
sudo ln -s base.lst xorg.lst
sudo ln -s base.xml xorg.xml

Running TurboVNC on Clear Linux is possible after making the 3 symbolic links.

https://www.turbovnc.org/

The scripts embedded in the TurboVNC RPM package is not compatible on Clear Linux. So, the --noscripts option to rpm is necessary.

sudo rpm -ivh --nodeps --noscripts turbovnc-3.0.3.x86_64.rpm

That completes the TurboVNC installation. Launch vncserver on the server side.

/opt/TurboVNC/bin/vncserver

Desktop 'TurboVNC: clr-pc:1 (mario)' started on display clr-pc:1

Starting applications specified in /opt/TurboVNC/bin/xstartup.turbovnc
Log file is /home/mario/.vnc/clr-pc:1.log

Notice :1 above. Provide the same X display/screen number when connecting from the client side, using vncviewer or connect application. Note: There is a :1 after the IP address.

TurboVNC logs are found in your HOME ~/.vnc/ folder. Press the red X icon to disconnect, though the session still remains on the server side. To kill the session, pass the -kill option to vncserver on the server side using the same X display/screen number.

/opt/TurboVNC/bin/vncserver -kill :1

There is an issue request for adding audio support to TurboVNC. In the meantime, see my tips (in the same thread) having audio tunneled via OpenSSH. It works great. Note: Your configuration may differ. My client machine is a mac laptop.

To uninstall TurboVNC, like before, the --noscripts option is needed.

sudo rpm -e --noscripts turbovnc

Aqua1ung · March 25, 2023, 6:42pm

You’re missing a “swupd” in sudo bundle-add package-utils x11-server x11-tools : sudo swupd bundle-add package-utils x11-server x11-tools

Otherwise, it looks like I, for one, am running into some trouble:

Command return looks good:

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

WARNING: DadsGram:1 is taken because of /tmp/.X11-unix/X1
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

And here’s what the log says:

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 14:36:37 Using security configuration file /etc/turbovncserver-security.conf
25/03/2023 14:36:37 Enabled security type 'tlsvnc'
25/03/2023 14:36:37 Enabled security type 'tlsotp'
25/03/2023 14:36:37 Enabled security type 'tlsplain'
25/03/2023 14:36:37 Enabled security type 'x509vnc'
25/03/2023 14:36:37 Enabled security type 'x509otp'
25/03/2023 14:36:37 Enabled security type 'x509plain'
25/03/2023 14:36:37 Enabled security type 'vnc'
25/03/2023 14:36:37 Enabled security type 'otp'
25/03/2023 14:36:37 Enabled security type 'unixlogin'
25/03/2023 14:36:37 Enabled security type 'plain'
25/03/2023 14:36:37 Desktop name 'TurboVNC: DadsGram:2 (dad)' (DadsGram:2)
25/03/2023 14:36:37 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t
25/03/2023 14:36:37 Listening for VNC connections on TCP port 5902
25/03/2023 14:36:37   Interface 0.0.0.0
25/03/2023 14:36:37 Framebuffer: BGRX 8/8/8/8
25/03/2023 14:36:37 New desktop size: 1240 x 900
25/03/2023 14:36:37 New screen layout:
25/03/2023 14:36:37   0x00000040 (output 0x00000040): 1240x900+0+0
25/03/2023 14:36:37 Maximum clipboard transfer size: 1048576 bytes
25/03/2023 14:36:37 VNC extension running!
xstartup.turbovnc: Creating new session bus instance:
xstartup.turbovnc:   unix:path=/tmp/dbus-8HwleIA0Js,guid=ec688357887d75f7e22a9cd5641f3f36
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 28379

Are you running TurboVNC in Wayland?

Aqua1ung · March 25, 2023, 10:48pm

Yeah, it appears that TurboVNC does not work with Wayland, so that puts the kibosh on it as far as I am concerned. Many thanks for your efforts, nonetheless!

marioroy · March 26, 2023, 12:49am

Thanks. Fixed.

No. Wayland support is not yet available. Before using TurboVNC, log out of the Wayland session and select “GNOME on Xorg”. This requires the “x11-server” and “x11-tools” bundles, mentioned in the first post.

github.com/TurboVNC/turbovnc

Wayland Support

opened 08:16PM - 19 Nov 15 UTC

dcommander

enhancement funding needed

My (admittedly limited) understanding of Wayland is that it is essentially frame…-based and image-based from the get-go. All of the drawing and rendering takes place within the application, and the application then tells the Wayland compositor, "Here's a frame. Display it in this window." This is a very natural fit for VNC, since a VNC server could simply be a Wayland compositor that processes each frame from an application and converts it into a single RFB framebuffer update. It would greatly simplify the VNC server, since it would no longer be necessary for it to hook into low-level drawing primitives or to convert the inherently single-buffered, fine-grained drawing approach used by X11 into a more "frame-like", coarse-grained, image-based approach suitable for remote interaction. At first glance, it also seems like this could provide a straightforward way of supporting: - Seamless windows. Since each Wayland application is generating frames, not primitives, each window essentially acts-- from the point of view of the compositor-- like a video stream, so it would be straightforward to have a server-side compositor that translates the windows into separate RFB streams and a client application that translates them back into windows. - Remote 3D. The details are still sketchy, but my understanding is that Wayland applications will be required to handle GPU access on their own, which may eliminate the need for VirtualGL (except for supporting legacy X11 applications.) One would assume that a typical Wayland OpenGL application would already be doing off-screen rendering (via EGL) and that calling eglSwapBuffers() would move the off-screen image into the compositor, but I'm just guessing at this point. It may still be necessary to have a VirtualGL-like solution that straightforwardly marshals EGL commands to the Wayland compositor that is attached to the GPU rather than the hypothetical TurboVNC Wayland compositor. - Frame-based video codecs like H.264. Since Wayland actually does have a concept of frames, it would be natural to design a Wayland VNC server such that particular windows (3D windows, for instance) are transmitted as H.264 streams, thus eliminating [all of the problems](http://www.turbovnc.org/About/H264) inherent with using H.264 in the existing VNC architecture.

Aqua1ung · March 28, 2023, 3:45pm

Thank you, I know how to switch to Xorg, and I have no doubt that I’d be able make TurboVNC work. For now, however, I am stubborn enough to be looking for a Wayland solution, which is why I’ve chosen to focus on xrdp and NoMachine. I am hoping to make at least one of these work, with help form the good folks in these forums.

Again, many thanks for your efforts!