Path: utzoo!attcan!uunet!lll-winken!csd4.milw.wisc.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: visual depth vs. colormap_size
Message-ID: <8904051242.AA12457@EXPIRE.LCS.MIT.EDU>
Date: 5 Apr 89 12:42:19 GMT
References: <RUSTY.89Apr4161039@garnet.berkeley.edu>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 37


    In what way is the software cursor not "reasonably" supported?

Comments in the code:

 * sunGetPixel --
 *	Given an rgb value, find an equivalent pixel value for it.
 *	XXX - this is garbage - re-implement
 
    /*
     * XXX: will have to alter the colormap entries of the foreground and
     * background pixels. For now, just change the pixels...
     */

The Sun ddx simply allocates read-only entries out of the default colormap
(and I don't think it ever frees them).  Yanking an arbitrary number of colors
away from the user is unfriendly.  Always allocating out of the default map
is incorrect for windows that use other colormaps.  There is no guarantee that
the allocation will succeed (the server is technically permitted to fail in
this operation, but it isn't very desirable to do so).

    MIT qdss server:
      depth of root window:    4 planes
      number of colormaps:    minimum 1, maximum 1
      default number of colormap cells:    14
      preallocated pixels:    black 0, white 1

I believe this is a bug in the MIT server (I think a QDSS always has the cursor
entries at 254 and 255).  The QDSS server is quite buggy in many other
respects, one more bug isn't too surprising.

    The other thing that is curious about the output of xdpyinfo when you
    run it on the MIT qdss server on a monochrome 3200 is that it has 2
    visuals and the classes are PseudoColor and StaticColor rather than
    the expected GrayScale and StaticGray.

See sentence above.