Re: FVWM: Re: Colormap issues

From: Olivier Chapuis <olivier.chapuis_at_free.fr>
Date: Thu, 3 Oct 2002 11:03:27 +0200

On Wed, Oct 02, 2002 at 05:41:44PM -0700, Tim Freedom wrote:
> 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).
> >
> > 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.
>
> 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).
>

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.

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

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.
 
> And all my FvwmButtons are rather scrambled and ... well take a look for
> 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.
In an other mail you wrote:

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

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
--
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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Thu Oct 03 2002 - 04:19:08 BST

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:37:53 BST