Jupiter, Whilst DRC's instructions for building TurboVNC server with Mesa support are very helpful and much appreciated, the conclusion that there must be a bug in TigerVNC server makes no sense to me. You should mention that you are packaging up both TurboVNC and TigerVNC within the modules environment, and that you are including configuration information for xstartup and for the XFCE desktop environment within your packaged versions of TurboVNC and TigerVNC within the /usr/local/<module_name>/<version_number>/config/ directory. I can see major differences in the contents of those config/ directories between the TurboVNC and TigerVNC modules on at least one of our virtual machines.
Also, as discussed off list, I don't think you can safely rely on environment variables like $HOME being available in a .desktop launcher, because desktop launchers are not guaranteed to be run within a shell environment. My preference would be to omit the "Path=$HOME" line from the desktop launchers. Cheers, James On 22/12/2012, at 10:42 AM, jupiter <jupiter....@gmail.com> wrote: > Thanks for the tips of likely bugs in tigervnc to cause the problem, > and thanks for the wiki link, that is definitely the solution we need > go. > > Cheers, > > j > > On 12/22/12, DRC <dcomman...@users.sourceforge.net> wrote: >> 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 >> > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
