[comp.windows.x] How to define a default colour map at initialization?

larry@focsys.UUCP (Larry Williamson) (06/30/89)

When xinit starts X and xterm, a default colour map is set up that
defines black as pixel 0, white as pixel 1 and (in our case) differing
shades of red as the next 14 pixels (this is a 4 plane system, about
to be upgraded to 8 :-).

I would like X to startup with a different colour map. Specifically, I
want each pixel from 0 - n to be a shade of gray that ranges from
black at 0 to white at n.

It is easy to do this once X is started, my application changes the
colour map. The problem is that all processes that started before I
change the colour map (xterm, uwm, etc) get screwed up.  The pixel
that they were using for white (1) is now, very, very dark.  So, all
text windows suddenly go black. All processes that start after I
change the colour map, look fine. When they ask for a white pixel
value, they get the new value. (uwm is still a bugger to work with
though, because all the pop up windows it creates are black!).

I don't want to leave the pixel value 1 as white because I will be
displaying many large (>300K byte) gray scale images. It will not be
practical to run though every image and rescale all the pixel values.

Of course it is entirely possible that I have approached this problem
from the wrong direction, and I am doing everything wrong.  I have not
yet come to grips with the 'correct X philosophy' in all things.

In case it matters, and I suspect it does, I'm using X11R2.

thanks,
   -larry-- 
Larry Williamson  -- Focus Systems -- Waterloo, Ontario
                  watmath!focsys!larry  (519) 746-4918

converse@EXPO.LCS.MIT.EDU (Donna Converse) (07/01/89)

> I would like X to startup with a different colour map. Specifically, I
> want each pixel from 0 - n to be a shade of gray that ranges from
> black at 0 to white at n.

X will always start up with the same colormap, the default colormap of 
the screen.  You can't change that, and you can't cause the default 
colormap to come up with some other initial values.   But you can change
the values of the colormap cells in the default map after you begin your X
session, obviously [under visual types which allow read/write allocations]
 -- you've already done that -- and you can create other colormaps,
and direct that they be used by particular applications instead of 
[or in addition to, on a few machines] the default map.

You are describing a standard colormap, the RGB_GRAY_MAP.

> It is easy to do this once X is started, my application changes the
> colour map. The problem is that all processes that started before I
> change the colour map (xterm, uwm, etc) get screwed up.  The pixel
> that they were using for white (1) is now, very, very dark.  So, all
> text windows suddenly go black.

If you must use the default colormap of the screen for gray scale image
processing, insure that the colormap definition takes place before any other
clients begin.  Create a separate application for colormap definition,
and run it in the foreground before any other client runs.

Because you only have 16 colormap cells, I recommend that your application
create a new colormap, define the values for the color cells, and, because
you are running under R2, install it when your application gets the input focus,
and uninstall it when you loose the input focus.  R3 based applications should
not attempt to install or uninstall colormaps.  When your image processing 
application has the input focus, your xterms and other clients will not be
displayed in their proper colors.  When the mouse pointer moves out of
your image processing windows, the xterms and other clients will be
displayed in their correct colors, and the image windows will look weird.


If I've been too terse please let me know.  


Donna Converse
converse@expo.lcs.mit.edu