Subject: Re: xsrc/31163
To: None <,,>
From: Michael Lorenz <>
List: netbsd-bugs
Date: 09/06/2005 10:40:02
The following reply was made to PR xsrc/31163; it has been noted by GNATS.

From: Michael Lorenz <>
To: Martin Husemann <>
Cc:, NetBSD GNATS <>
Subject: Re: xsrc/31163
Date: Tue, 6 Sep 2005 06:39:19 -0400

 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
 > Nope, it's not that simple. True, the "depth" argument returned from
 > setup_visual() is not passed to open_window() - but after changing
 > that (and using the new arg in open_window) it still fails on first
 > color allocation. There must be more to it...
 Yes, X also wants a colour map. You can't inherit it because the parent
 as a 24bit window doesn't have one and DefaultColormap() doesn't
 something suitable either as long as the default visual is 24bit.=20
 > So there are two things:
 >  (1) the app is easily fixed by making the check for
 >      DefaultVisual()->class accept TrueColor as well as PseudoColor
 It does, but it checks for PseudoColor availability first and since
 that's available on ffb it tries to use it.
 >  (2) if the server returns a visual array including a PseudoColor 8
 >      bit depth visual, it should be usable - it's a server error,
 >      otherwise (and the failure is internal, isn't it?)
 No. The server wants a colour map on window creation if it can't inherit
 one somewhere ( that's ancient code in Xserver/dix/window.c ). In this
 case things should Just Work(tm) when xuvmstat would just pick the
 TrueColor visual or inherit both depth and visual.
 have fun
 Content-Type: application/pgp-signature
 Version: GnuPG v1.4.0 (NetBSD)