Xref: utzoo comp.sys.sgi:8679 comp.windows.x:33740
Newsgroups: comp.sys.sgi,comp.windows.x
Path: utzoo!news-server.csri.toronto.edu!helios.physics.utoronto.ca!physics.utoronto.ca!sysmark
From: sysmark@physics.utoronto.ca (Mark Bartelt)
Subject: IRIS XallocColorCells failure
Message-ID: <1991Mar7.201724.22547@helios.physics.utoronto.ca>
Sender: news@helios.physics.utoronto.ca (News Administrator)
Nntp-Posting-Host: helios.physics.utoronto.ca
Reply-To: sysmark@cita.utoronto.ca
Organization: University of Toronto Physics/Astronomy/CITA
Date: Thu, 7 Mar 1991 20:17:24 GMT

I've just made my first tentative steps into the X world, and this
first foray hasn't exactly been the most fun-filled escapade of my
life, at least thus far.  In fact, I find myself stymied by a problem
which neither the SGI man pages for X (at least, the ones I've looked
at; there are *lots* of them aren't there? :-) nor the various X books
at my disposal explain, at least at a level which a neophyte like me
can understand.

First, the background:  I've taken on the somewhat unenviable task of
porting a moderately large (~35mb of source code) software package to
the IRIS.  This software runs on a variety of hardware configurations,
and drives a variety of graphics devices.  The "correct" thing to do
is to write a GL version of the package's graphics routines, but since
this software now comes with X support, it seemed reasonable to start
off using the distributed X stuff, in order to get something up and
running soon, while the GL-based stuff got written.

The way its X support works is that a server program creates a window
using Xlib calls.  It accepts a socket connection from the application
process, which sends commands to the server, telling the server to do
things to the window.

Seems like it ought to port trivially, right?  After all, isn't that
the whole point of X, easy portability and such?  (1/2 :-)

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:

X Error of failed request:  BadAccess (attempt to access private resource denied)
  Major opcode of failed request:  89 (X_StoreColors)
  Minor opcode of failed request:  0
  Resource id in failed request:  0x0
  Serial number of failed request:  53
  Current serial number in output stream:  54

I've sniffed around with dbx far enough to discover that this happens when
XPending gets called, but *only* when it's called after a bunch of other
Xlib routines get called.  (The call to XPending happens every time through
the main loop, which, besides invoking Xpending, also checks the socket which
it uses to communicate with the client).  I could provide the sequence of Xlib
calls that the server makes before the XPending bombout, but I doubt that it's
terribly relevant to understanding this problem.  (Correct me if I'm wrong!)

Being a total X neophyte, I'm not even sure which man pages to start reading.
And I have no idea whether the failure above is connected with the fact that
XAllocColorCells fails at initialization time.  I presume that there is.

The XAllocColorCells failure, plus the reference to a "private resource" in
the error message, lead me to believe that something about SGI's implementation
of X makes color cell allocation impossible (or privileged).  I've RedTFM, but
haven't yet stumbled across anything that addresses this issue.  Can anybody
who really understands this X stuff explain what's going on?  Or suggest where
the problem might lie?  Or point me to a good reference?

Note that this server (allegedly) works just fine under other vendors' versions
of X, though I haven't actually tested that yet.  So I suspect something odd
with SGI's implementation, but don't know how to discover what's different, nor
how to work around it.  To ask the time-honoured question, is this a bug or a
feature?

As usual, thanks in advance.

--

Mark Bartelt                                                      416/978-5619
Canadian Institute for                                sysmark@cita.toronto.edu
Theoretical Astrophysics                              sysmark@cita.utoronto.ca