Name | Modified | Size | Downloads / Week |
---|---|---|---|
Parent folder | |||
turbovnc-2.1.2.src.rpm | 2017-09-25 | 5.8 MB | |
turbovnc-2.1.2.tar.gz.sig | 2017-09-25 | 65 Bytes | |
turbovnc-2.1.2.tar.gz | 2017-09-25 | 5.8 MB | |
turbovnc_2.1.2_i386.deb | 2017-09-25 | 4.2 MB | |
turbovnc_2.1.2_amd64.deb | 2017-09-25 | 4.3 MB | |
turbovnc-debuginfo-2.1.2.x86_64.rpm | 2017-09-25 | 7.1 MB | |
turbovnc-debuginfo-2.1.2.i386.rpm | 2017-09-25 | 7.0 MB | |
turbovnc-2.1.2.x86_64.rpm | 2017-09-25 | 4.1 MB | |
turbovnc-2.1.2.i386.rpm | 2017-09-25 | 4.0 MB | |
TurboVNC64-2.1.2.exe | 2017-09-25 | 2.5 MB | |
turbovnc-2.1.2-jws.zip | 2017-09-25 | 103.9 kB | |
TurboVNC-2.1.2.exe | 2017-09-25 | 2.4 MB | |
TurboVNC-2.1.2.dmg | 2017-09-25 | 2.1 MB | |
TurboVNC-2.1.2-AppleJava.dmg | 2017-09-25 | 2.1 MB | |
README.md | 2017-09-25 | 11.4 kB | |
Totals: 15 Items | 51.5 MB | 0 |
These packages were built with libjpeg-turbo 1.5.2:
http://sourceforge.net/projects/libjpeg-turbo/files/1.5.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.1.2
Significant changes relative to 2.1.1:
-
Improved the usability of multithreaded Tight encoding in the TurboVNC Server:
- The
TVNC_MT
andTVNC_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 server, 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.
- The
-
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.
-
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.
-
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 Server session using PAM User/Password Authentication, if the user ACL feature was disabled.
-
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}
.) -
Fixed an issue whereby the TurboVNC Server could not be built using GnuTLS 3.4.0 or later.
-
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 client 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.
-
Fixed an issue in the Mac (Java) TurboVNC Viewer whereby the initial non-full-screen window was positioned incorrectly if it spanned multiple screens.
-
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.
-
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.
-
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.
- 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
-
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. -
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.
-
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. -
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.
-
The Java/Mac/Un*x TurboVNC Viewer now supports the
user
andnoremotecursor
directives in .vnc connection info files. -
Fixed an issue that prevented the keyboard grabbing feature from working properly in the Java TurboVNC Viewer on 32-bit Windows systems.
-
Fixed an issue whereby, when server-side cursor rendering was enabled, the cursor would flicker on and off as the mouse was dragged.
-
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. -
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. -
The default xstartup.turbovnc script that the TurboVNC Server creates now sets the
XDG_SESSION_TYPE
environment variable tox11
. This is necessary when running GNOME 3 on Fedora 25 and later. Otherwise, GNOME 3 will assume it is operating in a Wayland environment. -
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.
-
Fixed a bug in the X.org code that prevented the TurboVNC Server from working properly on little endian PowerPC systems.
-
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.
-
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.
-
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 server session and the middle mouse button was clicked in the viewer window without first bringing the window to the foreground.
-
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" HTTP headers. These headers are used by Java Web Start to determine whether the server's copy of the TurboVNC Viewer JAR is newer than the client's copy, and the addition of the headers prevents an issue whereby Java Web Start would never update the cached copy of the TurboVNC Viewer JAR on the client.
- The JNLP file generated by the TurboVNC Server now contains directives that disable background updating of the TurboVNC Viewer JAR. Under certain circumstances, background updating was causing the TurboVNC Server to become unresponsive, since it is running the VNC, X11, and HTTP servers in the same thread.
-
Worked around an issue in OS X whereby the TurboVNC Viewer window would not be brought to the foreground if a mouse button other than the primary button was clicked in it. Because OS X sends only mouse press events to non-foreground windows, this issue was causing mouse buttons other than the primary button to become stuck in the pressed state on the server if one of those buttons was clicked in the viewer window while the window was in the background.
-
Fixed an issue in the TurboVNC Server whereby it would hang and eventually time out when attempting to negotiate VeNCrypt capabilities with the viewer. This issue was known to affect only Solaris 11 servers, but it might have also affected other platforms under rare circumstances.
-
Worked around an issue in Java that caused Control-Underscore (the keyboard shortcut for the Undo command in Emacs) to be transmitted incorrectly when using the Java TurboVNC Viewer. Worked around another issue in Java that caused AltGr symbols associated with a dead key (for instance, the '|' symbol on Danish keyboards) to be transmitted incorrectly.