Hi Greg,

Thank you very much for your help! I tried VNC, but GL is not conveyed by VNC, or not easily. I tried first with tightvnc, but got an error on the GL transport, even in the machine where X11 was enough to remotely open Chimera. I also tried something called VirtualGL combined with TurboVNC but got the same error. I presume I did not properly understand this set up...

Anyway, I have yet to try your second suggestion, concerning the Mesa libraries. Perhaps that will work.

Thanks again! Cheers,

Miguel Ortiz Lombardía

Architecture et Fonction des Macromolécules Biologiques (UMR7257) CNRS, Aix-Marseille Université Case 932, 163 Avenue de Luminy, 13288 Marseille cedex 9, France Tel: +33(0) 491 82 86 44 Fax: +33(0) 491 26 67 20 mailto:miguel.ortiz-lombardia@afmb.univ-mrs.fr http://www.afmb.univ-mrs.fr/Miguel-Ortiz-Lombardia

El 30/04/14 00:35, Greg Couch escribió:

Unfortunately, while the remote display of OpenGL applications should work, it is poorly supported since the demise of SGI and DEC workstations. When it does work, it is usually because the same OpenGL driver is installed on both the server and client computers.

Normally, your best option for the Mac would be to use the XQuartz from http://xquartz.macosforge.org/ and since that didn't work, your next best option is to use remote desktop application like vnc. I don't know if you can have multiple separate desktops with vnc for each user, so that might be limited to one user at a time. You could also try updating the Mesa packages on the server (especially the mesa-glx packages). Newer versions of Mesa are much better at supporting remote OpenGL (via the GLX protocol). It appears that wheezy has Mesa 8, and debian-testing only has Mesa 9, instead of the lastest Mesa 10, so if you go this route, I'd recommend compiling Mesa 10 yourself if possible.

HTH,

Greg

On 04/29/2014 08:49 AM, Miguel Ortiz Lombardía wrote:

...

Hi all,

I understand that this is not a typical use of chimera, so I don't expect much support, but I would appreciate if someone can give me a clue to solve the issue...

We have a GNU/Linux server (Debian wheezy) with some EM software installed on it. One of these programs calls at some point chimera to show something on which the user has to act upon (or just check, not sure, I'm not the user as you've guessed) This machine is accessed from client OSX machines via ssh. All permissions are set so X11 is seamlessly tunnelled between them (checked with many graphical programs) Now, for a OSX client running on 10.6.8 (snow leopard) and using Apple's X11 the whole process works without problems. But for a OSX on 10.7.5 (lion) with a parallel installation of Apple's X11 and Xquartz 2.7.5 the first small window opens and then the chimera process hangs (it can be killed via Ctrl-C, which returns the control to the program that launched chimera and things can proceed, though without the information provided by chimera)

If I connect to the Linux server from the lion machine and directly execute chimera I make a different observation: the first small window opens but then chimera crashes leaving this error in the terminal:

Error of failed request: GLXBadCurrentWindow Major opcode of failed request: 149 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 1360 Current serial number in output stream: 1360

Now, I would appreciate any clues on the meaning and possible solution of this error or at least any directions on how to properly remove both Apple's X11 and Xquartz (they are supposed to be able to work side-by-side but I presume that a possible source of problems could arise from some conflict between them) AND re-install them to test them in a fresh install.

Downgrading the lion machine to snow leopard does not seem to be an option...

Thank you! Cheers,