These packages were built with libjpeg-turbo 1.4.2:
http://sourceforge.net/projects/libjpeg-turbo/files/1.4.2/

Package signatures

To ensure the integrity of the TurboVNC binary packages, the RPM and DEB files and the source tarball are signed using the following key:
http://www.TurboVNC.org/key/VGL-GPG-KEY-1024
http://pgp.mit.edu/pks/lookup?op=get&search=0x6BBEFA1972FEB9CE
and the Windows installers are signed using a code signing certificate.

2.0.2

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.