Path: utzoo!attcan!uunet!husc6!ogccse!blake!uw-beaver!apollo!bowbeer
From: bowbeer@apollo.COM (Joe Bowbeer)
Newsgroups: comp.windows.x
Subject: Re: Cursor Management
Message-ID: <40341100.7458@apollo.COM>
Date: 12 Dec 88 03:58:00 GMT
References: <18724@shemp.CS.UCLA.EDU>
Reply-To: bowbeer@apollo.UUCP (Joe Bowbeer)
Organization: Apollo Computer, Chelmsford, MA
Lines: 28

X11 and the portable server implementation seem to be targeted for displays
with a hardware cursor having its own two-slot colormap (ala DEC GPX,
right?). When the cursor colors must be shared with the user colormap, there
are several ways to handle this.

In the Apollo implementation, we make use of the fact that the map_entries
field of the Visual doesn't have to be equal to 2**planes. We steal the high
two slots for our cursor and make sure that map_entries is decremented
accordingly. In this scheme, the answer to your question would be: "You
can't necessarily allocate 256 slots, check map_entries for the real limit."
BTW, I'm not sure where we got this idea from. We lifted the rest of our
software cursor implemetation from Godzilla's guide (Thanks, Dave
Rosenthal).

As for you, I don't believe SUN's implementation adjusts map_entries. I
believe their server attempts to allocate the cursor slots on the fly.
Therefore, I expect either (1) the SUN cursor is drawn using the default
colormap's BlackPixel and WhitePixel regardless of the current color map, or
(2) sunGetPixel in sunCursor.c tried to allocate two slots in the new map
for the cursor but failed. In the second case, you should see a warning
message and BlackPixel would be used for both colors:

	ErrorF("sunGetPixel: Can't alloc pixel (%d,%d,%d) in map 0x%x\n",
	       r, g, b, pScreen->defColormap);

BTW, I believe it's the first case.

[These opinions are my own and not necessarily those of my employer]