Some time ago I had a similar problem when I launched
ferret from a windows machine. I created the environment variable DISPLAY and
gave the value ‘:0.0’. The X-server itself worked fine (I caould
see xclock, for instance) but still ferret could not connect with the X-server.
I had a similar error as you: "Can't connect to X Server :0.0 Your DISPLAY environment variable must be set to point to a working X server. gopenws() 26 Specified workstation cannot
be opened gactivatews() 6 GKS not in proper state: GKS shall be
either in the state WSOP or in the state WSAC gsetdeferst() 7 GKS not in proper state: GKS shall be
in one of the states WSOP, WSAC or SGOP gsetlinerep() 7 GKS not in proper state: GKS shall be
in one of the states WSOP, WSAC or SGOP ginqmaxwssttables() 22 Specified
workstation type is invalid ginqmaxwssttables() 22 Specified
workstation type is invalid gupdatews() 7 GKS not in proper state: GKS shall be in
one of the states WSOP, WSAC or SGOP gclearws() 6 GKS not in proper state: GKS shall be
either in the state WSOP or in the state WSAC ginqwsconntype() 7 GKS not in proper state: GKS shall
be in one of the states WSOP, WSAC or SGOP gsetwswindow() 7 GKS not in proper state: GKS shall be
in one of the states WSOP, WSAC or SGOP gescsetdcsize() 7 GKS not in proper state: GKS shall be
in one of the states WSOP, WSAC or SGOP gupdatews() 7 GKS not in proper state: GKS shall be in
one of the states WSOP, WSAC or SGOP **ERROR: required program command has not been given:
graphical output device isnt ready" I still could not solve the problem. Does anyone have
an idea how I could approach this problem from a windows machine? I use ferret 5.51v in a cygwin environment. Thanks for your cooperation, Igaratza -----Mensaje original----- Dear Ferreters, By setting "xhost +":- 51 > xhost + access control disabled, clients can connect from any host I am now able to display plots in Ferret. Thank you to Martin Schmidt
for suggesting this. We think it might have something to do with the
command with which X is launched. On my machine the command is:- /usr/bin/X :0 -br -verbose -auth
/var/run/gdm/auth-for-gdm-cTFmyo/database -nolisten tcp vt7 and on both Martin's machine and machines where I can successfully run Ferret here the command is:- /usr/X11R6/bin/X :0 -audit 0 -br -dpi 96 -auth /var/lib/gdm/:0.Xauth
-nolisten tcp vt7 I have reported this to our IT group and they will look into it. If we
find a definite answer as to what it is that stops Ferret from displaying graphics with
access control enabled then I will update you. Thank you to everyone who has offered suggestions and solutions! Dr Adam Blaker Ocean Modelling and Forecasting National Oceanography Centre, Southampton ________________________________________ From: Karl.Smith@xxxxxxxx [Karl.Smith@xxxxxxxx] Sent: 09 December 2010 14:49 To: Blaker A.T. Cc: Ansley Manke Subject: Re: [ferret_users] Graphics display problem... Dr Blaker, I don't know if it will make any difference (it shouldn't), but could you try setting DISPLAY to "localhost:0.0" ? Karl ----- Original Message ----- From: "Blaker A.T." <atb299@xxxxxxxxxxxxxxx> Date: Thursday, December 9, 2010 2:19 am Subject: [ferret_users] Graphics display problem... > Dear Ferreters, > > I would like to know if anyone else has had (and hopefully solved) > problems with Ferret > being unable to display plotting windows? > > We have a problem when running Ferret under SUSE SLED v11.1, where > Ferret seems > unable to connect to the X Server, for example:- > > 22 > ferret > NOAA/PMEL TMAP > FERRET v6.64 > Linux(gfortran)
2.6.9-89.0.20.ELsmp - 09/16/10 > 9-Dec-10
10:00 > > set memory/size=9999 > Cached data cleared from memory > yes? set data levitus_climatology > yes? sho d > currently SET data sets: > 1> > /nerc/packages/ferret/6.64/fer_dsets/data/levitus_climatology.cdf > (default) name
title
I J >
K L > TEMP
TEMPERATURE
1:360 1:180 1:20 > ... > SALT
SALINITY
1:360 1:180 1:20 > ... > > yes? shade temp[k=1] > Xlib: connection to ":0.0" refused by server > Xlib: No protocol specified > > > Can't connect to X Server :0.0 > Your DISPLAY environment variable must be set to > point to a working X server. > > gopenws() 26 Specified workstation cannot be opened > gactivatews() 6 GKS not in proper state: GKS
shall be either in > the state WSOP or in the state WSAC > gsetdeferst() 7 GKS not in proper state: GKS
shall be in one of > the states WSOP, WSAC or SGOP > gsetlinerep() 7 GKS not in proper state: GKS
shall be in one of > the states WSOP, WSAC or SGOP > Xlib: connection to ":0.0" refused by server > Xlib: No protocol specified > > ginqmaxwssttables() 22 Specified workstation type is
invalid > ginqwsconntype() 7 GKS not in proper state: GKS
shall be in one > of the states WSOP, WSAC or SGOP > gsetwswindow() 7 GKS not in proper state: GKS
shall be in one of > the states WSOP, WSAC or SGOP > gescsetdcsize() 7 GKS not in proper state: GKS
shall be in one > of the states WSOP, WSAC or SGOP > gupdatews() 7 GKS not in proper state: GKS shall
be in one of > the states WSOP, WSAC or SGOP > **ERROR: required program command has not been given: graphical > output device isnt ready > yes? > > The DISPLAY environment is set correctly:- > 23 > env | grep DISPLAY > DISPLAY=:0.0 > > I have tried many other X dependent applications, including
xclock, > xcalc, and packages > such as ncview and all these work fine. We do not have the same > problem using Ferret > under SUSE SLED v10.3, the plotting windows appear fine. > > Has anyone else encountered this behaviour before? I am not sure > whether it is something > subtle that has changed or is missing from the X setup between
SLED > 10 and SLED 11, or > whether it is something to do with Ferret. One one hand, it seems > obvious that it is a SLED > 10/11 or X Server problem, but on the other hand the fact that all > the other packages I have > tried seem to work fine, suggests that it is a Ferret issue. > > > Thanks in advance, > > > Dr Adam Blaker > > Ocean Modelling and Forecasting > National Oceanography Centre, Southampton > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. |