Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!dont-send-mail-to-path-lines
From: alc@athene.srl.ford.COM (Alan L. Clark)
Newsgroups: comp.windows.x
Subject: Re: Colormaps, Xnews vs Xsun?
Message-ID: <9106121658.AA12016@athene.srl.ford.com>
Date: 12 Jun 91 16:58:21 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 76

In article <882@ra.MsState.Edu> fwp1@jester.cc.msstate.edu
(Frank Peters) writes:

   Now, on to xv.  This program works fine with the MIT Xsun server.

   Running under the Xnews server it displays the first picture without
   any complaint.  When I select the next picture to be displayed the
   program aborts with the following error:

    X Error of failed request:  BadAccess (attempt to access private resource denied)
     Major opcode of failed request:  88 (X_FreeColors)
     Minor opcode of failed request:  112
     Resource id in failed request:  0xe0005e
     Serial number of failed request:  1300
     Current serial number in output stream:  1506

You are lucky! xv is one of the best PD client programs I've seen as far
as handling this problem is concerned.  It allows three different ways of
fixing this problem (with the OW2.0 server), via a command switch, an X
resource, or at compilation via Makefile switch, viz the following excerpt 
from the Makefile for xv:

   # If, when 'Applying' colors, or when loading new pictures, you get an
   # X Protocol Error on the XFreeColors() call, your X Server is Wrong.
   # Several workarounds:  You can specify '-bfc' on the command line, or
   # set the 'xv.brokeFreeCols' resource to 'true'.  Alternately, you can
   # uncomment the BROKECOLS line below to compile in the workarounds
   # permanently.  If you do this, '-bfc' will toggle OFF the workarounds.
   # Noteworthy Offenders:  AIX 3.1 on IBM 6000, and OLW on Suns
   #
   BROKECOLS = -DBROKEFREECOLS

also, look at the xv man page for info on -bfc or the brokeFreeCols resource.

Unfortunately, this problem rears its ugly head with many other clients
and until Sun fixes the xnews server, IT HAS TO BE HANDLED IN THE CLIENT
PROGRAM.

If you have other client programs with similar problems (like I do) and are
inclined to messing with the code, the following routine can be used in cases
where a client makes a call to XFreeColors to free a bunch of colors.
(If they are freed one by one, you have to get more involved in the
client's code).  Replace a call to 
      XFreecolors(theDisp, theCmap, freecols, nfcols, 0L);
with
      free_unique_colors(theDisp, theCmap, freecols, nfcols);

The routine follows:

void free_unique_colors( theDisp, theCmap, freecols, nfcols )
Display *theDisp;
Colormap theCmap;
Pixel *freecols;
int nfcols;    
{
    int i, j;	

    for (i=0; i<nfcols; i++) {
      int j;
      for (j=0; j<i; j++) {
        if (freecols[i] == freecols[j])   /* already been freed once */
          break;
      }  
      if (j==i)      /* wasn't found in already-freed list */
        XFreeColors(theDisp, theCmap, &freecols[i], 1, 0L);
    }

}

I hope this helps.

-------
  __       ___
 |  | |   |                   alc@athene.srl.ford.com
 |__| |   |        Al Clark,  or
 |  | |__ |___                clark@srlvx0.srl.ford.com