> 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.

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.)

> Is this a feature in the cgsix framebuffer that links is trying to
> leverage?

Not per se.  Links has no way to tell you're using a cgsix; all it
knows is what the X server presents to it.  Use xdpyinfo and you can
see the other five visuals.

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.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B