To the best of my knowlege, the establishment of the connection between the OpenDX UI and executive shouldn't care at all about how you are connected to the system on which OpenDX is running. If you successfully get a connection and try to render using OpenGL (so-called hardwaremode) it checks to see if the X server has the GLX extension and will produce an error message, but that should not interfere with establishing the connection (if there's no GLX you can always use OpenDX' native software renderer).
There are really two connections being made here. One is between the StartupUI (that silly little window that has the Edit Visual Programs button) and the real OpenDX UI, and the second, between the UI and dxexec. The command-line you saw with the -appPort argument is the command line the StartupUI is using to start the UI. This connection is via the DXLink API, and the -appPort argument determines the port to use for this connection, and defaults to 1920. The UI/dxexec connection defaults to 1900. Could it be the first of these connections that is failing, rather than the second? If the second fails you generally get an Editor up, and then a dialog comes up to tell you that the connection to dxexec failed, with (hopefully) a bit of info as to why. One thing you might try is to circumvent the StartupUI by doing directly to the Editor by typing dx -edit rather than just dx. That in effect runs the same command line that you ran successfully. If it is the UI/dxexec connection thats failing, then the problem is most likely that Editor cannot fork dxexec. By default, the Editor runsdxexec by forking dx -execonly on the same machine the editor is running on, and maintains a pipe to dxexec's stdout. It then watches the pipe for a message from the exec telling it what port the exec has opened - try running dx -execonly from the command line and you should see the port=1900 message. If that port is tied up, the exec steps up from 1900 until it finds an available port and passes the port number back to the Editor to establish the connection. There are several ways to modify this behaviour. Various environment variables come into effect, including DXEXECROOT, DXARCH, and DXHOST. There are also command-line overrides, such as -host host and -port #. So I'd wonder whether the environment you get on the machine you are trying to run OpenDX on depends in some fashion on where you log onto it from. I'd also check is that dxexec can run at all - ssh to the machine where you want to run dx and type dx -execonly. It should come back with some verbosity and then the port= message. If not, then that what we need to fix. It ought to tell you something. Hope this helps. Greg Rich Cook <[EMAIL PROTECTED]>@opendx.watson.ibm.com on 08/09/2001 12:04:47 PM Please respond to [email protected] Sent by: [EMAIL PROTECTED] To: [email protected] cc: [EMAIL PROTECTED] Subject: [opendx-users] Re: problem with dx : Cannot connect to dxexec New information: I also have a Macintosh in my office running OS X (which is BSD unix). When I ssh from there to the same AIX machine and type `dx`, then press the "edit visual programs" button, I have no problem. Therefore, I don't believe it is network topology. So, my question becomes, does the server (which I guess is called dxexec) check the hardware configuration (eg video card) for certain features (such as 3d hardware interpolation, which I believe is not available on the Indigo2 but certainly is on the Onyx and the Mac)? At 4:45 PM -0700 8/8/01, Richard Cook wrote: >Hello, when I attempt to ssh to our IBM AIX machine from my office >(an SGI indigo2 box with IRIX 6.5) and run dx, I can run the dxui >front end, but if I then try to run, say the editor from there, it >complains that it cannot connect to dxexec. >However, if I ssh to the same account on the same machine, but this >time ssh FROM a different SGI (an Onyx running IRIX 6.5 in another >building, possibly another network subnet), I can run dx and then >spawn the dx editor as you would expect, with no troubles. > >WHY OH WHY do I get this error from one box and not from the other? >This is not a problem with paths, libraries, or other configuration >issues on the AIX machine, because I ssh to the same account on the >same machine. The ONLY difference between the two situations is the >machine from which I ssh. > >I believe the problem is perhaps related to dxui, a program which is >launched by the DX front end when you click on one of its buttons. >I notice (by observing that the front end "edit visual programs" >button launches the following command: > >/usr/local/OpenDX/4.1/dx/bin_ibm6000/dxui -edit -memory 128 -processors >1 -xrm DX.editorWindow.geometry:-0+0 -appPort 1920 -wizard -directory >/usr/local/OpenDX/4.1/dx/bin > >When I try this command from the command line, it fails to work as >well, UNLESS I eliminate the -appPort 1920 line, in which case it >fires up the editor and server correctly!!!! > >I am really confused, help! Thanks. >-- >opinions expressed here are not those of my employer. >Richard Cook >Lawrence Livermore National Laboratory >Bldg-551W Rm-1300, #5, Mail Stop L-661 >7000 East Avenue, Livermore, CA, 94550, USA >phone (925) 423-9605 (work) fax (925) 424-2477 -- -Sincerely, Rich Cook 925-784-3077 ******************************************************************* Sometimes it is said that man cannot be trusted with the government of himself. Can he, then, be trusted with the government of others? Thomas Jefferson *******************************************************************
