Re: Remote ssh -Y display: cannot create graphics configuration

Hi Michael-

Michael Zeleznik wrote:
I wonder if anyone has seen this problem? I checked the archives
and did not see anything that helped.

IDV runs fine on my Linux box (Fedora core 3) with a low end video card
(ASUS Radeon 9200 SE 128MB AGP8X).

I can also "ssh -Y" from my Linux box back to itself, and IDV runs fine.
Note, if I use "ssh -X", IDV complains about GLX extensions not being
available, but "ssh -Y" works okay.

Now, on a remote SunOS SPARC server (headless, but with OpenGL installed),
I have installed the Solaris SPARC IDV.

When I "ssh -Y" from my Linux box to that remote box, and then run runIDV,
I get a popup error saying that it cannot create a graphics configuration.
Here is what it prints out:

 > ./runIDV -debug -trace
Warning: Cannot convert string "-monotype-arial-regular-r-normal--*-140-*-*-p-*-iso8859-1" to type
****** START ******
Thread:Thread-3
S   D     T>NamedStationTable.makeStations
36   297   <NamedStationTable.makeStations ms: 32
1230 6705  >NamedStationTable.makeStations
6    148   <NamedStationTable.makeStations ms: 5
25124 19885 >Decode.vm.init
4    0       >Decode.vm.getMaster()
1    0         Decode VM-getmaster-1
0    0         Decode VM-getmaster-2
3    0         Decode MVM-master-5
Java 3D WARNING : reported GLX version = 1.2
    GLX version 1.3 or higher is required
    The reported version number may be incorrect.  There is a known
    ATI driver bug in glXQueryVersion that incorrectly reports the GLX
    version as 1.2 when it really is 1.3, so Java 3D will attempt to
    run anyway.

Note, I see that same GLX warning when I run locally.

The version of Java 3D (1.3.2 or higher) that is being used
expects GLX version 1.3 or higher, but as it says, sometimes the
ATI driver will report the wrong version.  I have this same issue
on my Linux system (FC5) with an ATI card and the IDV still runs.
We were not successful installing the ATI Linux driver on my
system since it's a mobile Radeon, but that is an option to get
rid of the message.  However, it won't  solve your problem with
the headless system.

I opened my firewall up completely and still see the same problem.

I am not sure where to look next. Any pointers would be much appreciated.

I don't have any solutions for this at the moment.  But, I do
have a system to test this with and can reproduce the problem
so I'm trying various workarounds, but no success yet.

Don
*************************************************************
Don Murray                               UCAR Unidata Program
dmurray@xxxxxxxxxxxxxxxx                        P.O. Box 3000
(303) 497-8628                              Boulder, CO 80307
http://www.unidata.ucar.edu/staff/donm
*************************************************************