Re: Color resources on SunOS 4.1.3

[Sven Thommesen]

Sven Thommesen wrote:
> 
> Patrick Maheral wrote:
> >
> > Hello,
> >
> > This problem has been bothering me for some time now, but I haven't got
> > around to solving it yet.  When I run heatbugs demo, I get warnings that
> > color 0xXX0000 could not be allocated in the color map (sorry I don't have
> > the output message).  This message appears for all of the "reds" in the
> > simulation (ie colors 0xXX0000, XX = 00 to FF).  What I end up with is a
> > white world with green bugs and no heat (red).
> >
> > I realize this is a minor problem, and I just wondered if anyone else has
> > come across these warning before.  The machine is a Sun Sparc 5 running
> > SunOs 4.1.3 (Rev. B) and OpenWindows 3.0 (X11R4 I believe).
> >
> > Any suggestions appreciated.
> >
> > Thanks,
> > Patrick
> 
> Patrick,
> 
> this issue has come up before. This is "just the way X works" in default
> mode. Evidently, there's a 256-slot color resource that is shared by
> running programs that do not arrange themselves otherwise. There are 3
> possible avenues to improving the situation:
> 
> (1) Swarm can allocate itself a "local" color map, which would make it
> independent of color resources allocated already by hogs like Netscape.
> This solution evidently requires some extra programming to the Swarm
> libraries by Manor or some other knowledgeable X-guru. (It is probably
> not at the very top of Manor's list of Things To Do Right Now.)
> 
> (2) I was told that there is a way to tell X in the .Xresources file that
> a given program needs its own local color map, but I haven't had time to
> try it (and the reference is not at hand right this moment). I'll post
> the suggestion here as soon as I locate it.
> 
> (3) By default, X runs in 8-bits-per-pixel color mode. I have verified
> that if you run X in 16 or 32 bits-per-pixel mode, the problem (i.e. the
> error messages you cite) goes away. You start x in 16-bit mode by saying
>         "startx -- -bpp 16",
> or "startx -- -bpp 32" for truecolor.
> Actually, to see if this is doable in your setup, say
>         "startx -- -bpp 16 > startx.log 2>&1"
> and then look at startx.log after you exit from X. There should be an
> error message if 16bpp was not available.
> The capabilities of your graphics card + monitor are set up in the X
> configurator program. On my Linux box, the result ends up in the file
> "etc/XF86Config", which is read by X on startup.
> (Unfortunately for me, my setup at work does not support 16bpp. :-(
> I hope to change that soon ...)
> 
> Let us all know if you try #3 and meet with success!
> 
> Hope this helps,
> 
> --Sven

Patrick & Patrick,

I located the third possible way to get more color resources.

I was advised on the redhat support list, by <address@hidden>,
to put the command "xstdcmap -a" into the Xclients file (that is, into
the file "~/.Xclients" which is in your home directory.)

I just tried that, and though it seems to give some relief, it does not
solve the problem. Without this command, if I run startx and then run
Mosaic I immediately get color resources missing. Running heatbugs on 
top of that of course has the same problem. WITH this command in
.Xclients, I can start Mosaic without any complaints from X, but heatbugs
still has problems.

So it's either run in 16bpp mode, or wait for Manor ....   :-)

--Sven