Subject: Re: FVWM: Colormap issues

From: Olivier Chapuis <[email-masked]>
Date: Tue, 1 Oct 2002 08:37:31 +0200

On Mon, Sep 30, 2002 at 06:05:06PM -0700, Tim Freedom wrote:
> I had mailed about this like a couple of weeks ago, but it doesn't
> look like my mail made it to the mailing-list.  In any regard, let
> me broach the subject again.  I grabbed an fvwm snapshot (back in 9/16)
> and then again 9/26 and compiled them without a hitch, but the colormap
> is all freaky on me (gotta love that description :-)  Simply put,
> without making any changes to any of my setup files, my emacs and icons
> are very different in tone/color.  A case in point, the clamp.xpm is
> yellowish in color when it should really be brown.  If I invoke 'xv'
> from the command line and look at clamp.xpm, it looks fine (its brownish).
> I don't have any "colormap" commands in my .fvwm2rc file (FWIW).
> 
> I'll attach a small example of what I'm talking about.  Even the rcalc.xpm
> (also noted in the jpg) instead of having a gray edge has a redish one.
> 
> I looked at the Changelog to see any mention of 'colormap' and downloaded
> a few snapshots in between any mention of that word to see where the
> problem started happening for me; here's a summary,
> 
>  + snap-20020926: exhibits the same problem (colors look wrong)
>  + snap-20020916: exhibits the same problem (colors look wrong)
>  + snap-20020904: exhibits the same problem (colors look wrong)
>  + snap-20020831: exhibits the same problem (colors look wrong) 
>  + snap-20020815: exhibits the same problem (colors look wrong) 
>  + snap-20020810: exhibits problems, different form (more faded)
>  + snap-20020805: exhibits problems, faded + FvwmPager is green-puke color
>  + snap-20020731: exhibits problems, faded + FvwmPager is green-puke color
>  + snap-20020720: exhibits problems, faded + FvwmPager is green-puke color
>  + snap-20020715: Works great
>  + snap-20020501: Works great
> 
> So it might be this change that is causing the problem,
> 
> --
>     2002-07-18  olicha  <olivier.chapuis@fr...>
> 
>             * libs/PictureUtils.c (PictureRGBtoPixel):
>             (decompose_mask):
>             Fixed(??) color allocation for some visuals
> --
> 

Not exactly I think. In what follow I assume that you have a screen
which supports only 256 colors (8 bit depth). Can you confirm this?

The point is that a new color limit method has been implemented for
such a screen. New colors tables are used so that it is possible to
use gradient in such screens (and use bg pixmap with a lot of close
colors in Colorset). One pb with these new tables is that they have
not enough grey (so the pb with the calc icon). This may be fixed in
the future. Also colors approximation formulae has changed and I am not
sure that the new one are so good. But remember that with a 8 bit depth
screen fvwm will never use true colors for icons but colors in a table
(and any reasonable app will do the same things with such screens, if
it has to display a lot of colors).

You can still use the "old" table by using the following option
-color-limit 61. Moreover, when the "old" table was build I think that
the (IMHO ugly, do you try wm-icons package :o) icons you use was used
for testing. Unfortunately, you can still have "pbs" because colors
approx was done in a different way (BTW, in two steps one by fvwm and
the other by the xpm lib). 

You may alos try to use dithering: use Colorset in your FvwmButtons:

Colorset 10 bg grey, fg white, ditherIcon

*FvwmButtons: Colorset 10
# remove the Back and Fore colors option
# ... your config

and start fvwm without the "-color-limit" option
(DitherIcon/NoDitherIcon are not dynamic, you should restart the
Buttons after a change).  BTW, ditherIcon is an undocumented Colorset
option because maybe it will be removed. Also, there are not enough
doc about the -color-limit option as the code is not finished.

You may also try to start fvwm with -color-limit 125 or 216.
But you will probably have pbs with certain apps you use
(or fix some pbs with some gtk apps).

Any feedback is really welcome.

Regards, Olivier

--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Tim Freedom <[email-masked]>
Date: Tue, 1 Oct 2002 10:30:48 -0700 (PDT)

On 1 Oct 2002 08:37:31 +0200, Olivier Chapuis wrote:
> [snip snip]
> [snip snip]

Here's the output of 'xdpyinfo'

screen #0:
  dimensions:    1280x1024 pixels (361x289 millimeters)
  resolution:    90x90 dots per inch
  depths (3):    1, 8, 24
  root window id:    0x29
  depth of root window:    8 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x20
  default number of colormap cells:    256
  preallocated pixels:    black 0, white 1
  options:    backing-store YES, save-unders YES
  largest cursor:    unlimited
  current input event mask:    0xd8003d
    KeyPressMask             ButtonPressMask          ButtonReleaseMask        
    EnterWindowMask          LeaveWindowMask          SubstructureNotifyMask   
    SubstructureRedirectMask PropertyChangeMask       ColormapChangeMask       
  number of visuals:    5
  default visual id:  0x22
  visual:
    visual id:    0x22
    class:    PseudoColor
    depth:    8 planes
    available colormap entries:    256

I believe I have a raptor graphics card that is supposed to support alot
more than 256 colors, anyone know how to alter this setting (or to verify
that I'm capable of that) ?

> the other by the xpm lib). 

I'll grab the "beautiful" wm-icons to see what you are talking about :-)
Are you saying that the icons there will not exhibit this problem (use
less gray ?) or simply that they look nicer ?

> # remove the Back and Fore colors option

That looked horrid, so I opted for

  Colorset 10 bg grey59, fg white, ditherIcon

but that still showed the same problem (in both rcalc.xpm and clamp.xpm)

> doc about the -color-limit option as the code is not finished.

Well, in short I don't use gradients (as I see that its a nicety that I
can certainly live without), but I do expect to see my limited 8 icons
to be displayed correctly.  Maybe a 'EnableGradients on/off' might be
something you'd consider.

In any regard, I tried starting fvwm with '-color-limit 61' and that fixed
my icon problems :-).  Is there anyway I can put that option inside of my
.fvwm2rc file ?  Is there any reason why the "ColorLimit" command has been
obsoleted ?

>From fvwm.1

     "ColorLimit limit
           This command is obsolete. See the  -color-limit  option
           to fvwm."

> (or fix some pbs with some gtk apps).

I'm satisfied with '61' colors I guess, no need to expand that number :-)

Thanks for all your help.

 .tf. (please CC replies)

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 1 Oct 2002 23:32:11 +0200

>     SubstructureRedirectMask PropertyChangeMask       ColormapChangeMask       
                ^^^^^^^^

>     available colormap entries:    256
                                     ^^^

> that I'm capable of that) ?

I do not know how many colors can support your card but you run it
with 256 colors only. I know nothing about X with Solaris but with
XFree you can either pass an option to your Xserver (via startx) or
edit the XF86Config config file to set the depth.  With XFree-3 the
option is -bpp the_depth, with XFree-4 it is -depth the_depth. Typical
depth are 2 (2 colors), 4 (8 colors), 8 (256, colors your case), 15
(2^15 colors), 16, 24 and 32. Try man X and man startx. Let us
know if you found the trick.

> less gray ?) or simply that they look nicer ?

I simply say that IMHO they look nicer.

> but that still showed the same problem (in both rcalc.xpm and clamp.xpm)

I do not think it will "solve" your pbs. The icons will look
different. It does not work as there is a bug in the code (at present
time it works only when the button has the Colorset:
*FvwmButtons: (Colorset 10, Icon rcalc.xpm, ...). 
This will be fixed in an incomming snapshot.
 
> to be displayed correctly.

This is a bit arbitrary. The 61 colors tables make a good
approximation of your icons, but the 64 colors table (the default one)
does not make your icons ugly (ask someone which never see these icons
if one of the two FvwmButtons screen shot that you send to the list is
really better than the other one). Also the 64 colors table is a
standard (can be use by gtk, qt and maybe java if you know how to
configure these "libs" and this is important when you need to share
256 colors). Anyway, fvwm let you choose the table you want.

> Maybe a 'EnableGradients on/off' might be
> my icon problems :-).

That is your EnableGradients on/off. But it does not disable gradient,
this is not the point. The point is dithering which is a technique which
allows to multiply colors. It needs special colors tables for fast
rendering.  What we should do is to add some grey colors to these
tables and use it when we do not dither (default for icons).

>  Is there anyway I can put that option inside of my
> .fvwm2rc file ?

No.

> Is there any reason why the "ColorLimit" command has been
> obsoleted ?
>

Yes. A bit technical to explain.

Regards, Olivier

---

From: Dan Espen <[email-masked]>
Date: Tue, 01 Oct 2002 18:03:56 -0400

>   depth of root window:    8 planes
...
> that I'm capable of that) ?

xdpyinfo says your card can do three depths, b/w, 8 bit pseudocolor,
and 24 bit truecolor.  The default however is 8 bit.

How you change this depends on your X server.

On a Sun, there are a few different commands, depending on your
hardware, one of them is m64config, the man page may help.

On Linux, look at your XF86Config file, it should be easy to spot
what needs changing, or use one of the GUIs supplied.

> something you'd consider.

Its not really necessary to do that if you do the -color-limit thingie.
We're still working on the documentation.  One of the issues is
how will the user decide which of the many color limit choices
he should use.

> .fvwm2rc file ?  Is there any reason why the "ColorLimit" command has been

I think this stuff is still under development.
The need for the colorlimit command went away in the 2.4.x release,
the default colorlimiting was usually enough.

I think we still need to work out what the new default should be.

This is a beta, so your opinion, which I think you made clear,
won't be ignored.

> I'm satisfied with '61' colors I guess, no need to expand that number :-)

Olivier,  I don't know if that will help, for one thing it will use
up more colors.  I don't know if we discussed this before, but
the 61 color table had a lot of colors in it that were designed to
evenly fill the gaps in the perceptual (HVC) colorspace.
I believe the new
tables are optimized for gradients by spacing the colors evenly in
a linear colorcube.  That can leave some pretty big gaps in
the perceptual colorspace.

Thats not to say that the 61 color color table won't turn gray
into pink or green, I've seen it do that.

I don't know if we discussed any color theory before, I hope this
stuff makes some sense to you (perceptual and linear colorspaces).
I'm not a color expert, but I did some
study of this stuff when I came up with the original 61 colors
and the matching algorithm.  The matching algorithm in Fvwm is
not the algorithm used to create the 61 color color table, since
the perceptual match algorithm is too slow for Fvwm use.

I still have the source code for the program I used to fill in
the gaps if you're interested.

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 1 Oct 2002 22:22:29 +0000

> I simply say that IMHO they look nicer.

Of course they are nice. :-)

But the real reason is that some of the icon sets were designed to work
well will 8-bit displays. Here is 48x48-infox icons set that will be
included with the next version soon, it uses only 15 colors:

  http://wm-icons.sf.net/tmp/48x48-infox.tar.gz

Regards,
Mikhael.

---

From: Tim Freedom <[email-masked]>
Date: Wed, 2 Oct 2002 14:47:17 -0700 (PDT)

On Tue, 01 Oct 2002 18:03:56 -0400 "Dan Espen" wrote:
> Tim Freedom writes:
> > I believe I have a raptor graphics card that is supposed to support
> > alot more than 256 colors, anyone know how to alter this setting
> > (or to verify that I'm capable of that) ?
> 

OK, after some digging I figured out that the video card on the Sun-Ultras
here is set to 8+24 depth (that is 8 __and__ 24 bit) -- in other words its
24-bit enabled, but is capable of showing 8-bit only applications (in case
those applications check, I guess).

Here's the video command and the output,

  $ pgxconfig -prconf

  --- Hardware Configuration for /dev/fbs/gfxp0 ---
  Type: GFX8P
  Board: TSI Raptor GFX 8P
  PROM Information: 1.11 99/07/06 TSI
  DAC: TSI RAMDAC 0x31
  RAM: 8MB
  EDID Data: 1024x768x85, 800x600x85, 640x480x85, 1152x864x85,
  1600x1200x85, 1600x1200x75, 1800x1440x75, 640x480x60, 640x480x75,
  800x600x60, 800x600x75, 1024x768x60, 1024x768x75, 1280x1024x75
  Current resolution setting: 1280x1024x75
  Possible depths: 8, 24, 8+24
  Current depth: 8+24

and

  $ pgxconfig -propt

  --- OpenWindows Configuration for /dev/fbs/gfxp0 ---
  OWconfig: system
  Video Mode: none
  Depth: 24

OK, does 24-bit really work, well I did the following,

  xv -24 -best -perfect -cmap -cgeom -0-0 kittens.jpg

And in the "XV Controls" window it notes using "24-bit mode. Using TrueColor
visual" meaning the solaris Xserver (Xsun) is capable of 24-bit.  So I asked
a sys-admin friend and he noted that "xdpyinfo is probably unable to
understand 8+24 mode and is simply returning the first result it sees when
multiple options are available."  So I'm not sure how fvwm determines what
the X-server is capable of, but its figuring them to be 8-bit on this
machine when they really need to be 24-bit (is it grabbing xdpyinfo's
output ?).  Anything I can do to make fvwm resolve to 24-bit short of
restarting the server with that depth setting explicitly (meaning I'd
have to call the powers that be to change the configuration on this
machine - after a million+1 questions) ?  What do other window managers
(like CDE) do to resolve this ?

Thanks

 .tf. (please CC replies)

---

From: Dan Espen <[email-masked]>
Date: Wed, 02 Oct 2002 19:04:58 -0400

> those applications check, I guess).

Gee, pretty neat video card.
I don't have any experience with it.
>From the fvwm man page, it looks like you might be able
to use either the -visual or -visualId argument to force fvwm to
use a specific visual.

---

From: Tim Freedom <[email-masked]>
Date: Wed, 2 Oct 2002 17:41:44 -0700 (PDT)

On Wed, 02 Oct 2002 19:04:58 -0400 "Dan Espen" wrote:
> 
> Tim Freedom writes:
> > OK, after some digging I figured out that the video card on the
> > Sun-Ultras here is set to 8+24 depth (that is 8 __and__ 24 bit).
> > In other words its 24-bit enabled, but is capable of showing 8-bit
> > only applications (in case those applications check, I guess).
> 

A couple of things (I must be cursed or something :-) I get the same
"odd" results using either method noted above (ie. visual or visualId).

1. You might want to apply the following patch for all those '-visual'
   options to work (it currently looks only for the first letter on
   most of the visual options and so if you have "truecolor" that will
   not trigger anything -- contrary to what the man page says; ie.
   truecolor should work as an option).  Otherwise do a string crawl to
   compare only the first character of the word or something.

#### PATCH BEGIN ####
--- ./fvwm/fvwm.c.old	Wed Oct  2 17:18:54 2002
+++ fvwm/fvwm.c	Wed Oct  2 17:21:41 2002
@@ -1786,27 +1786,27 @@
 			{
 				usage();
 			}
-			if (StrEquals(argv[i], "staticg"))
+			if (StrEquals(argv[i], "staticgray"))
 			{
 				visualClass = StaticGray;
 			}
-			else if (StrEquals(argv[i], "g"))
+			else if (StrEquals(argv[i], "grayscale"))
 			{
 				visualClass = GrayScale;
 			}
-			else if (StrEquals(argv[i], "staticc"))
+			else if (StrEquals(argv[i], "staticcolor"))
 			{
 				visualClass = StaticColor;
 			}
-			else if (StrEquals(argv[i], "p"))
+			else if (StrEquals(argv[i], "pseudocolor"))
 			{
 				visualClass = PseudoColor;
 			}
-			else if (StrEquals(argv[i], "t"))
+			else if (StrEquals(argv[i], "truecolor"))
 			{
 				visualClass = TrueColor;
 			}
-			else if (StrEquals(argv[i], "d"))
+			else if (StrEquals(argv[i], "directcolor"))
 			{
 				visualClass = DirectColor;
 			}
#### PATCH END ####

2. I also tried to start with '-visualId' set to 0x26 since xdpyinfo
   notes,

    ...
    visual id:    0x25
    class:    StaticGray
    depth:    8 planes
    available colormap entries:    256
    red, green, blue masks:    0x0, 0x0, 0x0
    significant bits in color specification:    8 bits
  visual:
    visual id:    0x26
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits

In either case, I get the following stderr output - what does it
mean ?

 [FVWM][FvwmErrorHandler]: <<ERROR>> *** internal error ***
 [FVWM][FvwmErrorHandler]: <<ERROR>> Request 72, Error 8, EventType: 0
 [FVWM][FvwmErrorHandler]: <<ERROR>> *** internal error ***
 [FVWM][FvwmErrorHandler]: <<ERROR>> Request 72, Error 8, EventType: 0
 [FVWM][FvwmErrorHandler]: <<ERROR>> *** internal error ***
 [FVWM][FvwmErrorHandler]: <<ERROR>> Request 72, Error 8, EventType: 0

And all my FvwmButtons are rather scrambled and ... well take a look for
yourself - a small image is attached.  Otherwise all else seems ok.

What am I doing wrong ?

Using snap-20020926

Thanks

 .tf. (please CC replies)

---

From: Tim Freedom <[email-masked]>
Date: Wed, 2 Oct 2002 17:43:50 -0700 (PDT)

Damn it - I forgot to attach the image again.  Sorry about this.

 .tf.

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 3 Oct 2002 11:03:27 +0200

> "odd" results using either method noted above (ie. visual or visualId).

Well, running fvwm 2.5.x in a different visual than the default visual is
totally broken at present time (but with depth <= 8 and a dynamic
visual class (PseudoColor, GreyScale and DirectColor)). I hope that
this will be fixed in a few days.

>  [FVWM][FvwmErrorHandler]: <<ERROR>> Request 72, Error 8, EventType: 0

This says that XPutImage fail (parameter mismatch, a gc problem I guess
when loading an xpm) and it is the reason of your icon pbs in FvwmButtons.
 
> yourself - a small image is attached.  Otherwise all else seems ok.

Hum, Do you use some xpm image in others place (menus, Icon and MiniIcon
style?). I guess that no xpm image will be displayed fine.
 
> What am I doing wrong ?

In theory you do nothing wrong, you just fall on a bug. The 2.5.x
series is **alpha-alpha** at present time. In practice, I am not sure
it is a good idea to run fvwm with a visual != than the default
visual.

> (like CDE) do to resolve this ?

If you start fvwm without -visual{Id} it asks the server for the
default visual and use it (I do not think that fvwm is broken here; it
does not grep xdpyinfo, it uses the X library).  But, why you do
not always start your Xserver with 24-bit set explicitly?  I've no
experience with 8+24 depth video cards, but it seems to me that the
depth 8 is useful for applications which work only with a depth 8
dynamic visual (PseudoColor) because, for example, the application
needs read-write colors. So, if you do not use such apps or if you use
such apps which can found this depth 8 visual alone or via an option I
think you should start your Xserver with 24-bit. 

Others reasons to do not use 24-bit by default:
- This may use more memory (???)
- Your Xserver driver is not accelerated with this mode.

In abstract if you do not have good reasons to do not use 24-bit
by default, use it!

So now if you have a good reason for using 8-bit by default either
- Do not use the -visual{Id} option (fvwm with 256 colors,
maybe when fvwm will become beta the -color-limit 61 option
will be not needed).
- Use the -visual{Id} option (wait a few days for 2.5.x or use
fvwm-2.4.11).

Regards, Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 3 Oct 2002 13:35:23 +0200

On Thu, Oct 03, 2002 at 11:03:27AM +0200, Olivier Chapuis wrote:
> does not grep xdpyinfo, it uses the X library).

Ooops, Non. fvwm try to found the "best" visual. So there is a
problem here.

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 3 Oct 2002 14:16:46 +0200

> Ooops, Non. fvwm try to found the "best" visual. So there is a
                              ^
Ooops, Ooops, Ooops. Put this | mail in your trash ... And this
one too.

Sorry, Olivier

---

From: Tim Freedom <[email-masked]>
Date: Thu, 3 Oct 2002 09:58:37 -0700 (PDT)

> this will be fixed in a few days.

In a really absurd way, I'm happy to hear that :-)  At least its nothing
very particular with my setup and is something that is visible elsewhere.
I'll keep posted for a fix to give it a try.

> style?). I guess that no xpm image will be displayed fine.

I think there are like 3-4 menu icons that I played with at some point
and simply left-in to show people (you know to wow 'em :-)  Is that a
problem ?  Should I remove 'em ?  If you'd like me to run some debug code
for ya, don't hesitate to let me know.

> it is a good idea to run fvwm with a visual != than the default

Are you saying that running with a visual != default visual is a bad
idea now or in general ?  I can see why the "now" would makes sense, but
if it were an "in general" statement, then I don't really know what
to say.

> think you should start your Xserver with 24-bit. 

I use a great deal of third-party applications and I'm not sure which
require 8-bit and which don't.  If I were to restart the Xserver in
24-bit, I'd require the help of the sys-admins here (which usually turn
into a brief interrogation) and if things don't work I will be on very
shaky ground to ask 'em to revert me back (you know that "evil eye" thing),
etc (the option of me controlling that setting/file is not much of an
option - don't ask).

> Others reasons to not use 24-bit by default:

Simply put, don't want to deal with the appropriate authorities :-)
due to hassle since its nothing that I personally control.  Its not
technical at all.

> - Use the -visual{Id} option (wait a few days for 2.5.x or use

I've grabbed 2.4.11 and will keep an eye out for a commit that addresses
visuals to grab a snapshot (2.4.11 worked great btw).  Do let me know if
I can help.

 .tf. (please CC replies)

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 3 Oct 2002 19:30:45 +0200

> does not grep xdpyinfo, it uses the X library).

In fact I do not know what we should do with a card with 2 depths
for a given visual. I found nothing in the X lib (or in the Xevi
extension) for such a situation. I imagine that there is an X extension
to deal with this situation and we should use it to choose the desired
depth.

Olivier

---

From: Dan Espen <[email-masked]>
Date: Thu, 03 Oct 2002 14:02:33 -0400

> to deal with this situation and we should use it to choose the desired

Why shouldn't the Fvwm command line arg work as advertised?