On 15:38 Sat 24 Jun     , der Mouse wrote:
> > My SPARCstation 20's card works fine with X, but doesn't agree with
> > links -g. I normally run X using -cc in grayscale:
> 
> > xinit -- -ar1 200 -ar2 50 -cc 0
> 
> > But in color or grayscale links trashes the current [palette]--the
> > background flips to black, and most of the screen is unreadable.
> > When I exit links it's all good again.
> 
> This is typical colourmap contention.
> 
> Using -cc 0 does not force everything into grayscale.  The X server
> still presents the same suite of six visuals that it usually does; it
> simply makes the StaticGray one the default.  The X client in question
> (I thought links ran within a terminal emulator; if I'm right, it's the
> terminal emulator, if not, it's probably links) is discovering the
> existence of some other visual and using it.

No, links -g is an unusual graphical browser. In a terminal (text-only) mode it
works fine.

> Since a cgsix cannot support multiple colourmaps on the screen at once,
> when your window manager installs a colourmap using this other visual,
> all the windows using the default visual go technicolour.  (If you have
> your window manager switch colourmap focus back to some other window,
> the links window should go technicolour and everything else should look
> good again.)

That's fine, in fact that's what happens on my IBM T30 when I run X in
8-bit color, so the 8-bit color on my cgsix is somehow different than say an
ATI Radeon. I wonder if it's possible that links-gui is that it's generating a
palette that's not appropriate for an 8-bit Sun card.

Here's an excerpt from x.c:

    250         case 8:
    251         for (a=0;a<256;a++)
    252         {
    253             color.red=tbl1[(a>>5)&7];
    254             color.green=tbl1[(a>>2)&7];
    255             color.blue=tbl0[a&3];
    256             color.pixel=a;
    257             color.flags=DoRed|DoGreen|DoBlue;
    258             XStoreColor(x_display,x_colormap,&color);
    259         }
    260         break;

The other theory I have is that there is function being used that has
platform-specific behavior such as WhitePixel and BlackPixel:

   1106     x_black_pixel=BlackPixel(x_display,x_screen);
   1107     x_white_pixel=WhitePixel(x_display,x_screen);

According to the Xlib Programming Manual, these are not always equal to #000000
and #ffffff.

http://tronche.com/gui/x/xlib/display/display-macros.html

> If the X server you're using has a way to tell it "don't just make
> StaticGray the default; actually suppress the other visuals", using
> that should make the colourmap contention go away.  But if the X client
> in question is picky, it might well refuse to run when it finds itself
> unable to locate a suitable visual - besides, I don't know of any X
> server that runs on a cgsix that has such an option.

I couldn't find a way to force anything. I don't yet understand why a an
application would use anything but the DefaultColormap and DefaultVisual to
begin with.

Eric Radman