fwp1@Jester.CC.MsState.Edu (Frank Peters) (06/12/91)
Hello,
I'm seeing a colormap behavior difference between the Xnews server
shipped by Sun with Open Windows and the Xsun server (at patch level
18) from the MIT R4 release tapes. In both cases I'm using the olwm
window manager as shipped with Open Windows.
The two programs that I am having trouble with are Sun Net Manager and
xv (an image display and manipulation program). I also have much more
occasional problems with xloadimage (another image viewer).
The symptoms:
When running the Xsun server Sun Net Manager (snm) has problems with
color. If I open a snm monitor window from an icon various lines and
connections that are in black and white are drawn. Glyphs that are
some color, however, don't appear until I explicitly give a refresh
command (via the window manager menu). Similarly, if another window
partially obscures the snm window and then the snm window becomes
visible again, the color portion of the display doesn't appear until
a refresh is done (I originally thought that this was a bug related
to expose events until I noticed that the only problem was with color
elements).
SNM has a graphing tool included with it. You can select a set of
host data you want displayed and pull down a menu to select the color
in which it is to be displayed. The menu consists of several boxes
of various colors. Under the Xsun server these boxes are either
black or the color of the menu background (the olwm window border
color).
When running the Xnews server snm behaves perfectly correctly. It
displays color icons as they are exposed and the boxes in this menu
are the colors they represent.
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
The xloadimage program works much better. But it occasionally causes the
following to be logged to the console (though it doesn't exit and does
display the picture):
olwm: Warning, X Error: BadColor (invalid Colormap parameter)
Request Major code: 81
Request Minor code: 2
ResourceId 0xd00001
I've read the fine manuals on xnews, xsun, xserver, olwm and the various
client applications. The olwm manual discusses colormaps a bit but doesn't
seem to be discussing this problem (and, in any event, the same olwm executable
and resource settings are being used with either X server).
Similar behavior seems to result when running the twm window manager.
Does any of this strike a familiar chord with anyone? Any suggestions
for a solution? Ideally I'd like to get snm to work with the Xsun
server from MIT, but barring that I'd like to get xv/xloadimage working
reliably with xnews.
Thanks
Frank
--
Frank Peters Internet: fwp1@CC.MsState.Edu Bitnet: FWP1@MsState
Phone: (601)325-2942 FAX: (601)325-8921alc@athene.srl.ford.COM (Alan L. Clark) (06/12/91)
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