3.0.90 (3.1 beta1)

Assets

• turbovnc-3.0.90.tar.gz is the official source tarball for this release. The automatically generated "Source code" assets are not supported.
• Refer to https://TurboVNC.org/Downloads/DigitalSignatures for information regarding the methods used to sign the files in this release and instructions for verifying the signatures.
• The binary packages were built with libjpeg-turbo 3.0.0 and Adoptium OpenJDK 17.0.8+7.

Packaging Changes

• Linux/i386 RPM and DEB packages are no longer provided. Those packages were only useful for 32-bit-only Linux distributions, which are increasingly rare. Within the Red Hat and Ubuntu ecosystems, as an example, RHEL 6 (EOL 2020-11-30) and Ubuntu 18.04 LTS (EOL 2023-05-31) were the last enterprise releases to support 32-bit x86 CPUs.
• The Windows installers are temporarily unsigned.

Support

Code Quality: Beta
Current Support Category: EOL

Documentation

User’s Guide for TurboVNC 3.1 (Beta)

Release Notes

Significant changes relative to 3.0.3:

1. The TurboVNC Server and Viewer now support UTF-8 clipboard transfers.

2. The "Global" tab in the TurboVNC Viewer Options dialog now has a button that can be used to reset all options to their default values.

3. The TurboVNC Viewer now maintains a different set of options for each unique TurboVNC host.

4. The TurboVNC Server and Viewer now implement the QEMU Extended Key Event, QEMU LED State, and VMware LED State RFB extensions, which allow raw keyboard scancodes to be transmitted to the VNC server instead of X11 keysyms. Effectively, this means that the mapping of keycodes into keysyms is performed on the host rather than the client, which eliminates various system-specific and locale-specific key mapping issues (including issues with dead keys on international keyboards.) This feature also fixes lock key synchronization issues when using the TurboVNC Viewer with VMware's VNC server.

5. If the NoReconnect parameter is unset (which it is by default), the TurboVNC Viewer will now offer to reconnect if the initial connection or authentication fails.

6. The TurboVNC Server can now listen on a Unix domain socket, rather than a TCP port, for connections from VNC viewers. This is useful in conjunction with SSH tunneling, and it also allows the Unix domain socket permissions to act as an authentication mechanism for a TurboVNC session. Two new Xvnc arguments, -rfbunixpath and -rfbunixmode, can be used to specify the Unix domain socket path and, optionally, the permissions. A new vncserver argument, -uds, causes the script to automatically choose an appropriate Unix domain socket path under the TurboVNC user directory. See the Xvnc and vncserver man pages for more details.

7. The TurboVNC Viewer can now connect to a VNC server that is listening on a Unix domain socket. This is accomplished by specifying {host}::{uds_path} as the VNC server, where {host} is the hostname or IP address of the VNC host and {uds_path} is the path to the Unix domain socket on the host. If {host} is not localhost, then SSH tunneling with an external SSH client is implied. Refer to the TurboVNC Viewer's usage screen (specifically, the documentation of the Server parameter) and the TurboVNC User's Guide for more details.

8. The TurboVNC Viewer now asks for confirmation before overwriting an existing screenshot file.

9. The TurboVNC Viewer now supports a new TurboVNC-specific connection info file format. TurboVNC connection info files have an extension of .turbovnc, and each line of these files contains a TurboVNC Viewer parameter name and value separated by an equals sign (=).

10. The default values of all TurboVNC Viewer parameters can now be modified by specifying the values in ~/.vnc/default.turbovnc using the connection info file syntax described above.