After posting the first summary I received a couple of more answers
with additional information. There were also requests to explain the
basic setup for window exchange. Since I am anything but an expert for
that sort of thing the related part of this summary will be rather short
The problem was:
I have a problem exchanging windows between a Silicon Graphics
Iris workstation and a SUN sparcstation 1 running Motif and openwindows
respectively. It is actually a one-way problem. Getting windows from the SUN
to display on the iris is no problem, but it doesn't work the other way round.
I have already tried starting up openwin with the '-noauth' option (which
disables MIT-MAGIC-COOKIE) and am sure I have set xhost and DISPLAY
The error message I keep getting from the iris is:
--- iris1 12# dgl error (TCP connect): Connection refused dgl error (default init): default dglopen(sun1.lett.kun.nl:0.0,4) returned -127 ---
I am not really sure what the problem really is, the first line suggests security, the second something about the graphics library on the iris - the SUN only has a monochrome display.
Thanks to the following for sending more suggestions:
email@example.com firstname.lastname@example.org email@example.com firstname.lastname@example.org ravi.vax135.att.com email@example.com ilight!gaa@uunet.UU.NET firstname.lastname@example.org
The following information is (at least in part) new:
From: email@example.com a lot of applications on a SGI use the special graphic library GL which is the real heart for the fantastic graphic speed on a SGI. (You know, everything else is boring on a SGI, that's why I use the SUN) That means if you start a application on a SGI with just one GL function the special hardware is needed. But this isn't typical hardware for a SUN. So you could forget the application or you have to buy special hardware like the freedom board from E&S and special software called NthGl. Together you have to pay for this much more than for a new SS10. So... forget it ;-)
the sgi has X and gl. programs that use the sgi gl are not pure X. you cannot run gl programs on a remote display, unless the remote is an sgi. this is a problem similar to running some of the openwindows applications on an X terminal. if the openwin app. uses the news part of openwin, then you can only display on an xnews server (ie. a sun running openwin), not on a pure X server. the connection refused is coming from the fact that the sun doesn't have:
sgi-dgl 5232/tcp #SGI Distributed Graphics Lib.
in /etc/services, nor
sgi-dgl stream tcp nowait root /usr/etc/dgld dgld -IM -tDGLTSOCKET
in inetd.conf. hence the connection refused error.
also be aware that under irix 4.0.5, there is a problem in displaying openlook apps on the sgi X server. sun xview apps., like cm and mailtool, hang the irix X server. they start up okay, but as soon as you click on a button, the server freezes, and you have to kill the xview app. a workaround is to start EVERY xview app with -Wfsdb or -fullscreendebug. for example, use
mailtool -Wfsdb or mailtool -fullscreendebug
(this last tidbit is from the sgi "Pipeline", Vol. 4, No. 4, July/August 1993).
The problem is that Sun's OpenWindows lacks the DGL (SGI's Distributed Graphics Library) protocol layer that the windows (applications) on your SGI require to display graphics. It's not a security problem, nor is it a Motif/OpenLook conflict. This problem is completely analogous to the problem displaying Sun NeWS applications (such as answerbook and pageview) on non OpenWindows displays.
Most of the SGI window applications (workspace, vadmin, explorer, etc) use DGL, so you won't be able to display these on your Sun. A few apps do work though, such as insight, toolchest, winterm, grelnotes, as well as all X11 apps (xterm, xclock, xman, etc.)
DGL may be available commercially for Sun. I don't know of anyone who sells it though.
-------------------- Getting window exchange going ---------------------
To be able to exchange windows, the receiving X server must be told that it is o.k. to receive windows from some other machine using the xhost command, e.g.
allows user <some_user> to send windows from machine <some_machine>. Using only <some_machine> allows all users on that machine to send windows. the same procedure can be used to disallow access by certain users and machines using '-' instead of '+'. I have my xhost statements in the ~/.xinitrc but it is also possible to modify access from the shell prompt in a window. xhost without arguments shows the current settings. Also check the manual page for your window system to see which access control mechanisms are provided. For example, openwin allows use of MIT-MAGIC- COOKIE-1 or SUN-DES-1 (openwin -auth <protocol>) as well none at all (openwin -noauth).
Also, the remote machine must know where to send windows, i.e. the DISPLAY environment variable must be set to the local display, typically something like: pluto.lett.kun.nl:0
which results in the windows being sent to screen 0 on machine pluto.lett.kun.nl. It may not be necessary to set DISPLAY explicitly, I usually use 'xterm -exec telnet <remote_machine>' and start remote windows from there. The iris is then able to figure out the display itself, but I believe I have seen a case where other machines were not able to do this. The place to check are the comp.windows.x.* newsgroups and their faqs.
Sorry if you knew all this (or even more) already. I did say I am not an expert.
-------------------------------------------------------------------------- Ingo Jentsch Language and Speech Nijmegen University Voice: ++31 (080) 616103 email: firstname.lastname@example.org --------------------------------------------------------------------------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:06 CDT