The interactive file manager requires Javascript. Please enable it or use sftp or scp.
You may still browse the files here.

Home / 2.1
Name Modified Size InfoDownloads / Week
Parent folder
README.md 2017-04-05 9.0 kB
turbovnc_2.1_i386.deb 2017-04-05 4.2 MB
turbovnc_2.1_amd64.deb 2017-04-05 4.2 MB
turbovnc-debuginfo-2.1.x86_64.rpm 2017-04-05 7.1 MB
turbovnc-debuginfo-2.1.i386.rpm 2017-04-05 7.0 MB
turbovnc-2.1.src.rpm 2017-04-05 5.7 MB
turbovnc-2.1.x86_64.rpm 2017-04-05 4.1 MB
turbovnc-2.1.i386.rpm 2017-04-05 4.0 MB
turbovnc-2.1.tar.gz.sig 2016-09-23 72 Bytes
turbovnc-2.1.tar.gz 2016-09-21 5.7 MB
TurboVNC64-2.1.exe 2016-09-21 2.5 MB
TurboVNC-2.1.exe 2016-09-21 2.4 MB
TurboVNC-2.1.dmg 2016-09-21 2.1 MB
TurboVNC-2.1-AppleJava.dmg 2016-09-21 2.1 MB
Totals: 14 Items   51.1 MB 2

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

Packaging changes

A new build of the Linux RPMs and DEBs was uploaded on 2017-04-05 to fix 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.

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.1

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 user name to be sent to the server in lowercase. This can be useful for Windows clients, since Windows allows mixed-case user names 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 client 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 Server 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 Server 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.

Source: README.md, updated 2017-04-05