Such an issue has nothing to do with client/server interaction. It's most likely due to a bug in the TigerVNC server. I ceased my involvement with that project about a year ago, for a variety of reasons, but one of the largest was that I felt like I was fighting an uphill battle to make TigerVNC as performant and stable as TurboVNC. It was going to be easier to migrate the "interesting" features from TigerVNC into TurboVNC (which we're in the process of doing for TurboVNC 1.2) rather than stabilize TigerVNC and add the features to it that TurboVNC users needed. The TigerVNC Project has no QA, beta, and release process, so even when I stabilized it, it tended not to stay that way for long. On the server end, TigerVNC's stability depends a lot on the stability of a particular X.org release, so it is really designed for system integrators (such as Red Hat, etc.) to maintain, and it relies on the system integrators to do QA and fix bugs. TurboVNC, on the other hand, is designed as a self-contained, enterprise-class product, so any time a bug is fixed for one user, all users benefit.
Since I've gotten asked about using Mesa with TurboVNC several times in recent months, I went ahead and created a wiki article on it: http://www.virtualgl.org/Documentation/Mesa The procedure is simple. It just requires you to build Mesa with the X11 driver, which isn't normally included in most vendor-supplied releases of Mesa. Note that we do things this way for two reasons: (1) We don't want software OpenGL to be enabled by default in TurboVNC, because if VirtualGL were not working properly for some reason (or if the user forgot to type in 'vglrun'), they might never know that something was wrong, other than for the fact that their application was running more slowly than expected. (2) One of the driving principles of the VirtualGL Project is to avoid, as much as possible, maintaining an implementation of the OpenGL API. Because that API changes relatively quickly, we provide a platform that allows applications to interact directly with other implementations of it (including Mesa.) Thus, when OpenGL changes, usually no changes are required to VirtualGL or TurboVNC. On 12/21/12 5:12 AM, jupiter wrote: > Hi, > > I am running tigervnc 1.2.0 on server and turbovnc 1.1 for client. I > can click applications on desktop menu without problems, but when I > dragged the application icon to desktop, I could not start desktop > launcher, it could not interpret $HOME parameter and it misinterpret > "terminal" to be xterm. > > It is fair to say, it does not have such problem if I run both > turbovnc server and client together. But we don't have GPU on VM and > we have to run tigervnc server for using mesa, > > It seems either bugs in tigervnc or mismatch between tigervnc and > turbovnc viewer. Is there workaround to fix the problem? ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
