can not allocate any read/write color cells
candrsn at mindspring.com
Wed Apr 12 23:00:28 EDT 2000
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
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
At this point I dropped in the patched driver and d.mon worked correctly
(even with netscape and gedit running)
It seems that KDE and Gnome and FVWM95 and Enlightenment and WindowMaker
SUN CDE, and Sun Openwindows all allocate many colors for their
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
BTW the updated driver worked when forced into all visuals
DirectColor, StaticColor, StaticGray, GrayColor, PseudoColor, and
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
causing it to find the highest bit depth TrueColor display available.
(you still need to edit /etc/X11/XF86Config to change bit depth under
8 bit XFree86 3.3.5 has 6/7 bit TrueColor available, in this case
the default (PsuedoColor) is a better choice.
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.
More information about the grass-user