lcs@icad.icad.com (Larry Stone) (12/19/90)
According to my understanding of the protocol spec and Xlib, any color
cell is allocated read-only with AllocColor, it can be freed by a
FreeColors request. The only time FreeColors should issue an Access
error is when the pixel was not previously allocated by the same client.
I have some code that allocates color cells with AllocColor and later frees
them with FreeColors, and it works fine when the colormap has a read/write
kind of visual (GrayScale, PseudoColor, DirectColor). When the visual
is a static one (StaticGray, StaticColor, TrueColor), any attempt to
FreeColors gets an Access error. Philosophically, it doesn't make a lot
of sense to "reserve" and "free" color cells in an immutable color map, but
the protocol is documented to allow it (and it makes the client code simpler).
Is this a common mistake in X server implementations? I've noticed this
behavior with MIT X11R4 (p/l 14) on a DECstation, the Ultrix 4.0 product
server, and a Visual X terminal. Visual said it was a bug in the server
and is corrected the latest release.
-- Larryrws@EXPO.LCS.MIT.EDU (Bob Scheifler) (12/20/90)
I've noticed this behavior with MIT X11R4 (p/l 14) on a DECstation, I believe there is an MIT server bug if you run the server so that the default 8-bit colormap is a static visual, but I don't recall any bugs if you create your own static colormap. If you do, please submit a bug report to xbugs with a sample program to demonstrate it.
mouse@LARRY.MCRCIM.MCGILL.EDU (12/20/90)
> I have some code that allocates color cells with AllocColor and later > frees them with FreeColors, and it works fine when the colormap has a > read/write kind of visual (GrayScale, PseudoColor, DirectColor). > When the visual is a static one (StaticGray, StaticColor, TrueColor), > any attempt to FreeColors gets an Access error. More precisely, you need another condition as well: "and it's the default visual for the screen". > Is this a common mistake in X server implementations? Yes. Until I tracked it down it was in the MIT server and has doubtless spread to others, as you note. > Visual said it was a bug in the server and is corrected the latest > release. Good for them (though I'd prefer patches, but you can't have everything). der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
jbk@visual.UUCP (12/20/90)
> When the visual is a static one (StaticGray, StaticColor, TrueColor), > any attempt to FreeColors gets an Access error. > Is this a common mistake in X server implementations? Yes. Actually, it was a bug in the generic X11.3 server release from MIT. It has been fixed in Visual's newest release, 3.0, which provides a complete implementation of X11.4. Please contact us if you have any questions or if we can be of any help. Thanks, Jeff Jeff Krampf Visual Technology jbk@visual.uu.net Customer Service: 1-800-VISUALC