These packages were built with libjpeg-turbo 2.0.0:
https://sourceforge.net/projects/libjpeg-turbo/files/2.0.0/
Relative to VirtualGL 2.5.x, this reduces the CPU usage of the VGL Transport (with JPEG compression) when using an AVX2-capable CPU.

Packaging changes

New builds of VirtualGL-2.6.x86_64.rpm and virtualgl_2.6_amd64.deb were uploaded on 2019-04-11 to fix an issue (caused by an oversight in the Docker image used to perform official VirtualGL builds) whereby the official x86-64 VirtualGL binaries depended on libstdc++.so.6.

Package signatures

To ensure the integrity of the VirtualGL binary packages, the RPM and DEB files and the source tarball are signed using the following key:
https://www.VirtualGL.org/key/VGL-GPG-KEY-1024
https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xecf01671d05e2a105ff84dc46bbefa1972feb9ce
and the Windows installers are signed using a code signing certificate.

Cygwin

Use the vglcygsetup script to install or update the VirtualGL Client for Cygwin.

2.6

Significant changes relative to 2.6 beta1:

1. Fixed an issue whereby the modifications that vglserver_config made to lightdm.conf sometimes caused vglgenkey to be executed multiple times. This was known to cause problems with remote login methods, such as XDMCP, and it also caused LightDM on Ubuntu 18.04 to lock up when logging in locally.

2.5.90 (2.6 beta1)

Significant changes relative to 2.5.2:

1. VirtualGL began handling WM_DELETE_WINDOW protocol messages in version 2.1.3 as a way of avoiding BadDrawable errors that would occur if the 3D application was closed by the window manager (using the window's close gadget, for instance) and the application did not handle WM_DELETE_WINDOW messages itself. VirtualGL throws the following error if such a situation occurs:

   [VGL] ERROR: in {method}--
   [VGL]    {line}: Window has been deleted by window manager
   

   However, this error was also thrown erroneously by VirtualGL if a 3D application handled WM_DELETE_WINDOW messages but did not subsequently shut down its X11 event queue. This was known to affect GLFW applications but likely affected other applications as well. To address this problem, VirtualGL now ignores WM_DELETE_WINDOW messages if it detects that the 3D application is handling them.

2. Fixed an issue whereby the VGL logo would be drawn incorrectly or the 3D application would segfault if the OpenGL window was smaller than 74x29, VGL_LOGO was set to 1, and quad-buffered stereo was enabled.

3. Fixed an issue whereby the glxinfo utility included in the VirtualGL packages would fail with a GLXBadContext error when used in an indirect OpenGL environment.

4. VirtualGL can now be used with depth=30 (10-bit-per-component) visuals and FB configs, if both the 2D and 3D X servers support them. Currently this only works with the X11 Transport, since other transports do not (yet) have the ability to transmit and display 30-bit pixels. Furthermore, anaglyphic stereo does not work with this feature.

5. Worked around a segfault in Mayavi2 (and possibly other VTK applications) when using nVidia's proprietary drivers. VirtualGL's implementation of glXGetVisualFromFBConfig() always returned a TrueColor X visual, regardless of the GLXFBConfig passed to it. From VirtualGL's point of view, this was correct behavior, because VGL always converts the rendered 3D pixels to TrueColor when reading them back. However, some use cases in VTK assume that there is a 1:1 correspondence between X visuals and GLX FB configs, which is not the case when using VirtualGL. Thus, VGL's implementation of glXGetVisualFromFBConfig() was causing VTK's visual matching algorithm to always select the last FB config in the list, and when using nVidia hardware, that FB config usually describes an esoteric floating point pixel format. When VTK subsequently attempted to create a context with this FB config and make that context current, VirtualGL's internal call to glXMakeContextCurrent() failed. VGL passed this failure status back to VTK in the return value of glXMakeCurrent(), but VTK ignored it, and the lack of a valid context led to a subsequent segfault when VTK tried to call glBlendFuncSeparate(). VirtualGL's implementation of glXGetVisualFromFBConfig() now returns NULL unless the FB config has a corresponding visual on the 3D X server.

6. VirtualGL can now be built and run with OpenSSL 1.1.

7. The VGL Transport now works properly with IPv6 sockets. When -ipv6 is passed to vglconnect, or the VGLCLIENT_IPV6 environment variable is set to 1, the VirtualGL Client will accept both IPv4 and IPv6 connections.

8. Worked around a segfault that would occur, when using VirtualGL with the non-GLVND-enabled proprietary nVidia OpenGL stack, if an OpenGL application called glXDestroyContext() to destroy an active OpenGL context in which the front buffer was the active drawing buffer, then the application called glXMake[Context]Current() to swap in another context. Under those circumstances, VirtualGL will read back the front buffer within the body of the interposed glXMake[Context]Current() function, in order to transport the contents of the last frame rendered to the buffer. Since VirtualGL temporarily swaps in its own OpenGL context prior to reading back the buffer, then swaps the application's OpenGL context back in after the readback, VirtualGL was passing a dead context to nVidia's glXMake[Context]Current() function, which triggered the segfault. Arguably nVidia's glXMake[Context]Current() implementation should have instead thrown a GLXBadContext error, but regardless, VirtualGL now verifies that the application's OpenGL context is alive before swapping it back in following a readback. This issue was known to affect ParaView but may have affected other applications as well.