virtualgl-announce — VirtualGL Announcements (moved to Google Groups-- see http://www.VirtualGL.org/About/MailingLists)

[VirtualGL-Announce] VirtualGL and TurboVNC mailing lists have moved to Google Groups

[DRC <dco...@us...>]

SourceForge removed the ability for project admins to view/manage the
members of mailing lists, which was the final straw.  Given that there
is some cross-pollination between our projects and TigerVNC, and
TigerVNC is using Google Groups, I decided to do likewise with both
VirtualGL and TurboVNC.  You can join the new groups either using a
Google account (which gives you full access to the group from the web
interface) or a non-Google e-mail address (which gives you access to
post from e-mail only.)  Links for joining all of the groups can be
found here:

http://www.virtualgl.org/About/MailingLists
http://www.turbovnc.org/About/MailingLists

(Note that you have to be logged in with a Google account in order to
join with that account.)

To unsubscribe from the old lists, visit one or more of the following URLs:
https://sourceforge.net/projects/virtualgl/lists/virtualgl-announce/unsubscribe
https://sourceforge.net/projects/virtualgl/lists/virtualgl-users/unsubscribe
https://sourceforge.net/projects/virtualgl/lists/virtualgl-devel/unsubscribe
https://sourceforge.net/projects/turbovnc/lists/turbovnc-announce/unsubscribe
https://sourceforge.net/projects/turbovnc/lists/turbovnc-users/unsubscribe
https://sourceforge.net/projects/turbovnc/lists/turbovnc-devel/unsubscribe

The direct addresses for e-mailing the new groups are:
vir...@go...
vir...@go...
tur...@go...
tur...@go...

Other notes:
-- If you join with a non-Google e-mail address, Google makes you go
through a really annoying Turing test.  I apologize in advance for that.
-- The old mailing lists will be retained on SourceForge for archival
purposes, but they are no longer linked from our SourceForge project
pages.  To view the archives, visit the links on VirtualGL.org and
TurboVNC.org (see above.)
-- The new mailing lists have already been added to mail-archive.com.
-- The new lists are public (anyone can join or view the messages), but
the subscriber lists are visible only to me.
-- As with the existing lists, only members can post (and only I can
post to the announcement lists.)
-- The new lists are configured such that your Google profile will not
be revealed if you post.  Only your chosen display name will be shown.

Reminders:
-- If a topic is specific to TurboVNC and does not necessarily involve
VirtualGL, then please use one of the TurboVNC lists to discuss that topic.
-- We also have a Facebook group (https://www.facebook.com/VirtualGL)
and a LinkedIn group (https://www.linkedin.com/groups/3182945) that
receive release announcements.  You can also use those groups to post
questions and concerns.

Please e-mail me directly (http://www.virtualgl.org/About/Contact) or
post a GitHub tracker issue
(https://github.com/VirtualGL/virtualgl/issues/new or
https://github.com/TurboVNC/turbovnc/issues/new) should you have any
questions, concerns, or problems subscribing to the new lists.

The old lists will be closed to new messages shortly, so please transfer
your subscriptions immediately.

DRC

[VirtualGL-Announce] VirtualGL 2.5.2 has been released

[DRC <dco...@us...>]

Official binaries and source tarball are here:

https://sourceforge.net/projects/virtualgl/files/2.5.2/

Change log is here:

https://github.com/VirtualGL/virtualgl/releases/tag/2.5.2/

[VirtualGL-Announce] TurboVNC and VirtualGL continuous integration systems are now online

[DRC <dco...@us...>]

We are now spinning continuous "official" pre-release builds from the
VirtualGL master (2.5.x) branch and the TurboVNC master (2.1.x) and dev
(2.2.x) branches, using Travis and AppVeyor.  Refer to:

http://www.virtualgl.org/DeveloperInfo/PreReleases
and
http://www.turbovnc.org/DeveloperInfo/PreReleases

for more information.  There are not many notable changes in the
TurboVNC dev branch yet, but the TurboVNC dev pre-release builds
incorporate the evolving version of libjpeg-turbo 1.6, so they include
the AVX2 SIMD work that has been done thus far (which should make those
builds significantly faster on recent CPUs.)

DRC

[VirtualGL-Announce] Web site outage

[DRC <dco...@us...>]

The hosting provider for the VirtualGL, TurboVNC, and libjpeg-turbo web
sites is currently down for unknown reasons (but probably related to the
large DDoS attack that is taking place in the U.S. today.)  Everything
on those sites was backed up last night.  All other project services are
functioning properly.

DRC

[VirtualGL-Announce] VirtualGL 2.5.1 has been released

[DRC <dco...@us...>]

Official binaries and source tarball are here:

https://sourceforge.net/projects/virtualgl/files/2.5.1/

Change log is here:

https://github.com/VirtualGL/virtualgl/releases/tag/2.5.1

[VirtualGL-Announce] VirtualGL 2.5 has been released

[DRC <dco...@us...>]

Files:
https://sourceforge.net/projects/virtualgl/files/2.5/

Changes relative to 2.5 beta1:

1. OS X 10.11 "El Capitan" no longer allows packages to install files
under /usr/bin, and this was preventing the VirtualGL binary package for
OS X from installing on that platform. The symlinks to vglclient and
vglconnect that the OS X package previously installed under /usr/bin
have thus been removed in this version of VirtualGL. It will therefore
be necessary to invoke vglconnect and vglclient using the full pathname
(/opt/VirtualGL/bin/vglconnect or /opt/VirtualGL/bin/vglclient) or to
add /opt/VirtualGL/bin to the PATH.

2. Fixed a regression introduced by 2.5 beta1[13] that caused certain
system commands (such as uname, hostname, etc.) to crash when running
those commands using vglrun on current Arch Linux spins (glibc 2.22, GCC
5.2.) This possibly affected other non-OpenGL, non-X11 applications on
other bleeding-edge Linux distributions as well.

3. vglserver_config should now work properly with MDM (MATE Display
Manager), if its config files are installed in the standard location
(/etc/mdm).

4. Fixed a regression introduced in 2.4 that caused vglrun to abort with
"VGL_ISACTIVE=1: is not an identifier" when running on Solaris 10 (or
other systems in which /bin/sh doesn't support "export VAR=value" syntax.)

5. Fixed a regression introduced by 2.5 beta1[3] whereby the VirtualGL
faker would segfault on Solaris if the 3D application called one of the
GLX/OpenGL functions that VirtualGL interposes and the underlying OpenGL
library (libGL) did not implement that function.

[VirtualGL-Announce] VirtualGL 2.5 beta1 has been released

[DRC <dco...@us...>]

Official binaries are available here:
https://sourceforge.net/projects/virtualgl/files/2.4.90%20%282.5beta1%29/

Changelog is available here:
https://github.com/VirtualGL/virtualgl/releases/tag/2.5beta1

[VirtualGL-Announce] Signed binaries

[DRC <dco...@us...>]

All of the VirtualGL binaries back to 2.3 have been digitally signed.

See

http://www.virtualgl.org/Downloads/DigitalSignatures

for instructions on how to verify the signatures.

[VirtualGL-Announce] VirtualGL code migration to GitHub is complete

[DRC <dco...@us...>]

I'm not sure whether all of my previous messages regarding the 
SourceForge outage got through, so forgive me if any of this is old news.

Let me start by saying that I think (hope) that the rumors of 
SourceForge's demise have been greatly exaggerated.  They have largely 
owned up to their mistakes regarding the DevShare program and have taken 
steps to mitigate misleading ads (i.e. ads with fake download buttons) 
that were being served up by Google.  I also feel that they handled this 
outage in the best way they could.  I've been using SourceForge since 
2004-- you know, back when they were in pretty much exactly the same 
position that GitHub is in now.  I've been around this block enough 
times to be wary of jumping onto the latest & greatest platform just 
because it's the latest & greatest.

That being said, while I have had no major issues with SourceForge 
(before now), this outage made me finally admit that the advantages of a 
DVCS (such as git) far outweigh the pain of learning a new system.  To 
that end, I took advantage of the downtime to get familiar enough with 
Git that I can be productive with it.  When our subversion repository 
came back online on Sunday, I immediately started the (somewhat 
painstaking) task of migrating our code to GitHub.  I could just as 
easily have migrated it to SourceForge's Git or Hg servers, but I am a 
believer in using the best tool for the job.  Part of maintaining a 
healthy open source community is making it easy for developers to 
contribute, and GitHub's popularity and rich collaboration tools make it 
a clear winner in that department.

The code migration is now complete, and you can find our main repository at:
https://github.com/VirtualGL/virtualgl

Supporting repositories (build scripts, etc.) can be found at
https://github.com/VirtualGL

Please update any sandboxes you may have.  The subversion repository is 
frozen and will eventually be decommissioned.

The following provides a comprehensive list of project services and 
where to find them, going forward:

-- Code hosting:  GitHub only (https://github.com/VirtualGL/virtualgl)
    I double-checked and triple-checked the new repository against the 
old, but please let me know if you find any issues with it.

-- Issue/feature tracking:  Either GitHub 
(https://github.com/VirtualGL/virtualgl/issues) or SourceForge 
(https://sourceforge.net/p/virtualgl/_list/tickets)
    There are advantages and disadvantages to both (for instance, you 
can't attach files with GitHub), so for the time being at least, use 
whichever one you prefer.  I have moved the open feature requests to 
GitHub, but all other items are still on SourceForge.  If, at some point 
in the future, the SourceForge tracker stops being used or the GitHub 
tracker improves its feature set, I will consider freezing the SF tracker.

-- Patches:  Either GitHub 
(https://github.com/VirtualGL/virtualgl/pulls) or SourceForge 
(https://sourceforge.net/p/virtualgl/patches/)
    If, at some point in the future, the SourceForge tracker stops being 
used, I will consider freezing it.

-- Official Releases:  SourceForge 
(https://sourceforge.net/projects/virtualgl/files/)
    My automated pre-release and release scripts are heavily tied to the 
SourceForge file release system, I like certain features of that system 
(such as the statistics it provides), and there are a lot of links to 
those files out there, so at least for now, I will continue using 
SourceForge to distribute official releases.  I will, however, sign all 
RPMs and DEBs on that site with my GPG key and all Windows installers 
with my code signing certificate, in order to ease any concerns about 
binary tampering.  Look for a follow-up message announcing the 
completion of that project (SourceForge has not yet restored the file 
upload and SSH features, so access to the file release system is 
currently read-only.)
    This article 
http://michaeltunnell.com/blog/15-miscellaneous/53-14-potential-alternatives-to-sourceforge-for-binary-downloads 
echoes my thoughts on the decision to stick with SF for file releases.
    Note that GitHub includes metadata and automatically-generated 
tarballs for all of the release tags 
(https://github.com/VirtualGL/virtualgl/releases.)  For VirtualGL 2.0 
and newer, these tarballs should match the ones on SourceForge (the 
pre-2.0 tarballs on GitHub are missing the license files, due to an 
issue with the old CVS repository that was never resolved prior to 
converting it to subversion.)

-- Web site:  hosted on an external web server (http://www.VirtualGL.org)
    All of the links mentioned in this message can be found there.

-- Mailing lists:  SourceForge 
(https://sourceforge.net/p/virtualgl/mailman/)

-- Discussion forums:  SourceForge 
(https://sourceforge.net/p/virtualgl/discussion/)


As always, please send me any questions or concerns you may have.

DRC

[VirtualGL-Announce] Update on SourceForge outage

[DRC <dco...@us...>]

All services except for our subversion repositories have been restored 
(although I am still seeing some residual flakiness with some of the 
download mirrors.)

This outage has highlighted the need for distributed source control, and 
despite my reservations about git, I've decided that the benefits of 
that system finally outweigh the pain of migrating to it.  As soon as 
the subversion repositories come back online, I'll begin migrating them 
to GitHub, as well as tracking for new issues/feature requests (existing 
tracker items, as well as mailing lists and file releases, will remain 
on SourceForge.)  I will keep everyone posted as to the status of this 
migration.

DRC

[VirtualGL-Announce] VirtualGL 2.4.1 has been released

[DRC <dco...@us...>]

http://sourceforge.net/projects/virtualgl/files/2.4.1/

Packaging changes:
These packages were built with libjpeg-turbo 1.4.1:
http://sourceforge.net/projects/libjpeg-turbo/files/1.4.1/
This improves performance on 64-bit Mac clients, relative to VirtualGL 2.4.

Significant changes since 2.4:

[1] When an application doesn't explicitly specify its visual 
requirements by calling glXChooseVisual()/glXChooseFBConfig(), the 
default GLX framebuffer config that VirtualGL assigns to it now contains 
a stencil buffer.  This eliminates the need to specify 
VGL_DEFAULTFBCONFIG=GLX_STENCIL_SIZE,8 with certain applications 
(previously necessary when running Abaqus v6 and MAGMA5.)

[2] VirtualGL will no longer advertise that it supports the 
GLX_ARB_create_context and GLX_ARB_create_context_profile extensions 
unless the underlying OpenGL library exports the 
glXCreateContextAttribsARB() function.

[3] Fixed "Invalid MIT-MAGIC-COOKIE-1" errors that would prevent 
VirtualGL from working when vglconnect was used to connect to a 
VirtualGL server from a client running Cygwin/X.

[4] If a 3D application is rendering to the front buffer and one of the 
end-of-frame trigger functions (glFlush()/glFinish()/glXWaitGL()) is 
called, VirtualGL will no longer read back the framebuffer unless the 
render mode is GL_RENDER.  Reading back the front buffer when the render 
mode is GL_SELECT or GL_FEEDBACK is not only unnecessary, but it was 
known to cause a GLXBadContextState error with newer nVidia drivers 
(340.xx and later) in certain cases.

[5] Fixed a deadlock that occurred in the multi-threaded rendering test 
of fakerut when it was run with the XCB interposer enabled.  This was 
due to VirtualGL attempting to handle XCB events when Xlib owned the 
event queue.  It is possible that this issue affected or would have 
affected real-world applications as well.

[6] Fixed an issue that caused certain 3D applications (observed with 
CAESES/FFW, although others were possibly affected as well) to abort 
with "ERROR: in TempContext-- Could not bind OpenGL context to window 
(window may may have disappeared)".  When the 3D application called 
glXChooseVisual(), VirtualGL was choosing a corresponding FB config with 
GLX_DRAWABLE_TYPE=GLX_PBUFFER_BIT (assuming that VGL_DRAWABLE=pbuffer, 
which is the default.)  This is incorrect, however, because regardless 
of the value of VGL_DRAWABLE, VirtualGL still uses Pixmaps on the 3D X 
server to represent GLX Pixmaps (necessary in order to make 
GLX_EXT_texture_from_pixmap work properly.)  Thus, VGL needs to choose 
an FB config that supports both Pbuffers and Pixmaps.  This was 
generally only a problem with nVidia drivers, because they export 
different FB configs for GLX_PBUFFER_BIT and GLX_PBUFFER_BIT|GLX_PIXMAP_BIT.

[VirtualGL-Announce] VirtualGL 2.4 has been released

[DRC <dco...@us...>]

http://sourceforge.net/projects/virtualgl/files/2.4/

Significant changes since 2.4 beta1:

[1] Fixed an issue that prevented recent versions of Google 
Chrome/Chromium from running properly in VirtualGL.

[2] VGL_SYNC now affects glFlush().  Although this does not strictly 
conform to the OpenGL spec (glFlush() is supposed to be an asynchronous 
command), it was necessary in order to make certain features of Cadence 
Allegro work properly.  Since virtually no applications require 
VGL_SYNC, it is believed that this change is innocuous.

[3] Fixed a bug in vglconnect introduced in VirtualGL 2.3 that prevented 
'vglconnect -x' from working properly if the user did not have access to 
the current directory (vglconnect was erroneously creating a temporary 
file in the current directory instead of in /tmp.)

[4] GLXspheres now warns if the specified polygon count would exceed the 
limit of 57600 polygons per sphere imposed by GLU and prints the actual 
polygon count with this limit taken into account.  Also, a new option 
(-n) has been introduced to increase the sphere count.

[5] VirtualGL will now only enable color index rendering emulation if a 
color index context is current.  This specifically fixes an interaction 
issue with MSC Mentat, which occasionally calls glIndexi() when an RGBA 
context is current, but the fix may affect other applications as well.

[6] VirtualGL can now interpose enough of the XCB API to make Qt 5 work 
properly.  Qt 5 does not use XCB to perform 3D rendering (there is no 
suitable XCB replacement for GLX yet), but it does use XCB to detect 
whether the GLX extension is available and to handle the application's 
event queue(s).  Thus, when attempting to run Qt 5 applications in 
VirtualGL, previously the OpenGL portion of the window would fail to 
resize when the window was resized, or the application would complain 
that OpenGL was not available and fail to start, or the application 
would fall back to non-OpenGL rendering.

Currently, enabling XCB support in VirtualGL requires building VirtualGL 
from source and adding -DVGL_FAKEXCB=1 to the CMake command line.  The 
XCB interposer is also disabled by default at run time.  It must be 
enabled by setting the VGL_FAKEXCB environment variable to 1 or passing 
+xcb to vglrun.

[7] Fixed a deadlock that occurred when running compiz 0.9.11 (and 
possibly other versions as well) with VirtualGL.  The issue occurred 
when compiz called XGrabServer(), followed by glXCreatePixmap() and 
glXDestroyPixmap().  In VirtualGL, a GLX pixmap resides on the 3D X 
server, but the corresponding X11 pixmap resides on the 2D X server. 
Thus, VirtualGL has to synchronize pixels between the two pixmaps in 
response to certain operations, such as XCopyArea() and XGetImage(), or 
when the GLX pixmap is destroyed.  VirtualGL was previously opening a 
new connection to the 2D X server in order to perform this 
synchronization, and because the 2D X server was grabbed, compiz locked 
up when VirtualGL called XCloseDisplay() on the new display connection. 
  In fact, however, the new display connection was unnecessary, since 
the GLX/X11 pixmap synchronization occurs within the 3D rendering 
thread.  Thus, VirtualGL now simply reuses the same display connection 
that is passed to glXCreate[GLX]Pixmap().

[8] NetTest and TCBench for Windows are now supplied in a package called 
VirtualGL-Utils, which can be built from the VirtualGL source.  When the 
VirtualGL Client for Exceed was discontinued, these utilities ceased to 
have a home, but they are still useful tools to have, irrespective of 
the thin client solution that is being used.  The Windows build of 
TCBench was temporarily moved into the Windows TurboVNC Viewer packages, 
but it proved to be a pain to keep the source code synchronized between 
the two projects.

The VirtualGL-Utils package additionally contains a WGL version of 
GLXspheres, which is a useful tool to have when benchmarking Windows 
virtual machines that are running in a VirtualGL environment.

[9] Worked around an issue in recent versions of SPECviewperf and FEMFAT 
visualizer that caused them to segfault when used with VirtualGL.  Those 
applications apparently use a dynamic loading mechanism for OpenGL 
extension functions, and this mechanism defines symbols such as 
"glGenBuffers" at file scope.  Any symbol exported by an application 
will override a symbol of the same name exported by a shared library, so 
when VirtualGL tried to call glGenBuffers(), glBindBuffer(), etc., it 
was picking up the symbols from the application, not from libGL (and 
those symbols from the application were not necessarily defined.) 
VirtualGL now obtains the function pointers it needs for PBO readback 
directly from libGL using glXProcAddress() rather than relying on the 
dynamic linker to resolve them.  Note that this issue could be worked 
around in previous versions of VirtualGL by setting VGL_READBACK=sync.

[VirtualGL-Announce] VirtualGL 2.4 beta1 has been released

[DRC <dco...@us...>]

This is mainly just a bug fix release, but I also did an extensive 
overhaul of the code, making vast improvements to readability and 
maintainability, using more modern and consistent variable and class 
naming conventions, adding automated tests, etc.  Thus, I felt it 
prudent to put the code through a beta cycle.

Mac and Linux packages are here:
https://sourceforge.net/projects/virtualgl/files/2.3.90%20%282.4beta1%29/

Follow these instructions for Cygwin:
http://www.virtualgl.org/Documentation/Cygwin


Significant changes since 2.3.3:

[1] The VirtualGL Client for Exceed has been retired.  It will continue 
to be maintained in the 2.3.x branch on a break/fix basis only. 
Cygwin/X has matured to the point that it now provides an adequate 
solution for using the VirtualGL Client on Windows, with the only major 
limitation being lack of quad-buffered stereo support.  That feature 
alone is insufficient to justify a code base that is basically twice as 
complex as it otherwise would be.  Further, we are now maintaining our 
own Cygwin repository for the VirtualGL Client, which makes it easier to 
install on that platform.

The VirtualGL Client for Exceed reflects VirtualGL's origins as an 
add-on technology for existing remote X environments.  These days, most 
people use VirtualGL with some sort of X proxy instead.  There have been 
no significant changes to vglclient since version 2.2.1, as most of the 
efforts of The VirtualGL Project in recent years have focused on the 
server-side components and TurboVNC.  In the early days of the project, 
there were performance advantages to the VGL Transport, but that is no 
longer the case.  In fact, TurboVNC will generally do a better and 
faster job of compressing the image stream, since it uses a hybrid 
compression scheme rather than pure JPEG.  The native Windows version of 
TCBench, which previously shipped with the VirtualGL Client for Exceed, 
has been moved into the Windows TurboVNC Viewer package.

[2] The VirtualGL source code has been extensively refactored to use 
more modern variable, class, and method naming conventions, and 
automated test scripts for the utility libraries and the faker have been 
added.

[3] glXChooseFBConfig() now properly handles the GLX_FBCONFIG_ID 
attribute.  The improper handling of this attribute was known to cause 
an error ("Could not find GLX 1.3 config from peer info") when running 
the LWJGL (Lightweight Java Game Library) on AMD GPUs, but it may have 
affected other apps as well.

[4] The performance of PBO readback on ATI FirePro adapters has been 
improved dramatically (close to an order of magnitude.)

[5] vglserver_config will now set DRI device permissions properly on 
systems that lack an xorg.conf file but have an xorg.conf.d directory.

[6] vglserver_config should now work with recent Debian releases.

[7] Fixed an issue whereby VirtualGL would not always resize the Pbuffer 
corresponding to an Xt or Motif OpenGL widget whenever the widget was 
resized.

[8] The Mac packaging system now uses pkgbuild and productbuild rather 
than PackageMaker (which is obsolete and no longer supported.)  This 
means that OS X 10.6 "Snow Leopard" or later must be used when packaging 
VirtualGL, although the packages produced can be installed on OS X 10.5 
"Leopard" or later.  OS X 10.4 "Tiger" is no longer supported.

[9] The "Uninstall VirtualGL" app should once again work on OS X 10.5.

[10] Fixed an infinite drawing loop that occurred when running Altair 
HyperBeam with VirtualGL.  Since 2.1.3, VirtualGL has been setting the 
WM_DELETE_WINDOW property on any OpenGL window so that it (VGL) can be 
notified if the window manager deletes the window (thus preventing VGL 
from trying to draw to the window after it disappears.)  This was 
originally done within the body of XCreate[Simple]Window(), but Java did 
not like us overriding the property for 2D windows (refer to 2.3.1[9].) 
  Thus, the setting of WM_DELETE_WINDOW was moved into the body of 
glXMake[Context]Current() so that it affected only OpenGL windows. 
However, VGL was incorrectly replacing the list of WM protocols rather 
than simply adding WM_DELETE_WINDOW to the existing list.  VGL was also 
not checking whether WM_DELETE_WINDOW already existed in the list before 
adding it.  For reasons that are not well understood, this caused 
HyperBeam to get into an infinite loop, because calling 
XSetWMProtocols() within the body of glXMakeCurrent() seemed to cause 
the application to call glXMakeCurrent() again.  This issue may have 
affected other applications as well.

[11] Fixed an issue whereby the RPMs generated by VirtualGL's packaging 
system (including the official RPMs for VGL 2.3.2 and 2.3.3) could not 
be installed on later Fedora releases.

[12] Fixed an issue whereby glXSwapBuffers() would not work properly 
unless the drawable passed to that function was current.  This 
specifically fixes a rendering issue with voreen, but it may have 
affected other apps as well.

[13] Fixed an issue that prevented vglgenkey from working properly on 
Red Hat Enterprise Linux 7.

[14] Fixed an issue that prevented vglserver_config from working 
properly on Ubuntu 14.04.

[VirtualGL-Announce] TurboVNC now has a new home

[DRC <dco...@us...>]

I am pleased to report that the spinoff of TurboVNC into a separate 
project has been completed.


What has changed
================


Mailing lists
-------------

Perhaps most important for those reading this-- there are three new 
mailing lists specific to TurboVNC (turbovnc-announce, turbovnc-users, 
turbovnc-devel.)  If you are an active customer of mine who is using 
TurboVNC, or if your e-mail address contained the word "TurboVNC" in it 
(pretty obvious), then I automatically copied your subscription from 
virtualgl-{} to turbovnc-{}, but otherwise, please take a moment to 
subscribe to one or more of the new lists if you want to continue 
receiving information about TurboVNC:

http://sourceforge.net/p/turbovnc/mailman/

You may also want to unsubscribe from the virtualgl-* mailing lists if 
you don't care about VirtualGL.  The virtualgl-* mailing lists will be, 
from this moment forward, for discussing VirtualGL only.


Downloads
---------

-- VirtualGL files are now at:
    http://sourceforge.net/projects/virtualgl/files/
-- TurboVNC files are now at:
    http://sourceforge.net/projects/turbovnc/files/

Please update any packaging scripts and documentation to reflect the new 
URLs.  Unfortunately, SourceForge doesn't allow symlinking within the 
file release directories, so I can't maintain backward compatibility here.


Web sites
---------

-- TurboVNC now has its own SourceForge project page at 
http://www.sourceforge.net/projects/turbovnc.  All TurboVNC bugs, 
feature requests, and patches have been moved into that tracker.  Both 
the VirtualGL and TurboVNC SourceForge pages contain a link to the 
other, for convenience.

-- All of the TurboVNC content that used to be on VirtualGL.org is now 
on http://www.TurboVNC.org.  That includes all of the sponsors and 
projects on the "Sponsors" page that were specific to TurboVNC.

-- The pre-release builds for TurboVNC are now at:
    http://www.turbovnc.org/DeveloperInfo/PreReleases


Subversion
----------

The VirtualGL and TurboVNC subversion repositories have been split and 
re-imported.  Thus, it is no longer necessary to add "vgl" or "vnc" to 
the end of the subversion URL when doing a checkout.  The new URLs for 
anonymous checkout are:

-- VirtualGL:
    svn://svn.code.sf.net/p/virtualgl/code
-- TurboVNC:
    svn://svn.code.sf.net/p/turbovnc/code

(add "trunk" or "branches/*" or "tags/*" to these URLs to check out a 
specific version.)

Unfortunately, you will have to re-checkout existing working copies. 
There is no way to use 'svn switch' to migrate the working copies, 
because the revision numbering has changed.


New icons/logos
---------------

For the time being, I have updated the icons and logos to use a more 
modern (fire-engine-red) color scheme.  I am, however, looking for a 
graphic artist who would be willing to design a new logo for the 
project.  If you or someone you know might be interested, let me know.


What hasn't changed
===================

"The VirtualGL Project" is still the name of the entity that manages 
both VirtualGL and TurboVNC.

Our Facebook and LinkedIn pages will still contain both VirtualGL and 
TurboVNC content.

[Virtualgl-announce] Moving TurboVNC into a separate project

[DRC <dco...@us...>]

In order to increase the visibility of TurboVNC in the open source 
community, I think it may be time to consider spinning it off from The 
VirtualGL Project.  When VirtualGL was first open sourced 10 years ago, 
it made sense to include TurboVNC in the same project, because there 
were no other open source X proxies available at the time that had the 
necessary performance to handle 3D workloads.  During the Sun years, 
both projects were tied at the hip in the Sun Shared Visualization 
product, so it made even more sense for them to share online resources. 
  However, although I believe that TurboVNC's performance and quality 
are the best in its class, there are now quite a few other X proxies 
that provide sufficient performance for 3D workloads as well.

Although TurboVNC is well known in the visualization community, by 
virtue of its association with VirtualGL, I feel like there are a lot of 
potential users of the product who haven't heard of it because it's 
tucked away in The VirtualGL Project.  I've run across others who assume 
that TurboVNC can only be used with VirtualGL (well, they're sort of 
right if they're using a 3D application, but not other applications.) 
When you go to the VirtualGL project page on SourceForge, it lists 
TigerVNC as a recommended project.  I want TurboVNC in that list as 
well.  Further, I don't want to see anyone still trying to use TightVNC 
1.3.x (it happens more often than you'd think.)

If anyone has any strong objections, please let me know.  This isn't a 
done deal yet.  I want to get your feedback and concerns, in case there 
might be some potential downsides that I have not considered.

[Virtualgl-announce] TurboVNC 1.2.1 has been released

[DRC <dco...@us...>]

https://sourceforge.net/projects/virtualgl/files/TurboVNC/1.2.1/

Significant changes since 1.2:

[1] Fixed two regressions introduced in TurboVNC 1.0, one of which 
prevented older (RFB <= 3.3) VNC clients from connecting successfully to 
the TurboVNC Server and the other of which prevented clients other than 
TurboVNC and TightVNC from connecting to the TurboVNC Server using no 
authentication.

[2] Added a new parameter (EncPassword) to the Java TurboVNC Viewer that 
allows the password to be specified in encrypted ASCII hex.

[3] The toolbar buttons in the Java TurboVNC Viewer that send keystrokes 
are now disabled when view-only mode is selected.

[4] Enabled the MIT-SCREEN-SAVER X extension in the TurboVNC Server. 
Modern screen savers don't actually use this extension, but it provides 
an easy way for applications to query the idle time of the X server.

[5] Fixed a regression introduced in 1.2 beta1 whereby the TurboVNC 
Viewer desktop shortcut installed with the Linux RPM did not work properly.

[6] Fixed a bug in the Java TurboVNC Viewer's RRE decoder that was 
causing pixels to be displayed incorrectly.

[7] Pressing F8 (or the chosen menu key) twice in the Java TurboVNC 
Viewer now sends that keystroke to the VNC server.  This emulates the 
behavior of the X11 viewer.

[8] Added an option to vncserver that allows the output of Xvnc to be 
redirected to an arbitrary file.

[9] Implemented the X RANDR extension in the TurboVNC Server.  The main 
purpose of this at the moment is to placate applications that check for 
the extension and refuse to start without it.  The extension currently 
can't be used to change the screen size (that feature will be in 
TurboVNC 1.3.)

[10] Fixed an issue in the Java TurboVNC Viewer whereby, when a mouse 
button was pressed, pressing another button or activating the scroll 
wheel would cause the viewer to send a release event for the first button.

[11] Fixed an issue whereby the X11 TurboVNC Viewer would fail to 
authenticate if the encrypted password stored in the connection info 
file started with "00".

[12] Fixed an invalid memory access that occurred in the TurboVNC Server 
after a client disconnected.  This had the visible effect of causing an 
error ("Could not disable TCP corking: Bad file descriptor") to be 
printed to the TurboVNC Server's log, but it was not known to cause any 
other issues.

[13] Fixed an issue that prevented clipboard transfer from working 
properly with applications that request the clipboard selection in a 
non-ASCII format.  This was specifically known to affect rxvt-unicode.

[14] The Windows TurboVNC Viewer should now build properly with Visual 
Studio 2012.

[15] The "Uninstall TurboVNC" app should once again work on 32-bit OS X 
10.5 machines.

[16] Added two new command-line options to PuTTY, -L4 and -L6.  These 
work just like -L, except that -L4 forces PuTTY to use an IPv4 interface 
for the client side of the SSH tunnel, and -L6 forces PuTTY to use an 
IPv6 interface for the client side of the SSH tunnel.

[17] Worked around an issue whereby the Java/Mac TurboVNC Viewer would 
abort with "InStream max string length exceeded" when connecting to 
recent versions of the RealVNC Server.  This was due to a protocol 
conflict.  Apparently, RealVNC uses pseudo-encoding number -311 for 
their CursorWithAlpha extension, but TigerVNC uses -311 for 
ClientRedirect.  At least for now, ClientRedirect has been disabled in 
the Java TurboVNC Viewer by default, but there is a new hidden parameter 
(ClientRedirect) that can be set to 1 to re-enable it.

[18] Due to an oversight, the 3-button mouse emulation feature in the 
Windows TurboVNC Viewer was being enabled by default.  This has been 
fixed.  3-button mouse emulation is largely unnecessary with modern 
systems, and the feature is known to cause issues with certain applications.

[Virtualgl-announce] VirtualGL 2.3.3 has been released

[DRC <dco...@us...>]

https://sourceforge.net/projects/virtualgl/files/VirtualGL/2.3.3/

Significant changes since 2.3.2:

[1]
VirtualGL will no longer throw an exception if a 3D application calls 
certain X11 and GLX functions with a NULL argument.  It will instead 
allow the underlying X11 or GLX library to handle the error.  This 
specifically works around an issue with Fiji.

[2]
Worked around an issue whereby, when ANSYS Workbench 14.5 was run with 
VirtualGL, subprocesses (such as the geometry editor) launched from 
within the Workbench environment would not exit properly (and thus would 
become zombies.)  This issue also affected ANSYS HFSS, which would 
either lock up when exiting or would print an error message: "terminate 
called after throwing an instance of 'rrerror'".

[3]
Worked around an issue whereby, when using MAGMA5 with VirtualGL, the 
second and subsequent perspectives opened within the application would 
not always display correctly.

[4]
Added support for the GLX_EXT_texture_from_pixmap extension.

[5]
Added support for the GLX_EXT_swap_control and GLX_SGI_swap_control 
extensions and a new configuration variable (VGL_REFRESHRATE) that can 
be used to control them.  See the User's Guide for more information.

[6]
Added support for depth=32 visuals and FB configs.

[7]
Added a new "window manager" mode that disables certain features in 
VirtualGL that interfere with 3D window managers such as compiz.  This, 
combined with [6] and [4] above, should allow compiz to run properly 
with this version of VirtualGL, provided that the 2D X Server has 
support for the X Composite extension.  See the User's Guide for more 
information.

[8]
Fixed a BadDrawable X11 error that occurred when running the Steam 
client in VirtualGL.

[9]
Improved the accuracy of TCBench and CPUstat

[10]
Streamlined VirtualGL's behavior when it is installed from source:
-- vglrun now works regardless of where the faker libraries have been 
installed.  The build system hard-codes the value of the VGL_LIBDIR 
CMake variable into a script that vglrun invokes so it can add this 
directory to LD_LIBRARY_PATH.  If the faker libraries are installed into 
a system library directory, then packagers can choose to omit the new 
script, and vglrun will continue to work as it always has.
-- Whenever a 64-bit build is installed, glxspheres is now renamed 
glxspheres64, per the convention of the official packages.  This makes 
it possible to install a 32-bit and a 64-bit version of VirtualGL into 
the same directory.
-- If the install prefix is set to the default (/opt/VirtualGL), then 
the build system defaults to installing faker libraries from a 32-bit 
build into /opt/VirtualGL/lib32 and faker libraries from a 64-bit build 
into /opt/VirtualGL/lib64.
-- Similarly, if the install prefix is set to the default 
(/opt/VirtualGL), then the build system defaults to installing the libGL 
symlink for Chromium from a 32-bit build into /opt/VirtualGL/fakelib32 
and the libGL symlink for Chromium from a 64-bit build into 
/opt/VirtualGL/fakelib64.

[11]
PBO readback mode is now enabled by default.  Further research has shown 
that professional-grade GPUs always benefit from PBOs being enabled 
(quite dramatically, in the case of AMD FirePro adapters.)  With 
consumer-grade AMD adapters, PBOs generally do no harm, and with 
consumer-grade nVidia (GeForce) adapters, the results are mixed.  The 
GeForce drivers will fall back to blocking readbacks if the pixel format 
requested in glReadPixels() doesn't match the pixel format of the 
Pbuffer, so PBOs will generally be slower in those cases.  Thus, 
VirtualGL now falls back to synchronous readback mode if it detects that 
PBOs are not behaving asynchronously.

Further, VGL_FORCEALPHA is no longer enabled by default when PBOs are 
enabled. This option was introduced because of the GeForce behavior 
mentioned above, but the option has no effect whatsoever with the 
professional-grade GPUs that are recommended for use with VirtualGL. 
Instead, VGL will now detect situations in which VGL_FORCEALPHA might be 
beneficial and suggest enabling or disabling it (if VGL_VERBOSE=1.)

[12]
This version of VirtualGL provides a binary package and full support for 
Cygwin64.

[Virtualgl-announce] VirtualGL 2.3.3 release candidate is available for testing

[DRC <dco...@us...>]

There were significant enough changes in this release that I felt like a 
"mini beta" was warranted, so please download and test the packages from:

http://virtualgl.sourceforge.net/vgl.nightly

If no issues are discovered in a week, I'll put out the release.

Significant changes since 2.3.2:

[1]
VirtualGL will no longer throw an exception if a 3D application calls 
certain X11 and GLX functions with a NULL argument.  It will instead 
allow the underlying X11 or GLX library to handle the error.  This 
specifically works around an issue with Fiji.

[2]
Worked around an issue whereby, when ANSYS Workbench 14.5 was run with 
VirtualGL, subprocesses (such as the geometry editor) launched from 
within the Workbench environment would not exit properly (and thus would 
become zombies.)  This issue also affected ANSYS HFSS, which would 
either lock up when exiting or would print an error message: "terminate 
called after throwing an instance of 'rrerror'".

[3]
Worked around an issue whereby, when using MAGMA5 with VirtualGL, the 
second and subsequent perspectives opened within the application would 
not always display correctly.

[4]
Added support for the GLX_EXT_texture_from_pixmap extension.

[5]
Added support for the GLX_EXT_swap_control and GLX_SGI_swap_control 
extensions and a new configuration variable (VGL_REFRESHRATE) that can 
be used to control them.  See the User's Guide for more information.

[6]
Added support for depth=32 visuals and FB configs.

[7]
Added a new "window manager" mode that disables certain features in 
VirtualGL that interfere with 3D window managers such as compiz.  This, 
combined with [6] and [4] above, should allow compiz to run properly 
with this version of VirtualGL, provided that the 2D X Server has 
support for the X Composite extension.  See the User's Guide for more 
information.

[8]
Fixed a BadDrawable X11 error that occurred when running the Steam 
client in VirtualGL.

[9]
Improved the accuracy of TCBench and CPUstat

[10]
Streamlined VirtualGL's behavior when it is installed from source:
-- vglrun now works regardless of where the faker libraries have been 
installed.  The build system hard-codes the value of the VGL_LIBDIR 
CMake variable into a script that vglrun invokes so it can add this 
directory to LD_LIBRARY_PATH.  If the faker libraries are installed into 
a system library directory, then packagers can choose to omit the new 
script, and vglrun will continue to work as it always has.
-- Whenever a 64-bit build is installed, glxspheres is now renamed 
glxspheres64, per the convention of the official packages.  This makes 
it possible to install a 32-bit and a 64-bit version of VirtualGL into 
the same directory.
-- If the install prefix is set to the default (/opt/VirtualGL), then 
the build system defaults to installing faker libraries from a 32-bit 
build into /opt/VirtualGL/lib32 and faker libraries from a 64-bit build 
into /opt/VirtualGL/lib64.
-- Similarly, if the install prefix is set to the default 
(/opt/VirtualGL), then the build system defaults to installing the libGL 
symlink for Chromium from a 32-bit build into /opt/VirtualGL/fakelib32 
and the libGL symlink for Chromium from a 64-bit build into 
/opt/VirtualGL/fakelib64.

[11]
PBO readback mode is now enabled by default.  Further research has shown 
that professional-grade GPUs always benefit from PBOs being enabled 
(quite dramatically, in the case of AMD FirePro adapters.)  With 
consumer-grade AMD adapters, PBOs generally do no harm, and with 
consumer-grade nVidia (GeForce) adapters, the results are mixed.  The 
GeForce drivers will fall back to blocking readbacks if the pixel format 
requested in glReadPixels() doesn't match the pixel format of the 
Pbuffer, so PBOs will generally be slower in those cases.  Thus, 
VirtualGL now falls back to synchronous readback mode if it detects that 
PBOs are not behaving asynchronously.

Further, VGL_FORCEALPHA is no longer enabled by default when PBOs are 
enabled. This option was introduced because of the GeForce behavior 
mentioned above, but the option has no effect whatsoever with the 
professional-grade GPUs that are recommended for use with VirtualGL. 
Instead, VGL will now detect situations in which VGL_FORCEALPHA might be 
beneficial and suggest enabling or disabling it (if VGL_VERBOSE=1.)

[12]
This version of VirtualGL provides a binary package and full support for 
Cygwin64.

[Virtualgl-announce] TurboVNC: Retiring the X11 viewer + better Java viewer integration on Windows

[DRC <dco...@us...>]

I've just put out a new pre-release of TurboVNC 
(http://virtualgl.sourceforge.net/vnc.nightly.13) that gives a sneak 
preview of one of the biggest changes in TurboVNC 1.3:

Retiring the X11 viewer
-----------------------
It has been decided to get rid of the X11 viewer, although it will still 
be maintained on a break/fix basis in the 1.2 branch (no new features, 
but I'll still fix bugs if you find them.)  I've had a cross-platform 
viewer on the roadmap for a while (initially slated to be a port of the 
existing Windows viewer), and that may yet happen in coming years, but 
given how well the Java+JNI solution is working, I'm personally more 
interested in focusing on that path, since it's so much more flexible.

The new Linux packages automatically launch the Java viewer when you run 
/opt/TurboVNC/bin/vncviewer.  I am very interested in any feedback on 
this.  In particular:

-- Do you notice any performance difference relative to the old X11 
viewer?  Note that you need MIT-SHM pixmaps enabled to get peak 
performance-- the viewer script will complain if they aren't.

-- Do you have any issues with launching it?  In particular, does it 
cause problems with the Java implementation on any platforms you use? 
Note that if the "java" command isn't in your PATH, you can set 
JAVA_HOME to the directory of your JRE, and the vncviewer script will 
pick up on that.

-- Any functional issues?  Any features or behavior that you enjoyed 
from the old X11 viewer that you'd like to see incorporated?  I'm aware 
of the lack of key grabbing support, and that's definitely something 
that will go into it (somehow) before it is released.

-- Advice?  Hate mail?

Better integration of the Java TurboVNC Viewer on Windows
---------------------------------------------------------
The new Windows packages now include the libjpeg-turbo JNI library 
(turbojpeg.dll), so the Java viewer will be accelerated without having 
to install the libjpeg-turbo SDK separately.  I have not done a thorough 
evaluation of the native vs. Java performance on Windows yet, so any 
feedback on that is welcome as well.  There is no plan to retire the 
Windows viewer, but I would like the Java viewer to perform as close to 
it as possible, since a lot of people are starting to use the Java 
viewer as a zero-install solution.

On Windows, a script is now included (c:\program 
files\turbovnc\vncviewer-java.bat) that will allow you to access the 
command-line functions of the Java viewer, such as the -via and -tunnel 
options for SSH tunneling.

[Virtualgl-announce] TurboVNC 1.2 has been released

[DRC <dco...@us...>]

https://sourceforge.net/projects/virtualgl/files/TurboVNC/1.2/

Significant changes since 1.2 beta1:

[1]
The Mac TurboVNC Viewer no longer has a separate menu for the "About" 
and "Preferences" options.  As is the case with most Mac applications, 
these options are now accessed from the application menu.

[2]
Opening VNC viewer config (.vnc) files in the OS X Finder or dragging 
and dropping them onto the Mac TurboVNC Viewer icon now works properly. 
  Additionally, if a connection is already open, dragging and dropping a 
.vnc file onto the Mac TurboVNC Viewer icon will now open a new connection.

[3]
VNC viewer config (.vnc) files can now be opened in Windows by dragging 
and dropping them onto the Windows TurboVNC Viewer icon.

[4]
The Java TurboVNC Viewer can now be built and run with Java 1.5. 
Consequently, the Mac TurboVNC Viewer now works with the version of Java 
shipped with OS X 10.4 and 10.5.

[5]
Previously, when using the Java TurboVNC Viewer on Mac platforms, the 
menu bar was still visible in full-screen mode, and the dock was still 
visible if it was not set to auto-hide.  The Java/Mac TurboVNC Viewer 
now takes advantage of the OS X Lion full-screen feature, if available, 
to provide a "true" full-screen mode on OS X 10.7 and later.  On OS X 
10.6 and earlier, the behavior is unchanged.

[6]
Fixed a regression in the new Java TurboVNC Viewer whereby, when used as 
an applet, specifying a host other than the VNC server in the "Server" 
parameter had no effect.

[7]
Fixed various key mapping issues in the Java TurboVNC Viewer:
-- The viewer now differentiates between the numeric keypad versions of 
the navigation keys (Home, End, etc.) and their equivalents on the main 
keyboard.
-- The viewer now differentiates between the left and right versions of 
the modifier keys (Alt, Ctrl, etc.)
-- The viewer now properly handles the AltGr key on international keyboards.
-- Left Alt key sequences on Mac clients can now be used to activate 
pull-down menus on Linux/Windows servers.
-- The Apple keys on Macintosh keyboards can now be used as Windows keys 
when connecting to Linux and Windows servers.

[8]
The Windows TurboVNC Viewer now properly differentiates between the 
numeric keypad versions of the navigation keys (Home, End, etc.) and 
their equivalents on the main keyboard.

[9]
Fixed a minor issue in the Windows TurboVNC Viewer whereby it would 
trigger an Alt keypress on the remote desktop whenever an AltGr key 
symbol was typed repeatedly.

[10]
Added LSB headers to the TurboVNC Server init.d script (tvncserver) in 
order to avoid insserv errors/warnings with recent Debian releases.

[11]
The TurboVNC Server can now build its font path from a font catalogue, 
on systems that support them (such as RHEL 6.)  vncserver will now check 
for the existence of a font catalogue at /etc/X11/fontpath.d and use it 
if it exists.  For systems that do not support font catalogues, 
vncserver will now check for the existence of the Liberation fonts (used 
by LibreOffice) and the Ghostscript fonts and add them to the fontpath.

[12]
Fixed an error that occurred when running '/etc/init.d/tvncserver stop' 
with an empty /etc/sysconfig/tvncservers file.

[13]
Fixed an issue whereby the X11 TurboVNC Viewer would fail with an error 
message of "Password stored in connection info file is invalid" when 
loading a connection info file in which the encrypted password contained 
"00".

[14]
Fixed an issue with the multi-monitor spanning feature in the Mac/Java 
TurboVNC Viewer whereby the remote desktop would appear on the secondary 
monitor instead of the primary monitor when the span mode was set to 
"Primary" (or when the span mode was set to "Auto" and the remote 
desktop area was less than the primary monitor area.)


Significant changes since 1.2 rc:

[15]
Fixed Xvnc build errors on Solaris and FreeBSD.

[16]
The X11 TurboVNC Viewer will now temporarily ungrab the keyboard if the 
viewer window loses focus while the keyboard is grabbed (when not in 
full-screen mode, this can happen if the user clicks on another window, 
or if a notification dialog from the window manager pops up.)

[17]
Fixed TurboVNC Server build issues that occurred under Ubuntu 13.04 (and 
possibly other new Linux distros.)

[18]
The default xstartup.turbovnc script that the TurboVNC Server creates 
will now use the Gnome fallback window manager on Ubuntu 12.10 and 
later, assuming that the "gnome-session-fallback" package is installed. 
  TurboVNC cannot use Unity 3D (yet), and Unity 2D was removed in Ubuntu 
12.10 and later.

[19]
Fixed a segfault that occurred when starting the TurboVNC Server on 
Ubuntu 13.04 and Fedora 18 (and possibly other new Linux distros.)

[20]
The X11 TurboVNC Viewer will now automatically release the modifier keys 
if the viewer window loses focus.  This fixes an issue whereby using 
Alt-Tab to switch windows would leave the Alt key in a pressed state on 
the server.

[21]
The Java TurboVNC Viewer was ignoring the PORT parameter when SSH 
tunneling was enabled.  This has been fixed.

[22]
Fixed an issue whereby the Java TurboVNC Viewer window would not close 
if the server disconnected and the viewer was either running in listen 
mode or it had more than one connection open.

[23]
Since there is no way to see the console output in a Java Web Start 
environment or when starting the Java TurboVNC Viewer from an icon, it 
is difficult or impossible in such cases to debug errors that are only 
displayed to the console.  Thus, the Java TurboVNC Viewer now displays 
all errors both to the console and in an error dialog.

[24]
Fixed an issue in the Java TurboVNC Viewer whereby pressing Alt-Tab 
would change the keyboard focus to another window but would not bring 
the other window to the top.  This was originally a feature, not a bug, 
and was meant to be a stopgap substitute for a proper keyboard grabbing 
feature, but the behavior causes confusion and does not achieve the 
primary goal that a keyboard grabber should achieve (sending special 
keystrokes to the server.)

[25]
Fixed an issue in the TurboVNC Server whereby the value of $desktopName 
was being ignored if it was present in the TurboVNC config file.

[Virtualgl-announce] TurboVNC 1.2 release candidate

[DRC <dco...@us...>]

is now available at:

https://sourceforge.net/projects/virtualgl/files/TurboVNC/1.1.95%20%281.2rc%29/

There were enough issues discovered with the Java viewer that I felt it 
prudent to give the community another pass at testing it before the 
final release is issued.  All remaining issues that I'm aware of are 
bugs in Java, but I've filed bug reports for them on SourceForge for 
tracking purposes.  Please give everything a thorough test, particularly 
if your environment could be affected by one or more of the issues below.

Also note that, relative to the most recent pre-release build, this 
release enables multi-screen spanning with the new Lion full-screen feature.


Significant changes since 1.2 beta1:

[1] The Mac TurboVNC Viewer no longer has a separate menu for the 
"About" and "Preferences" options.  As is the case with most Mac 
applications, these options are now accessed from the application menu.

[2] Opening VNC viewer config (.vnc) files in the OS X Finder or 
dragging and dropping them onto the Mac TurboVNC Viewer icon now works 
properly.  Additionally, if a connection is already open, dragging and 
dropping a .vnc file onto the Mac TurboVNC Viewer icon will now open a 
new connection.

[3] VNC viewer config (.vnc) files can now be opened in Windows by 
dragging and dropping them onto the Windows TurboVNC Viewer icon.

[4] The Java TurboVNC Viewer can now be built and run with Java 1.5. 
Consequently, the Mac TurboVNC Viewer now works with the version of Java 
shipped with OS X 10.4 and 10.5.

[5] Normally, when using the Java TurboVNC Viewer on Mac platforms, the 
menu bar is still visible in full-screen mode, and the dock is still 
visible if it is not set to auto-hide.  The Java/Mac TurboVNC Viewer now 
takes advantage of the OS X Lion full-screen feature, if available, to 
provide a "true" full-screen mode on OS X 10.7 and later.  On OS X 10.6 
and earlier, the behavior is unchanged.

[6] Fixed a regression in the new Java TurboVNC Viewer whereby, when 
used as an applet, specifying a host other than the VNC server in the 
"Server" parameter had no effect.

[7] Fixed various key mapping issues in the Java TurboVNC Viewer:
-- Inability to differentiate between the numeric keypad versions of the 
navigation keys (Home, End, etc.) and their equivalents on the main 
keyboard.
-- Inability to differentiate between the left and right versions of the 
modifier keys (Alt, Ctrl, etc.)
-- The viewer was not properly handling the AltGr key on international 
keyboards.
-- Inability to use left Alt key sequences on Mac clients to activate 
pull-down menus on Linux/Windows servers.
-- The Apple keys on Macintosh keyboards can now be used as Windows keys 
when connecting to Linux and Windows servers.

[8] The Windows TurboVNC Viewer now properly differentiates between the 
numeric keypad versions of the navigation keys (Home, End, etc.) and 
their equivalents on the main keyboard.

[9] Fixed a minor issue in the Windows TurboVNC Viewer whereby it would 
trigger an Alt keypress on the remote desktop whenever an AltGr key 
symbol was typed repeatedly.

[10] Added LSB headers to the TurboVNC Server init.d script (tvncserver) 
in order to avoid insserv errors/warnings with recent Debian releases.

[11] The TurboVNC Server can now build its font path from a font 
catalogue, on systems that support them (such as RHEL 6.)  vncserver 
will now check for the existence of a font catalogue at 
/etc/X11/fontpath.d and use it if it exists.  For systems that do not 
support font catalogues, vncserver will now check for the existence of 
the Liberation fonts (used by LibreOffice) and the Ghostscript fonts and 
add them to the fontpath.

[12] Fixed an error that occurred when running '/etc/init.d/tvncserver 
stop' with an empty /etc/sysconfig/tvncservers file.

[13] Fixed an issue whereby the X11 TurboVNC Viewer would fail with an 
error message of "Password stored in connection info file is invalid" 
when loading a connection info file in which the encrypted password 
contained "00".

[14] Fixed an issue with the multi-monitor spanning feature in the 
Mac/Java TurboVNC Viewer whereby the remote desktop would appear on the 
secondary monitor instead of the primary monitor when the span mode was 
set to "Primary" (or when the span mode was set to "Auto" and the remote 
desktop area was less than the primary monitor area.)

[Virtualgl-announce] Additional features/fixes in 1.2 beta1

[DRC <dco...@us...>]

I accidentally left off three items in the 1.2 beta1 change log.  These 
were features/fixes that I was collecting for a 1.1.1 release that never 
happened:


[1] Modified the default xstartup.turbovnc script so that it loads the 
2D rather than the 3D version of the window manager on recent Ubuntu 
systems.  This specifically fixes an issue whereby the Unity window 
manager in Ubuntu 12.04 would not display its menus.

[2] Added a command-line switch (-norender) to Xvnc that can be used to 
disable the X RENDER extension.

[3] Added a command-line option (-xstartup) to vncserver that allows a 
custom startup script to be specified.  This is useful along with the 
-fg switch, because it allows a full-screen application to be launched 
without a window manager and causes the TurboVNC session to terminate 
when the application exits.

[Virtualgl-announce] TurboVNC 1.1.90 (1.2 beta1) has been released

[DRC <dco...@us...>]

https://sourceforge.net/projects/virtualgl/files/TurboVNC/1.1.90%20%281.2beta1%29/

Significant changes since 1.1:

[1] The Java TurboVNC Viewer has been completely rewritten and now 
supports most of the features of the TurboVNC native viewers, as well as 
all of the features of, and a rich GUI inspired by, the TigerVNC 1.2 
Java viewer.  In addition, the new Java TurboVNC Viewer has the ability 
to use libjpeg-turbo via JNI to decompress JPEG images, giving it levels 
of performance approaching the native viewers.  The new Java viewer now 
replaces the X11 TurboVNC Viewer on Mac systems, since it has higher 
overall performance on that platform (due to performance limitations of 
XQuartz) and much better usability.

[2] IPv6 support

[3] Implemented v0.10 of the X RENDER extension, to address 
compatibility problems with newer applications that assumed v0.10 
functionality was available without checking for it.

[4] Overhauled the build and packaging system.  All platforms now use 
CMake, and the Java code can be built either as part of a Unix or 
Windows build or as a stand-alone project.

[5] Renamed the resource file for the X11 TurboVNC Viewer to 
"Tvncviewer" to avoid conflicts with TightVNC.  This specifically fixes 
an issue whereby the TurboVNC Viewer would display its menus and 
titlebar incorrectly when running on a system that had the TightVNC 
Viewer installed.

[6] The Windows TurboVNC Viewer now accepts a scaling factor of 
"fixedratio" when using the /scale switch on the command line.  This was 
previously called "Auto" in the GUI, but the name was changed to match 
the Java TurboVNC Viewer.

[7] All default options in the X11 TurboVNC Viewer now have a 
command-line equivalent, which is useful in case the defaults are 
overridden using a resource file.

[8] Added a keyboard grabbing feature to the Windows TurboVNC Viewer so 
that it can optionally send special keystrokes (Alt-Tab, Ctrl-Esc, Menu 
key, etc.) to the VNC server.  The default behavior of this option is to 
enable grabbing only in full-screen mode (as the X11 TurboVNC Viewer 
already did), but a command-line option (-grabkeyboard) can be used to 
configure keyboard grabbing to be always on or always off. 
Additionally, grabbing can always be turned on/off by pressing 
CTRL-ALT-SHIFT-G.  The X11 TurboVNC Viewer has been extended to support 
the same functionality.

[9] Where possible, the naming of command-line options, resources, menu 
options, and parameters has been reconciled among the Windows, X11, and 
Java TurboVNC Viewers.

[10] The multi-screen window spanning feature in the Windows TurboVNC 
Viewer should now behave properly when fixed-ratio scaling is used.

[11] Fixed a logic error in the "automatic" spanning mode of the Windows 
TurboVNC Viewer, whereby it would try to extend the remote desktop 
window horizontally across multiple screens if the remote desktop height 
was taller than the local screen but the width was the same.

[12] The Windows TurboVNC Viewer will now return a non-zero exit status 
if it encounters an error.  This allows batch scripts to start the 
viewer with 'start /wait' and check its exit status.

[13] The /password option in the Windows TurboVNC Viewer should now work 
again.

[14] Fixed an intermittent failure with the idle timeout feature in the 
TurboVNC Server.  This failure was caused by the fact that the X server 
used a 32-bit value to store the number of milliseconds since 1970, and 
this value was wrapping around to 0 every 49 days.  If a TurboVNC Server 
session was started near the end of one of these 49-day cycles and the 
idle timeout was set for several days into the future, the expiration 
value for the timer would wrap around and become lower than the current 
time, thus causing the TurboVNC Server to exit.

[15] Worked around a bug in the version of TigerVNC Server that ships 
with Red Hat/CentOS 6, whereby dragging links from Firefox (running on 
the remote desktop) to the remote desktop would cause the X11 TurboVNC 
Viewer to crash.

[16] Added support for the RFB flow control extensions developed by the 
TigerVNC Project.  Clients that support these extensions (including 
TurboVNC 1.2 and later and TigerVNC 1.2 and later) can receive updates 
from the server without having to explicitly request them, which 
improves performance on high-latency networks.

[17] The titlebar of all flavors of the TurboVNC Viewer now displays the 
last encoding received from the server rather than the requested 
encoding.  This is useful when connecting to RealVNC and other servers 
that do not support Tight encoding.

[18] Implemented an interframe comparison engine (ICE) in the TurboVNC 
Server, which prevents duplicate framebuffer updates from being sent as 
a result of an application drawing the same thing over and over again. 
The ICE will normally be enabled when Compression Level 5 or above is 
requested by a VNC viewer, but you can also enable/disable it manually 
by passing command-line arguments to Xvnc.

[19] Added experimental (and currently undocumented) support for the 
-via and -tunnel command-line options to the Windows TurboVNC Viewer. 
These work the same way as the equivalent options in the X11 TurboVNC 
Viewer.  Currently, they require Cygwin SSH, since PLink does not have 
the ability to detach its process after authentication.

[Virtualgl-announce] VirtualGL 2.3.2 has been released

[DRC <dco...@us...>]

https://sourceforge.net/projects/virtualgl/files/VirtualGL/2.3.2/

Significant changes since 2.3.1:

[1] Added new stereo options, including green/magenta and blue/yellow 
anaglyphic as well as three half-resolution passive stereo options that 
can be used to drive 3D TV's.

[2] The 32-bit supplementary package for amd64 Debian systems should now 
work properly on MultiArch-compatible systems (such as Ubuntu 11 and later.)

[3] vglserver_config should now work properly with LightDM.

[4] VirtualGL was not advertising that it supported the 
GLX_ARB_create_context_profile extension, even though it does.  This has 
been fixed.

[5] VirtualGL now uses a separate OpenGL context to perform pixel 
readback.  This fixes several issues, including an error 
("GL_ARB_pixel_buffer_object extension not available") when trying to 
enable PBO readback with applications that use a 3.x or later OpenGL 
core profile, and incorrect rendering in JPCSP and other applications 
that modify certain pixel store parameters (such as GL_PACK_SWAP_BYTES 
or GL_PACK_ROW_LENGTH) that VirtualGL wasn't properly handling.

[6] VGL_FORCEALPHA=1 now works properly if the 3D application specifies 
visual attributes of GLX_RED_SIZE=GLX_GREEN_SIZE=GLX_BLUE_SIZE=1.

[7] glXUseXFont() has been extended to work with Pbuffers.  Due to an 
oversight, VirtualGL would previously abort with an error message if the 
3D application attempted to render text to a Pbuffer that it created,

[8] Fixed an issue whereby, when displaying to a 2D X server that lacked 
the MIT-SHM extension, the X11 Transport would sometimes fail to resize 
its internal Pixmap (used for double buffering) whenever the X window 
was resized.  This specifically caused OpendTect to display only a 
portion of its 3D view whenever it resized its 3D window after a 
"Restore" operation, but the issue may have affected other applications 
as well.

[9] Previously, 3D applications running in VirtualGL could not 
successfully use XGetImage() to obtain the rendered 3D pixels from a GLX 
pixmap.  This has been fixed.

[10] vglrun now automatically sets an environment variable that disables 
the execution of the VBoxTestOGL program in VirtualBox 4.2 and later. 
Since LD_PRELOAD is not propagated down to VBoxTestOGL whenever 
VirtualBox launches it (because VirtualBox is a setuid root executable), 
VBoxTestOGL always fails in a VirtualGL environment, which makes 
VirtualBox believe that the system has no 3D support.  With version 
4.1.10, VirtualBox began running VBoxTestOGL every time a VM was 
launched, which effectively prevented VBox from being used with 
VirtualGL unless the user hacked their system by symlinking /bin/true to 
/usr/lib/virtualbox/VBoxTestOGL.

[Virtualgl-announce] First pre-release build of TurboVNC 1.2 available

[DRC <dco...@us...>]

http://www.virtualgl.org/DeveloperInfo/PreReleases

This can be considered a "technology preview", since there are still a 
lot of outstanding issues to be addressed, and a few major features to 
be added before the beta.  One of the remaining major features to be 
implemented is the TigerVNC flow-control extensions, for improving 
performance on high-latency networks.  This effort has been funded and 
will be available for preview in the coming weeks.

Major new changes:

-- Support for X RENDER 0.10, which fixes major cosmetic defects 
discovered when attempting to run newer window managers and applications 
that aren't smart enough to fall back to earlier X RENDER functionality.

    KNOWN ISSUE:  With some applications, dragging a window off-screen 
and back on can corrupt the contents of the window.  This is being 
investigated.

-- The ability to disable X RENDER when starting Xvnc (pass -norender to 
vncserver.)

-- Fixed xstartup.turbovnc to automatically load the 2D version of the 
window manager on recent Ubuntu systems, which fixes various defects 
such as missing menus.  rm ~/.vnc/xstartup.turbovnc prior to starting 
TurboVNC so that it will re-create a new one.

-- NO MORE AUTOTOOLS.  The entire TurboVNC build, including the Unix 
code and Java code, are now part of the same CMake-based build system, 
which operates out of the top-level directory.

-- All-new Java viewer code base, which contains most if not all of the 
existing TurboVNC features, as well as:
    * Built-in support for VeNCrypt and TLS encryption (which can be 
used when connecting to TigerVNC servers.  We have no immediate plans to 
support TLS in the TurboVNC Server due to the pain of maintaining a 
cross-compatible GnuTLS build)
    * Built-in SSH tunneling support (currently has to be used from the 
command line.  Looking for funding to expand this into the GUI and add 
SSH key, i.e. password-less login, support)
    * Can load libjpeg-turbo via JNI, bringing the performance of the 
Java viewer to near native levels (there is further performance 
optimization work that needs to be done, and I think I can close that 
remaining gap.)  Note that if you want to build this feature or take 
advantage of it at run time, you need to install the latest pre-release 
of libjpeg-turbo from here: 
http://www.libjpeg-turbo.org/DeveloperInfo/PreReleases (not necessary 
when using the Mac app below.)
    * Packaged as a stand-alone app on Mac (fully self-contained, with 
the Java code as well as the libjpeg-turbo JNI code included in the 
app), so the app can be used as a user-friendly alternative to the X11 
TurboVNC Viewer.
    * Desktop resize support (also for use with TigerVNC servers at the 
moment.  Looking for funding to implement this in the TurboVNC server.)

    This new Java viewer will be the basis for our upcoming Android 
client, so we're looking for any and all feedback on it.

    KNOWN ISSUE:  Configuration load/save is broken at the moment. 
Eventually, the Java viewer will be able to load and save .vnc files 
like the Windows viewer.

    KNOWN ISSUE:  Loading the Java viewer using Xvnc's built-in HTTP 
server doesn't work if Xvnc is using a display other than :1.  This is 
being investigated.

-- All viewers and servers should now be fully IPv6 compliant (which 
means that TurboVNC can now be used with Microsoft DirectAccess.)  Note 
that there are new command-line options in Xvnc and vncviewer to force 
them to listen only on an IPv6 address.  The default behavior is to 
listen on both IPv4 and IPv6 addresses, if the system supports that.