sysmark@physics.utoronto.ca (Mark Bartelt) (03/08/91)
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
mikey@eukanuba.wpd.sgi.com (Mike Yang) (03/08/91)
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