Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!jade!ucbvax!shark.tek.COM!paulsh From: paulsh@shark.tek.COM Newsgroups: comp.windows.x Subject: Re: Another ??? in Porting layer doc/cfb source Message-ID: <8711032243.AA24375@shark.GWD.TEK> Date: Tue, 3-Nov-87 17:43:01 EST Article-I.D.: shark.8711032243.AA24375 Posted: Tue Nov 3 17:43:01 1987 Date-Received: Sat, 7-Nov-87 08:59:26 EST References: <8711030441.AA06334@xman.sgi.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 53 > ListInstalledColormaps is documented in PortingLayer document as taking a > pointer to a list of ColormapRec's (i.e. A ColomapPtr), but the cfb implemen- > tation takes and fills in a "Colormap *" which is just a pointer to longs. > I suspect cfb is right and documentation is wrong, anybody know better? I have successfully implemented and tested the server pScreen->ListInstalledColormaps routine using the same arguments that are found in cfb/cfbcmap.c, not those on page 25 of the "Definition of the Porting Layer" document. Therefore your assumption is correct. These are the same arguments as used in: ddx/mfb/mfbcmap.c ddx/cfb/cfbcmap.c ddx/sun/sunCG*.c And called from: dix/dispatch.c dix/colormap.c The server documentation should be corrected to read: int pScreen->ListInstalledColormaps(pScreen, pCmapList) ScreenPtr pScreen; Colormap *pCmapList; Xlib users should not confuse this with the XListInstalledColormaps routine which is functionally equivalent but returns the values as follows: Colormap *XListInstalledColormaps(display,w,num_return) Display *display; Window w; int *num_return; Thus the server implementer must allocate space for the array of Colormap ids that will be returned via pCmapList but the Xlib user can let the Xlib routine do this allocation. Paul Shearer M.S. 61-277 Tektronix, Inc. P.O. Box 1000 Wilsonville, OR 97070-1000 W (503) 685-2137 H (503) 224-3536 tektronix!shark!paulsh