Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!agate!rusty From: rusty@garnet.berkeley.edu Newsgroups: comp.windows.x Subject: Re: visual depth vs. colormap_size Message-ID: Date: 4 Apr 89 23:10:39 GMT References: <978@quintus.UUCP> <8904021903.AA07375@EXPIRE.LCS.MIT.EDU> Sender: usenet@agate.BERKELEY.EDU Lines: 42 In-reply-to: rws@EXPO.LCS.MIT.EDU's message of 2 Apr 89 19:03:43 GMT 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!rusty