Hi mjp,
Thanks for an account of a working solution to the problem. I
just wanted to
know if this intervention has to done on the client machine (from where i am
viewing the results), or on the server side (on which i am processing the
data)? Further,
in case of a 64 bit machine, would the source and the destination
directories change
accordingly?
best regards,
sid.
On Wed, Nov 19, 2008 at 8:50 AM, Mark J. Pearrow <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> This is a bug that has baffled me for almost a year now, so today I decided
> to just attend to it exclusively. I have never understood why, exactly, the
> anecdotal and illogical fix for the sliver-of-the-brain issue seems to be to
> install an NVidia graphics card in the afflicted server.
>
> I found this posting:
>
> https://mail.nmr.mgh.harvard.edu/pipermail//freesurfer/2008-April/007558.html
>
> Which seemed to indicate that it was not the card itself that made the
> difference, but rather some software component that made things work. There
> is an extension to X11, called GLX, which allows the remote side (the
> "client", in X11 speak) to bypass the processing of OpenGL commands and to
> send them to the server.
>
> So, following the advice in the posting above, I downloaded the latest
> NVidia.run package and unpacked it by using the "-x" flag - then I copied
> all of the usr/lib/ and usr/lib32/ difrectories in the (freshly unpacked)
> NVIDIA-linux directory into /usr/lib and /usr/lib32, respectively. Then I
> ran "ldconfig -v" to update the ld cache.
>
> And voila, I can run tksurfer over X11, VNC and NX now on a server that has
> no NVidia card, without any problems.
>
> I still don't understand what exactly is being provided by NVidia's version
> of the libraries, but I suspect it has to do with "TLS" (in the context of
> OpenGL, not in the crypto sense). This appeared in the output of `ldd
> tksurfer.bin` on my systems with nvidia cards, and on my previously-broken
> system after I installed those files:
>
> libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1
>
> mjp
>
>
>
>
>
>
> On Nov 18, 2008, at 9:35 PM, Bruce Fischl wrote:
>
> Hi Sid,
>>
>> this is a known problem. It actually used to work and we broke it. The
>> current workaround is to use VNC.
>>
>> cheers,
>> Bruce
>>
>>
>> On Tue, 18 Nov 2008, Siddharth Srivastava wrote:
>>
>> Hi !
>>> I am a relatively new user of freesurfer, and currently i have 2
>>> instances
>>> of the same -stable 64bit Linux versions installed, one on my local
>>> machine,
>>> and the
>>> other on a cluster, accessible over the network. I have been able to get
>>> freesurfer
>>> running without any problems on my local machine, but after i installed
>>> the
>>> same version on the remote machine, the tksurfer window did not display
>>> what i expectd to see, but only a small part of the data (%tksurfer bert
>>> lh
>>> inflated).
>>> This small patch responds to all commands from the GIU, but that is all
>>> that i see.
>>> I have trawled through the archives, both old and new, and there have
>>> been
>>> references to similar problems, without any definitive way to solve it.
>>> What
>>> exact
>>> aspect of the system configuration has to be examined/re-worked to solve
>>> it?
>>> Does anyone have any experience with this kind of problem?
>>> with regards,
>>> sid.
>>>
>>> _______________________________________________
>> Freesurfer mailing list
>> Freesurfer@nmr.mgh.harvard.edu
>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>>
>
>
_______________________________________________
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
