can not allocate any read/write color cells

[Carl Anderson]

Markus Neteler wrote:
> 

> Note: Today I have put an XDRIVER update in CVS (for GRASS 5 beta7)
>       written by Carl Anderson. He updated to run the XDRIVER
>       on various platforms with various color depth without
>       problems!
> 

please remember that I only tested for three(four) platforms
	Linux RH 6.1 - XFree86 3.3.5 - intel
	Linux RH 6.1 - Sparc (ipx, ss5)
	SUN Solaris 2.5.1 - sparc  (490/690)
	SUN Solaris 2.7 - sparc / ultra sparc (ss5, ultra5, ultra10, e5000)
for a variety of graphics cards that I had on hand
	ATI MACH 8	- intel 16 bit ISA
	ATI MACH 64	- intel pci
	S3 805		- intel pci
	S3 virge	- intel pci
	cgsix		- SUN sbus
	ffb		- SUN sbus
	pgx24		- SUN sbus
	

I would like to hear from the SGI camp and HP/UX camp and AIX camp
(I guess now that IBM is going linux wild AIX is going away...)


I want to coordinate with others on improvements.  I consider
what I gave Markus a hack, not well integrated into the general 
code scheme.  Mind you the patch does fix some problems,
especially those regarding too few colors on an 8 bit display.

The Driver code should be MUCH, MUCH more robust and able to 
choose a public or private colormap as necessary to get the most
number of colors.  And chose a visual type to go with it.


after Horacio's post  
I ran on last test of the new driver, to see if it would
reasonably fix his problem.

I set bpp to 8 bit and started XFree86 3.3.5
	and used twm as my window manager (only 4 colors allocated).

I ran the old driver (XDRIVER24), and grass d.mon, d.rast ... worked ok

I started netscape, d.rast now drew a test image but with alien colors
	(using a native colormap).
I then started gedit, d.mon now refused to start (unable to allocate
colors...)

At this point I dropped in the patched driver and d.mon worked correctly
again.
 	(even with netscape and gedit running)

It seems that KDE and Gnome and FVWM95 and Enlightenment and WindowMaker
and 
SUN CDE, and Sun Openwindows all allocate many colors for their
toolbars.  
GRASS (the old driver) doesn't play nice with other color hungry 
applications.  The updated driver fixes that problem.

But it probably introduces new troubles,  I want to find those troubles
and 
fix them.

BTW the updated driver worked when forced into all visuals
DirectColor, StaticColor, StaticGray, GrayColor, PseudoColor, and
TrueColor

Other than TrueColor and PseudoColor, private colors maps are strictly 
necessary.  But I am unaware of modern graphics cards that don't support 
either PsuedoColor or TrueColor.

the SUN pgx24 card can be run in 8 bit mode with a 24 bit overlay
so it could have
	8 bit PsuedoColor
	8 bit TrueColor
	24 bit TrueColor
	lots of other stuff

for this configuration the updated driver has a parameter
	nlev=-1
causing it to find the highest bit depth TrueColor display available.
(you still need to edit /etc/X11/XF86Config to change bit depth under 
Linux)

8 bit XFree86 3.3.5 has 6/7 bit TrueColor available, in this case
the default (PsuedoColor) is a better choice.




Horacio, 

If you don't compile grass yourself, let me know and I will email you
an updated binary for d.XXX.

-- 
----------------------------------
E-Mail: candrsn at mindspring.com
Date: Sun,  12:00:00 +0000 (GMT)

Flying Monkeys Usually Mean Trouble.
----------------------------------