Re: [VirtualGL-Users] Could be bugs?

[James W. <jam...@mo...>]

DRC,

No, your original understanding of the symptoms were correct, but I'm
saying that it's not a simple TurboVNC Server versus TigerVNC Server
comparison - there are other variables at play from our customizations
in regard to default xstartup, %gconf.xml etc., so first we need to
check that those customizations are being done consistently to
eliminate confounding factors.

Cheers,
James


On 22/12/2012, at 6:06 PM, DRC <dco...@us...> wrote:

> Sorry, I guess I misunderstood the bug.  I thought he meant that he was
> dragging other application icons to the desktop and they weren't
> launching, not that he was dragging the TurboVNC/TigerVNC icons to the
> desktop and those weren't launching.  The released binaries for TigerVNC
> don't have a desktop icon, and the one that we release in TurboVNC
> refers to absolute paths.  But if these icons are being created by a 3rd
> party or are being customized, then all bets are off.
>
>
> On 12/21/12 6:47 PM, James Wettenhall wrote:
>> 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 <jup...@gm...> 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 <dco...@us...> 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
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users