2.2

Assets

• turbovnc-2.2.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 2.0.0.

Support

Code Quality: Stable
Current Support Category: Extended

Documentation

User’s Guide for TurboVNC 2.2

Release Notes

Significant changes relative to 2.2 beta1:

1. The Alt button in the Java/Mac/Un*x TurboVNC Viewer toolbar now works properly. Previously, it was sending an Alt key press and a Ctrl key release.

2. Fixed an issue whereby, when using certain Command-{key} sequences in the Mac TurboVNC Viewer (specifically: Command-`, which switches between the two most recent viewer windows; Command-H, which hides all viewer windows; Command-Q, which exits the viewer; and Command-P, which toggles the profiling dialog), {key} was unintentionally transmitted to the VNC server.

3. Fixed a segfault in the TurboVNC Server that occurred when attempting to disable the Composite extension. This was a regression caused by a bug in the xorg-server 1.19.6 code.

4. The default xstartup.turbovnc script that the TurboVNC Server creates now works around an issue whereby the desktop contents would not be displayed when running the GNOME Classic window manager on RHEL/CentOS 7 or recent Fedora releases.

5. The default xstartup.turbovnc script that the TurboVNC Server creates now launches Unity 2D by default on Ubuntu 12, as was the case with TurboVNC 2.1.x. Unity 3D 5.20.x does not work properly with the TurboVNC X server, and Unity 2D provides a similar user experience.

6. The default xstartup.turbovnc script that the TurboVNC Server creates now properly launches the GNOME 3, GNOME Flashback (Metacity), and MATE window managers on Ubuntu 18.

7. Fixed an issue whereby the TurboVNC Server would fail to launch via the vncserver script (giving the error "Unrecognized option: -x509cert") if the server was built with TVNC_USETLS=OpenSSL or TVNC_USETLS=GnuTLS and the OpenSSL or GnuTLS headers/libraries were not installed.

8. The -list option for the vncserver script no longer lists orphaned TurboVNC sessions (sessions for which a PID file exists in the user's VNC directory but for which the corresponding Xvnc process is no longer running.)

9. Fixed an issue in the Java TurboVNC Viewer whereby, when using SSH tunneling with the built-in SSH client, the SSH connection would remain open even if the associated VNC connection had been closed.

10. Fixed an issue in the vncviewer-javaw.bat script, which is used to launch the Java TurboVNC Viewer on Windows without a console window, whereby jawt.dll would not be found when using certain versions of the Oracle JRE.

11. The Java TurboVNC Viewer now builds successfully with JDK 11.

12. Fixed an issue in the Mac TurboVNC Viewer whereby the "Preferences..." option in the VncViewer menu (and its associated hotkey, Command-,) would pop up a new copy of the Options dialog even if the Options dialog was already visible.

13. Worked around an issue in Java 9 through 11 that caused the Profiling dialog in the Mac TurboVNC Viewer to immediately disappear if it was popped up using the Command-P hotkey.

2.1.90 (2.2 beta1)

Assets

• turbovnc-2.1.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 2.0 beta1. Relative to TurboVNC 2.1.x, this reduces the CPU usage of Tight encoding (with JPEG compression) when using an AVX2-capable CPU.

Support

Code Quality: Beta
Current Support Category: EOL

Documentation

User’s Guide for TurboVNC 2.2 (Beta)

Release Notes

Significant changes relative to 2.1.2:

1. Added a system menu option and hotkey (CTRL-ALT-SHIFT-V) to the Windows TurboVNC Viewer that can be used to quickly toggle view-only mode on and off.

2. Added system menu options and hotkeys to the Windows TurboVNC Viewer that can be used to zoom in and out (increase or decrease the scaling factor) or reset the view to 100% when desktop scaling is enabled.

3. The TurboVNC Server now includes a GLX extension that uses the swrast DRI driver installed on the system to perform unaccelerated OpenGL rendering. Using VirtualGL for OpenGL rendering will still be much faster and more compatible, but this feature allows the TurboVNC Server to be used for casual OpenGL rendering if VirtualGL is not installed. Passing -extension GLX to vncserver disables the extension. Note that your system must have Mesa 8.x or later installed in order for the swrast DRI driver to be available. On systems that do not have vendor-specific GPU drivers installed, or on systems that provide a libglvnd-enabled build of Mesa, the TurboVNC Server's GLX extension will use direct rendering, which improves performance and compatibility.

4. Java 6 and earlier is no longer supported with the Java/Mac/Un*x TurboVNC Viewer. This increases the Mac system requirements to OS X/macOS 10.7 "Lion" or later. Apple's obsolete Java for OS X is no longer supported, and the standalone "AppleJava" version of the TurboVNC Viewer is no longer provided. Java SE 6 ceased receiving public updates in 2013 and, as of this writing, critical bug fixes and security fixes for that platform are only available with an Oracle Extended Support contract. Furthermore, Red Hat ceased supporting OpenJDK 6 in late 2016. The TurboVNC Viewer JAR will continue to be built with -source 1.6 -target 1.6, but it will only be tested with Oracle Java SE releases that are currently receiving public updates and OpenJDK releases that are actively supported by Red Hat. The 2.1.x version of the TurboVNC Viewer will continue to support Java 6 on a break/fix basis.

5. The ability to run the Java TurboVNC Viewer as an in-browser applet has been removed. Most popular web browsers have already abandoned the NPAPI plugin standard around which the Java plugin was designed, because that plugin standard grants full access to the client machine. However, such access is necessary in order to write a full-featured application (including a VNC viewer), and absent any other cross-browser plugin standard, it would be impossible for Oracle to make the Java plugin more secure without abandoning the write-once-run-anywhere nature of the Java language. Thus, they have chosen not to include any kind of browser plugin in Java 9. As of this writing, NPAPI support can only be obtained on most platforms by installing an older browser version. The only advantage of using the TurboVNC Viewer as an applet, as opposed to with Java Web Start, was the ability to embed the viewer in a web page, but this mode of operation had some known usability issues and was increasingly receiving little or no attention from the TurboVNC community. The applet feature will continue to be supported in TurboVNC 2.1.x on a break/fix basis.

6. The TurboVNC Server now has full support for the Xinerama extension, which allows multiple virtual screens to be configured within the same remote desktop. This provides better usability for multi-screen environments, since dialogs and maximized application windows are no longer split across screen boundaries. The server's screen layout can be configured in the following ways:

   • Multi-screen geometry descriptors, in the format W0xH0+X0+Y0[,W1xH1+X1+Y1,...,WnxHn+Xn+Yn]], are now accepted in these places:

     • The TurboVNC Server's -geometry command-line argument and the $geometry variable in turbovncserver.conf (thus allowing the user to specify a screen layout for the initial framebuffer)
     • The "Remote desktop size" combo box in the TurboVNC Viewer's Options dialog, the TurboVNC Viewer's -desktopsize command-line argument, and the DesktopSize parameter in the Java TurboVNC Viewer (thus allowing the user to remotely request a specific screen layout)
     • A new .vnc connection info file directive (desktopsize) that can be used instead of the resizemode, desktopwidth, and desktopheight directives

   • The automatic desktop resize feature in the TurboVNC Viewer is now multi-screen aware in both windowed and full-screen modes. When the viewer window is resized or reset to its default position, the viewer will now compute and request a new server-side screen layout that matches not only the viewer window boundaries but also the client's screen boundaries and the position of the taskbar/menu bar on the client. The single-screen automatic desktop resizing behavior of the TurboVNC 2.1.x viewer can be restored by setting the TVNC_SINGLESCREEN environment variable or the turbovnc.singlescreen Java system property to 1.

   • The X RandR extension can be used, either from the command line (xrandr) or through the window manager's display configuration applet, to modify the server's screen layout.

7. The TurboVNC Server is now based on xorg-server 1.19.6, which improves compatibility with newer window managers.

8. By default, the TurboVNC Server will no longer listen on a TCP socket for X11 protocol connections from X11 applications. This mimics the behavior of most modern X servers, which require X11 connections to be made using Unix domain sockets. To restore the behavior of previous versions of TurboVNC, pass -listen tcp to vncserver (assuming that X11 TCP connections are not globally disabled in the TurboVNC Server's security configuration file.)

9. The default xstartup.turbovnc script that the TurboVNC Server creates will no longer start a 2D window manager by default on Ubuntu systems, since the TurboVNC Server now has a software OpenGL implementation that supports running Unity 3D without VirtualGL. The xstartup.turbovnc script will now always attempt to start the window manager specified by the system or user defaults, unless the TVNC_WM environment variable is set. Setting the TVNC_WM environment variable to 2d will start the GNOME fallback/flashback or Unity 2D session on Ubuntu systems instead of Unity 3D. Setting the TVNC_WM environment variable to 2d will also start the GNOME classic session on RHEL 7 and recent Fedora releases. To start MATE, set the TVNC_WM environment variable to mate-session.

10. The -3dwm option for the vncserver script has been renamed to -vgl, to reflect the fact that the TurboVNC Server is now able to run 3D window managers without using VirtualGL.

11. Clipboard synchronization is now performed within the TurboVNC Server process, so the tvncconfig utility is no longer needed or provided.

12. The TurboVNC Server now uses a 30-bit default visual (BGRX 10/10/10/2 on little endian machines and XRGB 2/10/10/10 on big endian machines) when launched with -depth 30. This is mainly useful for application testing at the moment, since the pixels are downsampled to 8-bit RGB prior to transmission.

13. Introduced a new CMake variable (TVNC_SYSTEMLIBS) that, when enabled, will cause the TurboVNC Server to be built against the system-supplied versions of zlib, bzip2, and FreeType.

14. Introduced a new CMake variable (TVNC_SYSTEMX11) that, when enabled, will cause the TurboVNC Server to be built against the system-supplied versions of the X11 and OpenGL headers and libraries. This will probably fail unless the system is using xorg-server 1.19.x or later.

15. Fixed a bug in the TurboVNC Server's VeNCrypt implementation that prevented it from working properly with LibVNCClient.

16. The TurboVNC Server and Windows TurboVNC Viewer, when built with TVNC_SYSTEMLIBS=0 (which is the default), now incorporate the Intel zlib library, which accelerates zlib encoding and decoding significantly on SSE2-equipped CPUs. This improves the end-to-end performance of the Lossless Tight + Zlib encoding method, and of non-JPEG (low-color-depth) subrectangles encoded with one of the Tight + JPEG encoding methods, by approximately 20-40%.

17. The Mac/Java TurboVNC Viewer now includes remote drawing tablet support. This feature is implemented using a TurboVNC Helper JNI library, which is similar to the TurboVNC Helper included with the Un*x TurboVNC Viewer. This library connects the built-in drawing tablet drivers for OS X/macOS with the existing remote X Input feature in the Java TurboVNC Viewer and TurboVNC Server.

18. Fixed an issue in the Un*x/X11 TurboVNC Viewer and the Windows/Java TurboVNC Viewer whereby keyboard grabbing was always initially disabled in the second and subsequent connections initiated by the viewer, regardless of the grab mode.

19. The Java TurboVNC Viewer now builds and runs with Java 9 and later.

20. The SSH tunneling feature in the Java TurboVNC Viewer now works pr...

2.1.2

Assets

• turbovnc-2.1.2.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 1.5.2.

Support

Code Quality: Stable
Current Support Category: EOL

Documentation

User’s Guide for TurboVNC 2.1.2

Release Notes

Significant changes relative to 2.1.1:

1. Improved the usability of multithreaded Tight encoding in the TurboVNC Server:

   • The TVNC_MT and TVNC_NTHREADS environment variables now have corresponding Xvnc command-line options (-mt and -nthreads), which makes it easy to enable multithreaded Tight encoding in TurboVNC Server instances spawned by init.d/systemd.
   • The turbovncserver.conf file, which is parsed by the vncserver script, now includes two new variables ($multiThread and $numThreads) that can be used to configure multithreading on a system-wide basis or for all TurboVNC sessions started under a particular user account.
   • Previously, if multithreaded Tight encoding was enabled, the Tight encoder would use as many threads as there were CPU cores on the TurboVNC host, up to a maximum of 8. However, because of limitations in the Tight encoding type, using more than 4 threads requires the rfbTightNoZlib extension, which is only supported by the TurboVNC Viewer. To avoid confusion, the TurboVNC Server will no longer use more than 4 threads (regardless of the number of CPU cores) unless the thread count is explicitly specified.

2. Fixed an issue in the console version of the Windows TurboVNC Viewer (cvncviewer.exe) whereby the console output of the viewer could not be redirected to a file.

3. The Java/Mac/Un*x TurboVNC Viewer now includes an option for reversing the direction of mouse scroll wheel events that are sent to the VNC server. This is useful when connecting from clients that have "natural scrolling" enabled.

4. Fixed an issue whereby, under certain rare circumstances (for instance, if the Xvnc binary was setuid root), the TurboVNC Server would allow any user of the system (not just the session owner) to authenticate with a TurboVNC session using PAM User/Password Authentication, if the user ACL feature was disabled.

5. Fixed a BadMatch X11 error that occurred when attempting to resize the TurboVNC Server desktop to a smaller size using the X RandR 1.2 API (for instance, by executing xrandr --output TurboVNC --mode {new_mode}.)

6. Fixed an issue whereby the TurboVNC Server could not be built using GnuTLS 3.4.0 or later.

7. Improved the TLS encryption feature in the following ways:

   • The anonymous Elliptic Curve Diffie-Hellman (ECDH) key exchange algorithm is now supported when the TurboVNC Server is built using GnuTLS 3.0.0 and later. (The Java/Mac/Un*x TurboVNC Viewer already supports ECDH.)
   • The TurboVNC Server will now use the most recent version of the TLS protocol that both the server and the viewer support.
   • The "VNC connection info" dialog in the Java/Mac/Un*x TurboVNC Viewer will now display the TLS protocol version currently in use.
   • The TurboVNC Server can now be built with OpenSSL 1.1, and if it is built with TVNC_DLOPENSSL=1 (the default), it can use OpenSSL 1.1 at run time regardless of whether it was built on a machine that has OpenSSL 1.1 installed.
   • When using OpenSSL, the TurboVNC Server will now log a more meaningful error message if the TLS handshake fails.

8. Fixed an issue in the Mac (Java) TurboVNC Viewer whereby the initial non-full-screen window was positioned incorrectly if it spanned multiple screens.

9. Fixed an issue in the Windows (native) TurboVNC Viewer whereby multi-screen spanning did not work at all if the secondary display was to the left of the primary display.

10. Multi-screen spanning now works with the Linux/Un*x TurboVNC Viewer in full-screen mode, if the viewer is using the TurboVNC Helper library. (Due to limitations in X11, it is still not possible to use multi-screen spanning with the Linux/Un*x TurboVNC Viewer in windowed mode.) Also, the Linux/Un*x TurboVNC Viewer now falls back to Java's built-in full-screen window feature, thus allowing full-screen mode to work with single-screen (Primary) spanning even if the TurboVNC Helper library is not available.

11. The TurboVNC Server will now clamp the desktop dimensions to 32767x32767 regardless of the max-desktop-size setting in the security configuration file. This prevents two issues:

    • The server would fail to send framebuffer updates and would continuously log messages of the form "WARNING: Framebuffer update at 0,0 with dimensions 0x0 has been clipped to the screen boundaries" if the desktop width or height was set, by way of the -geometry command-line argument or a remote desktop resize request, to a value greater than 32767.
    • The server would segfault if a mode with a width or height greater than 32767 was configured and enabled using the X RandR extension.

    Although TurboVNC can handle framebuffer dimensions larger than this, the underlying X.org screen structure uses a signed short to represent width and height, and thus values larger than 32767 overflow the data type and can sometimes be interpreted as negative numbers.

12. Closed a loophole that allowed users to use X RandR functions to make the desktop larger than the dimensions allowed by the max-desktop-size setting in the security configuration file.

13. When automatic desktop resizing and automatic spanning are both enabled, the TurboVNC Viewer will now use single-screen spanning ("Primary monitor only") when in windowed mode and multi-screen spanning ("All monitors") when in full-screen mode.

14. Fixed an issue whereby the Java TurboVNC Viewer, when launched from the vncviewer-java.bat script, the Start Menu shortcut, or Java Web Start on Windows clients with a 32-bit JRE, would fail with "Error: missing 'server' JVM". On Windows, the 32-bit JRE only provides the client VM, and the 64-bit JRE only provides the server VM, so specifying -server in the launch scripts was unnecessary.

15. Worked around an issue whereby, when the TurboVNC Viewer was running on macOS 10.12 "Sierra", pressing and holding certain keys would cause the viewer to stop processing subsequent keystrokes if ApplePressAndHoldEnabled was set to true in the macOS user defaults (which it is by default in recent macOS releases.) It is still necessary to set ApplePressAndHoldEnabled to false, either in the global domain or the com.turbovnc.vncviewer.VncViewer domain, in order for key repeat to work with the TurboVNC Viewer.

16. The Java/Mac/Un*x TurboVNC Viewer now supports the user and noremotecursor directives in .vnc connection info files.

17. Fixed an issue that prevented the keyboard grabbing feature from working properly in the Java TurboVNC Viewer on 32-bit Windows systems.

18. Fixed an issue whereby, when server-side cursor rendering was enabled, the cursor would flicker on and off as the mouse was dragged.

19. Fixed an issue whereby the Java/Mac/Un*x TurboVNC Viewer would, under certain circumstances (specifically, when receiving a desktop size update from the server with automatic desktop resizing enabled, toggling on/off the toolbar, or changing the scaling settings), always behave as if the CurrentMonitorIsPrimary parameter was disabled.

20. The default xstartup.turbovnc script that the TurboVNC Server creates now allows the window manager startup script/executable to be specified using an environment variable (TVNC_WM.) This facilitates using a different window manager for local and remote desktop sessions on the same machine, or temporarily switching the window manager used by TurboVNC.

21. The default xstartup.turbovnc script that the TurboVNC Server creates now sets the XDG_SESSION_TYPE environment variable to x11. This is necessary when running GNOME 3 on Fedora 25 and later. Otherwise, GNOME 3 will assume it is operating in a Wayland environment.

22. Worked around an issue whereby desktop resizing in the TurboVNC Server would fail on Ubuntu 12.04 LTS (and likely on Ubuntu 12.10 and 13.04 as well, although those releases are EOL as of this writing) due to Ubuntu's inclusion of an experimental extension to the XFixes protocol that was never accepted upstream in X.org.

23. Fixed a bug in the X.org code that prevented the TurboVNC Server from working properly on little endian PowerPC systems.

24. Fixed a couple of issues in the TurboVNC Server that prevented cursors from being rendered and transmitted properly if the server was running on a big endian system.

25. Fixed an issue in the Windows TurboVNC Viewer whereby, if keyboard grabbing was disabled, using Alt-Tab to select another window would sometimes leave the Alt key in a pressed state on the server. Fixed a similar issue in the Mac TurboVNC Viewer whereby, when quitting the viewer using Command-Q or closing the connection using Command-W, the Super/Windows key would be left in a pressed state on the server.

26. Fixed an issue in the Java TurboVNC Viewer whereby the client clipboard contents would not be transferred to the server if text was selected in the VNC session and the middle mouse button was clicked in the viewer window without first bringing the window to the foreground.

27. Improved the zero-install Java Web Start feature in the following ways:

    • The built-in HTTP server in the TurboVNC Server now sends the "Content-Length" and "Last-Modified...

2.1.1

Assets

• turbovnc-2.1.1.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 1.5.1.

Support

Code Quality: Stable
Current Support Category: EOL

Documentation

User’s Guide for TurboVNC 2.1.1

Release Notes

Significant changes relative to 2.1:

1. Fixed an XML error ("The processing instruction target matching '[xX][mM][lL]' is not allowed" or "Could not parse launch file") that occurred when attempting to launch the Java TurboVNC Viewer using the built-in zero-install Java Web Start feature in the TurboVNC Server. Apparently recent releases of Java did not like the fact that the JNLP file generated by the TurboVNC Server began with an XML comment.

2. Arguments to the vncserver script are now case-insensitive.

3. The TurboVNC Server init.d script was erroneously checking for the existence of ~/.vnc/passwd, even if the permitted and selected security types did not require a VNC password file. The init.d script now invokes vncserver with a new argument (-quiet) that causes vncserver to fail if a VNC password file is required but does not exist.

4. The Java TurboVNC Viewer now supports the rfbTLS security descriptor used by Vino. This should allow the viewer to connect to encrypted Vino sessions using either the TLSVnc or TLSNone security types.

5. The default behavior of the TurboVNC Server is to refuse new non-shared connections if a viewer is already connected. Previously, the server accomplished this by hard-coding the -dontdisconnect argument to Xvnc inside of the vncserver wrapper script. This release of TurboVNC instead makes -dontdisconnect the default in Xvnc and introduces a new Xvnc argument (-disconnect) to reverse the behavior. This new option allows TurboVNC to mimic the behavior of other VNC implementations that disconnect existing viewers when a new non-shared connection is established.

6. Added a new parameter to the Java TurboVNC Viewer (LocalCursor) that, when enabled, causes cursor shape updates to be ignored and the local cursor to always be displayed. This mimics the behavior of the Windows TurboVNC Viewer when "Local cursor shape" is set to "Normal arrow" and "Mouse cursor" is set to "Don't show remote cursor". This option is useful when connecting to broken VNC server implementations that do not properly support server-side cursor rendering or cursor shape updates.

7. Fixed an issue in the Windows TurboVNC Viewer whereby the mouse scroll wheel would stop working if the viewer was moved to a monitor above or to the left of the Windows "main"/"primary" display.

8. Fixed an issue whereby zero-height PutImage requests (issued by XCB) would crash the TurboVNC X server. This was known to affect certain Qt5 applications running under Debian Stretch but may have also affected other applications and platforms.

2.1

Assets

• turbovnc-2.1.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 1.5.1.

Packaging Changes

• Fixed an issue whereby the TurboVNC Viewer JARs delivered via the TurboVNC Server's zero-install Java Web Start interface failed to launch ("com.sun.deploy.net.JARSigningException: Found unsigned entry in resource") with older JRE releases.

Support

Code Quality: Stable
Current Support Category: EOL

Documentation

User’s Guide for TurboVNC 2.1

Release Notes

Significant changes relative to 2.1 beta2:

1. Added a new parameter to the Java TurboVNC Viewer (LocalUsernameLC) that, when enabled along with the SendLocalUsername parameter, will cause the local username to be sent to the server in lowercase. This can be useful for Windows clients, since Windows allows mixed-case usernames but Un*x machines generally don't.

2. Fixed a regression introduced in 2.0 beta1[1] whereby connecting to the TurboVNC Server with cursor shape updates (client-side cursor rendering) enabled and continuous updates disabled (or with a viewer, such as the TurboVNC 1.1 Viewer, that doesn't support continuous updates) would cause the server and viewer to get into an infinite ping-pong loop whenever the cursor shape changed. This infinite loop caused TurboVNC to consume an inordinate amount of CPU and network resources until the next non-cursor-related framebuffer update was sent.

3. Fixed several serious visual artifacts with server-side cursor rendering (regression introduced in 2.0 beta1[1].) Server-side cursor rendering is not generally the default in TurboVNC, but it is useful for collaboration purposes.

4. Fixed an issue whereby the TurboVNC Server would become unresponsive to input if a viewer connected while the MATE screensaver was active.

5. The default xstartup.turbovnc script that the TurboVNC Server creates now includes a workaround for a bug in GNOME 3 whereby the pointer disappears when mousing over the top bar.

6. Fixed an issue in the Java TurboVNC Viewer whereby, when the remote desktop size was changed in the Options dialog, the new desktop size request was not sent to the server until the next framebuffer update was received.

7. Fixed an issue in the TurboVNC Server's implementation of the X RANDR extension that was causing viewer-initiated remote desktop resizes to fail or otherwise behave incorrectly with GNOME 3.

8. The TurboVNC Server now ignores remote desktop resize requests from viewers that authenticated with view-only credentials.

9. Fixed a regression introduced by 2.1 beta1[2] (but, for reasons unexplained, not exposed until 2.1 beta1[4]) whereby the TurboVNC Server, when built without TLS encryption, would sometimes segfault when a viewer disconnected. Oddly, this was not reproducible except on older platforms, such as RHEL 4.

10. Fixed a regression introduced in 2.1 beta1[2] whereby the TurboVNC Server, when built without TLS encryption, would fail to launch via the vncserver script and display the following error: "Unrecognized option: -x509cert".

11. Fixed an issue with the TurboVNC Server's 3D window manager feature that was known to affect Red Hat- and Ubuntu-compatible systems (and may have affected others as well.) When running vncserver with the -3dwm option, the window manager would behave as if VirtualGL was not active (thus causing the WM to crash, if it required OpenGL.) The underlying cause of this was code executed from within /etc/X11/xinit/xinitrc that launches the WM using ssh-agent if the SSH_AGENT_PID (Red Hat) or SSH_AUTH_SOCK (Ubuntu) environment variable is unset. ssh-agent clobbers the LD_PRELOAD environment variable, so in order to make it work properly with VirtualGL, vglrun has to be launched by ssh-agent, not vice versa.

    The default xstartup.turbovnc script that the TurboVNC Server creates now launches the window manager in VirtualGL and launches VirtualGL in ssh-agent if 3D window manager support is enabled and there is no existing ssh-agent session. Furthermore, the -3dwm option to vncserver now simply sets the TVNC_3DWM environment variable to 1 rather than invoking VirtualGL directly. The default xstartup.turbovnc script launches the WM in VirtualGL if that environment variable is set, using a second environment variable (TVNC_VGLRUN, which can be overridden by the user) to specify the VirtualGL command line. However, users can craft their own xstartup.turbovnc scripts that handle the TVNC_3DWM environment variable differently, if desired.

12. The default xstartup.turbovnc script that the TurboVNC Server creates will now properly launch the GNOME Flashback (Metacity) window manager on Ubuntu 16.04, if 3D window manager support is not activated. This eliminates the need to install MATE on that platform.

13. The default xtartup.turbovnc script that the TurboVNC Server creates now contains a fix for an issue whereby Unity 7.2 on Ubuntu 14 would automatically disable the compiz OpenGL plugin if the window manager was launched in a broken OpenGL environment (such as if the user forgot to specify -3dwm.) Symptomatically, this issue caused the menus and launcher to disappear, leaving only a blank desktop. When launching Unity, the xstartup.turbovnc script now attempts to create an environment similar to the one created by GDM or LightDM.

    This fix also allows Unity 7.4 under Ubuntu 16.04 to run in TurboVNC, if 3D window manager support is enabled.

14. The "OracleJava" TurboVNC package is now the default Mac package, since Oracle Java performs much better than Apple's (deprecated) Java distribution on OS X 10.10 "Yosemite" and later. Hence, the "OracleJava" suffix has been removed from that package. The "AppleJava" TurboVNC package is still provided, but it should only be used on OS X 10.9 and earlier.

15. Fixed a regression introduced in 2.1 beta1[2] whereby Xvnc would segfault if the -rfbauth argument was not specified and a viewer attempted to authenticate using a VNC password.

16. Dead keys should now fully work when using Java 8 or later on Windows and OS X. They still do not work properly when using Java 6 or Linux, due to bugs in Java.

17. Fixed two issues in the TurboVNC Viewer related to keyboard handling:

    • An issue whereby, when pressing Shift or AltGr, then pressing a "printable" (alphanumeric or symbol) key, then releasing the keys in the same order, the viewer would compute and send a different key symbol for the release event than it did for the press event (because the key was no longer modified.) This would confuse the XKEYBOARD handler in the server, which would ignore the release event, thus causing the printable key to appear pressed from the point of view of applications running in the TurboVNC session.
    • An issue whereby, when a key was pressed, the viewer window lost focus, then the key was released in another window, the key would similarly continue to appear pressed from the point of view of applications running in the TurboVNC session.

18. Fixed a regression in the standalone Linux TurboVNC Viewer caused by 2.1 beta1[4] (remote X Input support) whereby some X Input devices other than extended pointer devices (such as keyboards, regular mice, and webcams) were mistakenly being cloned onto the TurboVNC Server, thus causing erratic pointer behavior and other issues. Some devices (even some keyboards) seem to report that they are extended pointer devices when in fact they aren't. The TurboVNC Helper is now more discriminating and does not allow any X Input device whose type Atom is "MOUSE" or "KEYBOARD", or any device with relative valuators, to be cloned onto the server. The server now also rejects any attempt by the viewer to create an extended input device with relative valuators, since those don't currently work. Wacom tablets and other extended pointer devices with absolute valuators should still work fine.

19. Worked around an issue in Java that was causing scrollbars to be unnecessarily displayed in the Linux/Java TurboVNC Viewer when it was used under GNOME 3 with automatic desktop resizing enabled.

20. The Windows TurboVNC Viewer will now pass keystrokes from Microsoft extended keys to the VNC server when the keyboard is grabbed.

21. Fixed a regression introduced in 2.1 beta1[9] whereby the Linux TurboVNC Viewer and the Windows Java TurboVNC Viewer would throw a NullPointerException if the options were changed in the Options dialog prior to connecting to a VNC server. This issue occurred only in the standalone viewers, not when using Java Web Start.

2.0.91 (2.1 beta2)

Assets

• turbovnc-2.0.91.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 1.5 beta1. This improves encoding performance in the server by about 5-10% across the board, relative to TurboVNC 2.0.2.

Support

Code Quality: Beta
Current Support Category: EOL

Documentation

User’s Guide for TurboVNC 2.1 (Beta)

Release Notes

Significant changes relative to 2.1 beta1:

1. Fixed an issue in the Java TurboVNC Viewer whereby, when built against libjpeg-turbo 1.5 or later, it would generate the following error: "Class not found: org/libjpegturbo/turbojpeg/TJException" at run time and subsequently fail to accelerate JPEG decompression. TJException is a new class in libjpeg-turbo 1.5, and due to an oversight, VncViewer.jar was not including it.

Significant changes relative to 2.0.2:

1. The TurboVNC Server can now emulate a subset of the NV-CONTROL X11 extension, in order to support certain 3D applications that rely on this extension to query and set low-level nVidia GPU attributes. See the User's Guide for more details.

2. The TurboVNC Server now provides full support for the VeNCrypt RFB extensions, including TLS-encrypted security types. TLS encryption is provided by OpenSSL in the official TurboVNC binaries, but GnuTLS can be used instead when building the TurboVNC Server from source. Note that when using the Java TurboVNC Viewer, you must use 2.0.1 or later when connecting to a TurboVNC 2.1 server. Older versions of the Java TurboVNC Viewer had a bug that caused them to lock up when connecting to a server that supports both the Tight and VeNCrypt security extensions.

   Backward compatibility note: because of the addition of this feature, it was necessary to remove the -noauth, -novncauth, -nootp, and -nopam parameters to vncserver, because these parameters could not be emulated exactly using the new VeNCrypt security type selection mechanism. Please use the new -securitytypes parameter instead (see the Xvnc man page for more details.)

3. TurboVNC's vncserver script now supports the -autokill option from TigerVNC, which causes the server to be killed automatically whenever the startup script finishes (which will usually happen as the result of logging out of the window manager running in the TurboVNC session.) It was possible to accomplish the same thing in earlier versions of TurboVNC by running /opt/TurboVNC/bin/vncserver -fg </dev/null &, but this is more intuitive.

4. The TurboVNC Server and the Java TurboVNC Viewer (when the latter is run in standalone mode on Un*x/Linux machines, using the TurboVNC Helper library) now support a remote X Input interface whereby extended pointer devices (such as drawing tablets) on the client are cloned in the TurboVNC session, and the events from these devices (including pressure, tilt, etc.) are passed from viewer to server. This was specifically designed for Wacom tablets but should work with other extended pointer devices as well.

   Additionally, the Windows TurboVNC Viewer provides specific support for Wacom drawing tablets by interfacing between the Wacom drivers for Windows and the aforementioned remote X Input interface.

5. Keyboard grabbing has been implemented in the Java TurboVNC Viewer for Windows, thus allowing special keystrokes (such as Alt-Tab) to be sent to the server.

6. Added a new option to Xvnc (-pamsession) that will open a PAM session for every viewer that authenticates using the username/password of the user who owns the TurboVNC session and will leave that PAM session open until the viewer disconnects. This feature was specifically implemented in order to allow Kerberos tickets created by PAM to be reused within the TurboVNC session, but the feature may benefit other use cases as well.

7. Added a new parameter to the Java TurboVNC Viewer (NoReconnect) that can optionally be used to revert the behavior introduced in 2.0 beta1[17].

8. The controls in the Options dialog of the Windows (native) TurboVNC Viewer have been re-organized into two tabs ("Encoding" and "Connection"), which makes the layout of that dialog more similar to that of the Java viewer's Options dialog.

9. The keyboard/pointer grabbing feature can now be configured from the Options Dialog in both the Windows and Java TurboVNC Viewers.

10. Added a -poll option to tvncconfig, which works identically to the -poll option in RealVNC's (and TigerVNC's) vncconfig program. This causes tvncconfig to poll for changes to the clipboard at a specified interval rather than waiting for the X server to inform it of the changes.

11. The Windows TurboVNC Viewer package now includes a console version of the viewer (cvncviewer.exe), which is useful when debugging or when using the -via and -tunnel options. This version of the viewer is built by default when building TurboVNC on Windows, but it can be disabled by setting the TVNC_WINCONSOLE CMake variable to 0.

2.0.2

Assets

• turbovnc-2.0.2.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 1.4.2.

Support

Code Quality: Stable
Current Support Category: EOL

Documentation

User’s Guide for TurboVNC 2.0.2

Release Notes

Significant changes relative to 2.0.1:

1. The default xstartup.turbovnc script that the TurboVNC Server creates now includes unset DBUS_SESSION_BUS_ADDRESS. This fixes an issue whereby starting the TurboVNC Server from within an existing GNOME 2 (verified with GNOME 2.28.x and later) or MATE session would cause the GNOME/MATE session running in TurboVNC to fail with an error dialog: "Could not acquire name on session bus".

2. Fixed an issue whereby the TurboVNC Server would not properly handle Caps Lock when using the TurboVNC Viewer on OS X. X11 generates both a key press and a key release event when Caps Lock is toggled, but OS X generates a key press when Caps Lock is toggled on and a key release when it is toggled off. This was causing the Caps Lock state to become decoupled between client and server. The solution was to do what TigerVNC does and ignore Caps Lock (and other lock modifiers) on the server side, thus allowing the client to handle Caps Lock. If for some reason this causes problems, then the old behavior can be recovered by setting the TVNC_XKBIGNORELOCK environment variable to 0 prior to launching the TurboVNC Server.

3. Worked around an issue whereby the Java TurboVNC Viewer on Windows, when running under Java 7 and later, would take an inordinate amount of time to create the viewer window after connecting to a VNC server. This slowdown was due to a slow Win32 system call-- DescribePixelFormat()-- which is used in the implementation of GraphicsDevice.getConfigurations() in Windows JVMs. This system call also forces the DirectDraw DLL to be loaded, which is unnecessary (TurboVNC explicitly disables DirectDraw blitting for performance reasons.)

   The Java TurboVNC Viewer now automatically sets the sun.awt.nopixfmt system property to true, which should significantly speed up the creation of the viewer window, particularly on multi-screen clients, by avoiding the slow DescribePixelFormat() system call. This causes Java 2D to always use the default pixel format for the display, but since the TurboVNC Viewer will always try to use GDI blitting (as opposed to OpenGL or DirectDraw blitting), the default pixel format should always work. If for some reason it doesn't, however, then the old behavior of the Java TurboVNC Viewer can be restored by passing -Dsun.awt.nopixfmt=0 to java or adding -Dsun.awt.nopixfmt=0 to the JAVA_TOOL_OPTIONS environment variable.

4. "Dead" keys, which are used to add accents and other diacritics to subsequent alphabetic keystrokes, should now work properly when using the Windows TurboVNC Viewer. Additionally, certain AltGr-modified symbols (such as the Euro sign on European keyboards) did not previously work with the Windows TurboVNC Viewer. That has been fixed.

   Furthermore, dead keys should now mostly work when using the Java TurboVNC Viewer on Windows under Java 8 and later. Due to irregularities in how Java translates dead keys into events on other platforms (for instance, on OS X, Java uses a different key code for the press and release events of a particular dead key, and on Linux, Java only communicates release events for dead keys), dead key support on non-Windows platforms is still incomplete.

5. Fixed an issue in the Java TurboVNC Viewer whereby the Options, Clipboard, and Profiling dialogs were not centered relative to the viewer window.

6. Fixed an issue in the TurboVNC Server (Xvnc) whereby, when running a compositing window manager such as Gnome 3, activity in off-screen windows (such as a scrolling xterm being displayed in a separate workspace) could interfere with the display of on-screen windows that occupied the same screen area as the off-screen windows.

7. The Windows TurboVNC Viewer will now resolve localhost to the IPv4 loopback address (127.0.0.1) by default unless the /ipv6 option is specified. This makes its behavior more consistent with the Java viewer (NOTE: connecting to localhost on a Windows machine is an unusual case, but it can occur when using virtualization software that has a built-in VNC server.)

8. Improved the parsing of display names in both TurboVNC viewers. In particular, the Windows viewer now properly parses the following display name forms:

   • :n (same as localhost:n)
   • ::port (same as localhost::port)
   • x:x:x::x:n (abbreviated IPv6 address)
   • x:x:x::x::port (abbreviated IPv6 address)
   • x:x:x:x:x:x:x:x:n (full IPv6 address)
   • [IPv6]:n (IPv6 address in brackets)
   • [IPv6]::port (IPv6 address in brackets)

   Both viewers now properly parse the following display name forms:

   • x:x:x::x (abbreviated IPv6 address, same as x:x:x::x:0)
   • [IPv6] (IPv6 address in brackets, same as [IPv6]:0)

9. The Windows TurboVNC Viewer should now build with Visual C++ 2015.

10. Fixed an issue in the Java TurboVNC Viewer whereby the viewer, when using the "server" (manual) remote desktop resizing mode, would unnecessarily display two scrollbars if one of the remote desktop dimensions was too large for the local display but the other dimension wasn't.

2.0.90 (2.1 beta1)

Assets

• turbovnc-2.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 1.5 beta1. This improves encoding performance in the server by about 5-10% across the board, relative to TurboVNC 2.0.2.

Support

Code Quality: Beta
Current Support Category: EOL

Documentation

User’s Guide for TurboVNC 2.1 (Beta)

Release Notes

Significant changes relative to 2.0.2:

1. The TurboVNC Server can now emulate a subset of the NV-CONTROL X11 extension, in order to support certain 3D applications that rely on this extension to query and set low-level nVidia GPU attributes. See the User's Guide for more details.

2. The TurboVNC Server now provides full support for the VeNCrypt RFB extensions, including TLS-encrypted security types. TLS encryption is provided by OpenSSL in the official TurboVNC binaries, but GnuTLS can be used instead when building the TurboVNC Server from source. Note that when using the Java TurboVNC Viewer, you must use 2.0.1 or later when connecting to a TurboVNC 2.1 server. Older versions of the Java TurboVNC Viewer had a bug that caused them to lock up when connecting to a server that supports both the Tight and VeNCrypt security extensions.

   Backward compatibility note: because of the addition of this feature, it was necessary to remove the -noauth, -novncauth, -nootp, and -nopam parameters to vncserver, because these parameters could not be emulated exactly using the new VeNCrypt security type selection mechanism. Please use the new -securitytypes parameter instead (see the Xvnc man page for more details.)

3. TurboVNC's vncserver script now supports the -autokill option from TigerVNC, which causes the server to be killed automatically whenever the startup script finishes (which will usually happen as the result of logging out of the window manager running in the TurboVNC session.) It was possible to accomplish the same thing in earlier versions of TurboVNC by running /opt/TurboVNC/bin/vncserver -fg </dev/null &, but this is more intuitive.

4. The TurboVNC Server and the Java TurboVNC Viewer (when the latter is run in standalone mode on Un*x/Linux machines, using the TurboVNC Helper library) now support a remote X Input interface whereby extended pointer devices (such as drawing tablets) on the client are cloned in the TurboVNC session, and the events from these devices (including pressure, tilt, etc.) are passed from viewer to server. This was specifically designed for Wacom tablets but should work with other extended pointer devices as well.

   Additionally, the Windows TurboVNC Viewer provides specific support for Wacom drawing tablets by interfacing between the Wacom drivers for Windows and the aforementioned remote X Input interface.

5. Keyboard grabbing has been implemented in the Java TurboVNC Viewer for Windows, thus allowing special keystrokes (such as Alt-Tab) to be sent to the server.

6. Added a new option to Xvnc (-pamsession) that will open a PAM session for every viewer that authenticates using the username/password of the user who owns the TurboVNC session and will leave that PAM session open until the viewer disconnects. This feature was specifically implemented in order to allow Kerberos tickets created by PAM to be reused within the TurboVNC session, but the feature may benefit other use cases as well.

7. Added a new parameter to the Java TurboVNC Viewer (NoReconnect) that can optionally be used to revert the behavior introduced in 2.0 beta1[17].

8. The controls in the Options dialog of the Windows (native) TurboVNC Viewer have been re-organized into two tabs ("Encoding" and "Connection"), which makes the layout of that dialog more similar to that of the Java viewer's Options dialog.

9. The keyboard/pointer grabbing feature can now be configured from the Options Dialog in both the Windows and Java TurboVNC Viewers.

10. Added a -poll option to tvncconfig, which works identically to the -poll option in RealVNC's (and TigerVNC's) vncconfig program. This causes tvncconfig to poll for changes to the clipboard at a specified interval rather than waiting for the X server to inform it of the changes.

11. The Windows TurboVNC Viewer package now includes a console version of the viewer (cvncviewer.exe), which is useful when debugging or when using the -via and -tunnel options. This version of the viewer is built by default when building TurboVNC on Windows, but it can be disabled by setting the TVNC_WINCONSOLE CMake variable to 0.

2.0.1

Assets

• turbovnc-2.0.1.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 1.4.2.

Support

Code Quality: Stable
Current Support Category: EOL

Documentation

User’s Guide for TurboVNC 2.0.1

Release Notes

Significant changes relative to 2.0:

1. When using an external SSH client with the Via or Tunnel parameters, the Java TurboVNC Viewer was not passing the SSH username to the external SSH client, which caused SSH authentication to fail unless the remote and local usernames were the same. This has been fixed.

2. Fixed an issue whereby the TurboVNC X server was erroneously generating X11 MotionNotify events every time a mouse button was pressed or released, regardless of whether the pointer had actually moved. This caused problems with certain applications (for instance, in GNOME Terminal, text was selected when single-clicking on it rather than double-clicking or click-dragging on it.)

3. The /desktopsize server option now works properly with the Windows TurboVNC Viewer.

4. Fixed an issue that prevented VeNCrypt authentication from working in the Java TurboVNC Viewer when connecting to a server that supports both the TightVNC and VeNCrypt security extensions.

5. Improved the GUI for specifying the X.509 CA certificate and CRL in the Java viewer, and added new command-line/applet parameters (X509CA and X509CRL) that can be used to specify these files without using the GUI.

6. The Java viewer will now report an error if one of the security types specified in the SecurityTypes parameter is invalid. This prevents hard-to-diagnose issues (such as authentication errors or the wrong security type being selected) if one of the security types is misspelled.

7. The TightVNC/TurboVNC-specific "Unix Login" authentication scheme can now be enabled/disabled by using the Java TurboVNC Viewer's SecurityTypes parameter, similarly to other authentication schemes and VeNCrypt security types. Furthermore, the NoUnixLogin parameter now disables the VeNCrypt *Plain security types as well as the Unix Login security type, and the User and SendLocalUserName parameters now disable any of the VeNCrypt security types that don't require a username.

8. The Java TurboVNC Viewer now supports (and prefers) elliptic curve ciphers when using the Anonymous TLS security types. Additionally, the Java TurboVNC Viewer now uses TLS v1.1+ by default instead of TLS v1.0.

9. Improvements to the handling of X.509 certificates in the Java TurboVNC Viewer:

   • Fixed a NullPointerException that would occur when attempting to use one of the X.509 security types without specifying an X.509 certificate authority (CA) certificate.
   • If the server's certificate is signed by an unknown CA, then the viewer will pop up a dialog that gives the user the option to trust the certificate for future connections.
   • The viewer can now handle X.509 certificate files containing multiple concatenated certificates.
   • The viewer now performs hostname verification using either the X.509 v3 subjectAltName (SAN) extension or, if SAN is not present, the subject CN field.

10. When entering full-screen mode or using the "Default Window Size/Position" feature in the TurboVNC Viewer (both Java and Windows), the viewer will now use the monitor containing the largest number of pixels from the viewer window as the "primary" monitor, for the purposes of spanning. Thus, if the viewer window is mostly contained on a monitor other than the left/top one, entering full-screen mode or setting the window to the default size/position will no longer cause the window to jump to the left/top monitor.

    OS X Yosemite introduced an optional feature (enabled by default) called "Spaces", whereby each monitor occupies its own independent space when in full-screen mode (thus allowing full-screen mode to be enabled independently on each monitor.) Previously, when this feature was enabled, moving the TurboVNC Viewer window to a monitor other than the left/top one and entering full-screen mode would result in a black screen. This bug fix allows Primary spanning to work properly with Spaces, but note that no other spanning mode will work properly unless the Spaces feature is disabled.

    Both viewers contain a new command-line option/parameter (-firstmonitorisprimary for the Windows viewer, CurrentMonitorIsPrimary=0 for the Java viewer) that allows the previous behavior (always treating the left/top monitor as the primary) to be restored.

11. The Java TurboVNC Viewer now supports the BGR555 pixel format, which is reported to be necessary when connecting to some embedded devices.

12. The Java TurboVNC Viewer now encodes the clipboard as ISO-8859-1 when sending it to the server, instead of UTF-8. The RFB spec requires that the clipboard be encoded as ISO-8859-1, so it is possible that attempting to encode it as UTF-8 was causing problems with certain applications.

13. The TurboVNC Server now allows the maximum clipboard transfer size to be specified, by way of a new Xvnc argument (-maxclipboard). Previously the limit was hard-coded to 1 MB. Furthermore, the TurboVNC Server now truncates clipboard updates larger than the max. clipboard size instead of ignoring them.

14. The Java TurboVNC Viewer now allows the maximum clipboard transfer size to be specified, by way of a new parameter (MaxClipboard). The Java TurboVNC Viewer now also truncates any clipboard transfers greater than MaxClipboard (which is set to 1 MB by default.) This prevents the viewer from sending clipboard data to the server that will ultimately be discarded.

2.0

Assets

• turbovnc-2.0.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 1.4.1. This improves performance on 64-bit Mac clients, relative to TurboVNC 2.0 beta1.

Support

Code Quality: Stable
Current Support Category: EOL

Documentation

User’s Guide for TurboVNC 2.0

Release Notes

Significant changes relative to 2.0 beta1:

1. A new security configuration file directive (no-httpd) has been introduced in order to disable the built-in HTTP server in the TurboVNC Server on a system-wide basis.

2. A new security configuration file directive (no-x11-tcp-connections) has been introduced in order to disable X11 TCP connections to the TurboVNC Server on a system-wide basis. This is the equivalent of passing -nolisten tcp to every instance of the TurboVNC X server running on a particular host.

3. The Java TurboVNC Viewer now supports the grabkeyboard, resizemode, desktopwidth, and desktopheight directives in .vnc connection info files. These directives were added to the Windows TurboVNC Viewer in 2.0 beta but were left out of the Java viewer due to an oversight.

4. The default xstartup.turbovnc script that the TurboVNC Server creates will now launch the MATE desktop on Ubuntu 15, if it is installed and if 3D window manager support is not activated. The GNOME Flashback session under Ubuntu 15 cannot be made to work properly with TurboVNC, for unknown reasons, but MATE is a better solution anyhow.

5. The drawing performance of the Java TurboVNC Viewer when running under Oracle Java 7 and later on OS X has been dramatically improved (by 3-7x for 2D application workloads and 35-50% for 3D application workloads.) When running the standalone TurboVNC Viewer, Apple Java will probably still perform better on Macs running OS X 10.9 "Mavericks" and earlier, but on Macs running OS X 10.10 "Yosemite" and later, Oracle Java is now the fastest solution (Java 2D is apparently not accelerated in Apple Java 6 on these more recent OS X releases.) See the User's Guide for more details.

6. Fixed an issue whereby pressing any of the extra buttons on mice with more than 3 buttons (Microsoft calls these "X buttons") would cause the Java TurboVNC Viewer to send a left button press event to the TurboVNC Server without sending a corresponding button release event. The Java TurboVNC Viewer now ignores any X button events, since X11 doesn't support them.