[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20000207: gf driver

Chris,

Your gpcolor session below shows that dev=xw and not gf.

If you are running dev=xw and you have color problems, it could be that
you are not running ntl, while some other hogs like netscape are eating
up the available colors.

Steve Chiswell
Unidata User Support

>From: address@hidden (Chris Hennon)
>Organization: .
>Keywords: 200002081724.KAA11256

>Steve -
>
>I tried it out today and I can write gifs now, BUT.....
>
>I noticed that the background is now a shade of blue.  So I ran
>gpcolor to change the background back to white, and it bombs out:
>
>shear:[/usr/local/gempak]% gpcolor
>Creating process: gplt for queue 950
> COLORS    Color list                        101=white
> DEVICE    Device|name|x size;y size|color   xw
> Parameters requested: COLORS,DEVICE.
> GEMPAK-GPCOLOR>r
>Creating process: xw for queue 951
> Parameters requested: COLORS,DEVICE.
> GEMPAK-GPCOLOR>X Error of failed request:  BadAccess (attempt to access
>private resource denied)
>  Major opcode of failed request:  89 (X_StoreColors)
>  Serial number of failed request:  39
>  Current serial number in output stream:  41
>
>I've never had this problem with gpcolor before.  Any ideas?
>
>Chris
>
>
>On Mon, 7 Feb 2000, Unidata Support wrote:
>
>> 
>> Chris,
>> 
>> I rebuilt the distribution, but get the same results when trying to
>> set the display to shear:0. Sending to my machine here works ok.
>> 
>> I copied over my solaris executable of $GEMEXE/gf (moved the one built
>> on your machine to $GEMEXE/gf.old. All appears to work fine using
>> or copy. You will want to verify this on your own of course.
>> 
>> At this point, this result would lead me to beleive there is something
>> in the X server that has either been patched or updated along the way.
>> I will need to look at the library calls used by gf and see if any
>> patches have been issued along the way. 
>> 
>> I also noticed that your ~ldm/decoders directory still has old versions of
>> the dc executables in there (from last August, so you will probably want to
>> make sure you are running updated version of the decoders).
>> 
>> Steve Chiswell
>> ****************************************************************************
>> Unidata User Support                                    UCAR Unidata Program
>> (303)497-8644                                                  P.O. Box 3000
>> address@hidden                                   Boulder, CO 80307
>> ----------------------------------------------------------------------------
>> Unidata WWW Service                        http://www.unidata.ucar.edu/     
>> ****************************************************************************
>> 
>