pds@quintus.UUCP (Peter Schachte) (04/01/89)
The XVisualInfo structure has two members that appear to be redundant, namely depth and colormap_size. In every case I've seen, which isn't many, colormap_size == 1<<depth. I don't see why this wouldn't always be the case, but I'm not sure. So the question is: is this relationship always the case? If not, how can this happen? Thanks in advance, -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (04/03/89)
In every case I've seen, which isn't many, colormap_size == 1<<depth. The Digital QDSS, for example, can have depth 8 but colormap_size 254 because two colormap entries are usurped for the cursor. The sample Sun implementation ought to be (but isn't) this way as well, to reasonably support the software cursor.
rusty@garnet.berkeley.edu (04/05/89)
In article <8904021903.AA07375@EXPIRE.LCS.MIT.EDU> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes:
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Subject: Re: visual depth vs. colormap_size
Date: 2 Apr 89 19:03:43 GMT
The Digital QDSS, for example, can have depth 8 but colormap_size
254 because two colormap entries are usurped for the cursor. The
sample Sun implementation ought to be (but isn't) this way as well,
to reasonably support the software cursor.
What is wrong with the software cursor wrt the sample Sun
implementation? I can change the cursor colors and the bitmap for the
cursor on the Sun just fine. In what way is the software cursor not
"reasonably" supported?
Also puzzling is the output of xdpyinfo when you run it on a uvax 3200
with a 4 plane monochrome qdss:
Ultrix 3.0 DecWindows:
depth of root window: 4 planes
number of colormaps: minimum 1, maximum 1
default number of colormap cells: 16
preallocated pixels: black 0, white 1
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
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.
--
--------------------------------------
rusty c. wright
rusty@violet.berkeley.edu ucbvax!violet!rustyrws@EXPO.LCS.MIT.EDU (Bob Scheifler) (04/05/89)
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.fisher@decwin.DEC.COM (VMS DECwindows Engineering, 381-1466) (04/05/89)
rusty c. wright, agate!rusty@ucbvax.berkeley.edu writes: >Also puzzling is the output of xdpyinfo when you run it on a uvax 3200 >with a 4 plane monochrome qdss: > >Ultrix 3.0 DecWindows: > > depth of root window: 4 planes > number of colormaps: minimum 1, maximum 1 > default number of colormap cells: 16 > preallocated pixels: black 0, white 1 > >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 wrote a lot of the color support for the VAX server currently used on both VMS and Ultrix DECwindows, so I can tell you about that, although I can only guess about the MIT qdss server. In the 8-plane Gpx, the cursor (which is really not software...it just borrows a couple of colormap cells to determine its color) color is specified in colormap cells 254 and 255. These colormap cells are hard- wired to the cursor, although you can also use indices 254 and 255 in the regular image. I chose a somewhat different route than MIT for the 8-plane system (yes, I know...I'm coming to 4-plane). What I did was specify that there are 256 colormap cells, but I always have 254 and 255 allocated private in the default colormap. Thus, normally, one should never have a problem overwriting them. If you need to use a non-default colormap, however, you are able to allocate 254 and 255. The theory here is that you are going to screw up the colormap anyway so you probably have a good reason for doing it, and may well really need the colors. In fact I heard from a lot of image folks that they really wanted it this way since their images assumed 256 colors. Oh, yes, one more feature that makes this more palletable: When a colormap is installed, it does not actually write undefined entries into the h/w colormap. That means that if you don't really use 254/255, it won't wipe out the cursor. Now as promised to the 4-plane case: In the 4-plane GPX, the same h/w colormap is used, and it still has 256 entries. The cursor is still hard wired to 254 and 255. That means that under any philosophy, the qdss server is wrong to say that there are only 14 colors. You can use 16 with impunity. Note that this funny business with the cursor only happens on a VSII/GPX and a 3n00/GPX. On a VS2000 they put in some dedicated colormap cells for the cursor. > >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. >-- > There is no way in hardware to determine whether you have a monochrome or a color GPX. I suppose that the qdss server just assumes color. In the VAX server you can specify it. On VMS, you define a logical name. I'm not sure how that part got implemented in Ultrix. Probably a command line argument. In fact, you should probably check to make sure the MIT server does not also have a command line argument for selecting mono or color. Burns
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (04/05/89)
If you need to use a non-default colormap, however, you are able to
allocate 254 and 255. The theory here is that you are going to screw up
the colormap anyway so you probably have a good reason for doing it, and
may well really need the colors.
I would claim this is the wrong thing to do, at least as I understand what
you've said. You seem to be virtually guaranteeing that image applications
will either have completely bogus cursor colors, or else that image
applications will have specific knowledge of the hardware. Both scenarios
are bad. An image application creating its own colormap will likely either use
AllocAll for simplicity (in which case your server must assume the worse and
the cursor will get trashed), or use a standard colormap (which will probably
want to use all 256 entries for maximum shades).
(Also, you aren't "screwing up" the colormap, you're simply choosing another
one.)jlo@elan.UUCP (Jeff Lo) (04/05/89)
In article <978@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >The XVisualInfo structure has two members that appear to be redundant, >namely depth and colormap_size. In every case I've seen, which isn't >many, colormap_size == 1<<depth. I don't see why this wouldn't always >be the case, but I'm not sure. So the question is: is this relationship >always the case? If not, how can this happen? > >Thanks in advance, >-- >-Peter Schachte >pds@quintus.uucp >...!sun!quintus!pds What you are seeing is not always the case. We have an HP 9000/320 with an older mono display card, running HP's X11R2 server. With this card the display has a depth of 8, but only 2 colormap cells. I have heard that it is something needing compatibility with older color cards which are byte per pixel addressed, so the mono board was addressed with one byte per pixel. This is from xdpyinfo: depth of root window: 8 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x80065 default number of colormap cells: 2 preallocated pixels: black 0, white 1 Strange but true... -- Jeff Lo ..!{ames,uunet}!elan!jlo Elan Computer Group, Inc. 415-964-2200
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (04/06/89)
We have an HP 9000/320 with
an older mono display card, running HP's X11R2 server. With this card the
display has a depth of 8, but only 2 colormap cells.
This is really a bug. There's no good excuse (that I can think of) for why the
HP server reports a depth of 8 in this case, it should be reporting a depth of
1. (The topcat on the HP similarly reports depth 8, but it's really depth 6,
and has 64 colormap entries.) The reporting of 8 is due to bugs in the server
(the server "drawable" structure doesn't distinguish between "depth" and "bits
per pixel"). Fixed planned for R4.stroyan@hpfcdc.HP.COM (Mike Stroyan) (04/07/89)
> What you are seeing is not always the case. We have an HP 9000/320 with > an older mono display card, running HP's X11R2 server. With this card the > display has a depth of 8, but only 2 colormap cells. I have heard that it > is something needing compatibility with older color cards which are byte > per pixel addressed, so the mono board was addressed with one byte per pixel. This was the result of some assumptions in the leveraged sample server code. There wasn't time to adjust the code before the first X11 release. The depth will be reported correctly by the X server in HP's 6.5 and 3.1 releases. Mike Stroyan, stroyan@hpfcla.hp.com
harry%hpcvxhp@HP-SDE.SDE.HP.COM (Harry Phinney) (04/08/89)
> There's no good excuse (that I can think of) for why the > HP server reports a depth of 8 in this case, it should be reporting a depth of > 1. This bug was brought on initially by the need to be compatible with the dix and cfb code in the sample server, and was sustained by a lack of time and resources before R3. This bug has been fixed in the latest product release of the HP server which is supplied with the 6.5 and 3.1 releases of HP-UX for the series 300 and 800 machines respectively. Harry Phinney
geoff@desint.UUCP (Geoff Kuenning) (04/10/89)
> The Sun ddx simply allocates read-only entries out of the default colormap > (and I don't think it ever frees them). What I did in a 4-plane, 16-entry-colormap server was to make every attempt to satisfy the cursor color request, but to also allow the user to allocate the entire colormap. Here's how: Whenever I repainted the cursor, I first called a cursor-color allocation routine. (For efficiency, this routine checked a flag and only did any real work if the colormap had been changed or replaced since the last call). This routine first scanned the colormap to see if there were any free cells. If there were, it selected one arbitrarily, stored the cursor color in that cell, and used it -- but it did *not* allocate that cell from dix's point of view. (This was safe because if dix chose to allocate that cell, the routine would just pick a new one on the next cursor repaint). If the colormap had no free cells at all, the routine would search the colormap looking for an existing color that was "close" to the requested cursor color, and use the closest pixel found. (Actually, of course, this was all done in one loop). The result was that, if there were two free colormap cells, you got the cursor colors you requested. If no cells were free, but your cursor colors were selected from the colors you were using for the image itself, you still got the colors you requested. Only if you were trying to use 18 unique colors (16 for the image and 2 for the cursor) did you lose out, and then you got the server's "best effort" to achieve the cursor color you asked for. (If only one cell was free, the foreground color had priority). This solution obviously has flaws; in particular you could lose out on contrast with certain cursors and color choices. But I really couldn't see trying to explain to the user, "Yeah, it's a 16-color display, but you can only have 14 of them because you *might* want an aquamarine cursor." -- Geoff Kuenning geoff@ITcorp.com uunet!desint!geoff