dpg@citi.umich.edu (David Gorgen) (06/27/90)
In article <900626.14175407.003764@RMC.CP6> BUCKHOLTZ_G%RMC.CA@MITVMA.MIT.EDU writes: > Hi! > I was wondering if anyone out there has had any experience with > colormaps on Apollos. Apparently Xapollo reserves the last two cells > in the colormap for the cursor. I would like to find out what values > are hiding in these last two cells. I have tried using XQueryColor > but I get a BadValue error. When I create a new colormap > I still can't edit these last two cells. I there anything > that I can do to set and use these last two cells? > I am writing a Digital Image Processing package and I would > like all the shades of grey that I can get my hands on. > > bye, > Glenn You don't say what version of the Apollo server you are running, but it must be either the Domain/X11 product (any version through SR10.3), or some MIT version prior to R4. Current Apollo displays don't have hardware cursors, so the cursor is done in software, and therefore on a PseudoColor display it needs to be given two colormap slots. In the above versions of Xapollo, the simple scheme of using slots 254 and 255 was used. The PseudoColor visual for those displays has a colormap-entries value of 254; that is why you get a BadValue error in trying to access the two high cells. All colormaps created for that visual will have the same restriction. (By the way, this situation is not unique to Apollos; I understand that some DEC workstation displays have cursor hardware which is hard-wired to use colormap entries 254 and 255, so those servers work the same way.) This scheme had the advantages of being simple to implement, and guaranteeing that the cursor would be displayed with the correct colors, no matter what the user loaded into the colormap. However, it caused trouble for image processing applications like yours, which really need read/write access to all 256 slots. At R4, the MIT guys implemented a new software cursor scheme which (among other features) "steals" free slots dynamically from the installed colormap for the cursor. If there are no free slots, it chooses the one(s) which currently contain the closest match to the desired cursor colors. Thus the colormap- entries for the visual will be 256, but the disadvantage is that your cursor may be displayed in colors other than what they should be. If you load the whole colormap with a gray scale, a red-and-blue cursor will be displayed in shades of gray. Lacking a real hardware cursor sprite with its own 2-entry color table, this is the best that can be done. The Apollo driver was rewritten for the R4 tape, and it uses this scheme. So if you use an MIT R4 Xapollo server, you will get the above behavior. If you need to use an HP/Apollo-supported server, however (e.g. you want to mix windows from the Apollo and X window systems), you're out of luck, at least for now. Sorry, I am right now unable to say whether or when this will change in the future. -------------------------------------------------------------------------------- Dave Gorgen / GTD-East (formerly Apollo Computer), Hewlett-Packard Company located at: University of Michigan, CITI dpg@citi.umich.edu (Center for Information Technology Integration)