Xref: utzoo comp.sys.sgi:8707 comp.windows.x:33799
Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!mips!sgi!shinobu!odin!sgihub!dragon!eukanuba.wpd.sgi.com!mikey
From: mikey@eukanuba.wpd.sgi.com (Mike Yang)
Newsgroups: comp.sys.sgi,comp.windows.x
Subject: Re: IRIS XallocColorCells failure
Message-ID: <1991Mar7.234158.6475@dragon.wpd.sgi.com>
Date: 7 Mar 91 23:41:58 GMT
References: <1991Mar7.201724.22547@helios.physics.utoronto.ca>
Sender: news@dragon.wpd.sgi.com (CNews Account)
Reply-To: mikey@sgi.com
Organization: Silicon Graphics, Inc.
Lines: 42

In article <1991Mar7.201724.22547@helios.physics.utoronto.ca>, sysmark@physics.utoronto.ca (Mark Bartelt) writes:
|> The window gets created as expected, but one routine (XAllocColorCells)
|> returns zero when the server starts up.  Then, when the client program
|> tries to talk to the server, the server bombs out, saying:

I'm going to assume that you're running IRIX 3.3.

Under 3.3, the default invokation of the X server provides a visual
whose colormap contains only 16 read/write colormap cells.  The
remainder are read-only.  This situation allows GL and X programs to
co-exist without colormap conflicts.

However, if you try and run an X program which requires more colormap
cells, or expects to be able to modify large numbers of them (as your
application seems to), you're going to run into problems.

One possible solution is to start your X server such that most of the
colormap cells are read/write.  If you create a ~/.xSGINeWS.cmd with:

	/usr/bin/X11/Xsgi -bs -gl

all but 16 of the colormap cells will be read/write the next time you
login.  Be aware, however, that if you do this your GL programs may
display with the "wrong" colors.

Furthermore, from your description of your problem, your application
seems to be using XStoreColors without taking into account the value
returned by XAllocColorCells.  If your program expects all the
colormap cells to be read/write, you may still get your X error.
Although this may often be the case with other vendor's X servers,
it's not with ours.

By the way, the reason why your application emits the error in
XPending is because the X protocol is asynchronous.  Until that call,
your requests are queued up and haven't been processed.  The best way
to pinpoint the location of an error is to use -sync with Xt programs,
or use XSynchronize to cause requests (e.g. XStoreColors) to occur at
the time the Xlib function is called.

-----------------------------------------------------------------------
                 Mike Yang        Silicon Graphics, Inc.
               mikey@sgi.com           415/335-1786