Re: Colormap Issue with Gtk99.3

[Owen Taylor <owt1 cornell edu>]

Jay Bloodworth <jay@pathways.sde.state.sc.us> writes:

> Yesterday I installed Marc's RPMs for gnome and all it's required
> components.  Unfortunately, every gnome program (in fact every gtk
> program) that I attempted to run would segfault on startup.  So I go the
> source for gtk, so I could add a few g_prints and see what was going on.
> Many recompiles later, I narrowed the problem down to the following
> function call in gdk_colormap_get_system in gdkcolor.c:
> 
>       XQueryColors (gdk_display, private->xcolormap, xpalette, 
>                     private->visual->colormap_size);

> All of the pointers are valid when this function is called.  The problem
> seems to be that private->visual->colormap_size is equal to 2048, while
> xpalette is statically sized to 256.  By way of confirmation, I hardcoded
> 256 into the function call rather than the variable and then gnomine and
> the hello world program I'd been using for testing seemed to work fine.
> 
> Note that I am running a beta X server from Suse at 32bpp(for the Permedia
> 2 chip)  rather than XFree.  xdpyinfo reports the value 2048 for entries
> per colormap on this serevr as well.  On my other machine, running
> XFree3.3.1 (Matrox Millenium), also at 32bpp xdpyinfo reports 256 slots
> per colormap (and the gnome rpms work 'out of the box').

[ This really belongs on gtk-list ]

Most interesting... could you provide the complete output
of xdpyinfo? Does the server actually provide 2048 slot colormaps
in pseudo-color mode? (That would be cool, but most unusual)

I'm not really sure that that GDK should be querying
the colormap when the default visual is a TRUE_COLOR visual,
as I assume is the case here. 

The mismatch between xpalette and private->visual->colormap_size
is definitely a bug, and I think hardcoding in 256 wouldn't be
wrong. But since I'd like to get GTK's color functions doing
the right thing on more unusual hardware, I'd rather understand
what's going on here.

> I see two possible ways to fix this, either of which I'd be happy to do
> myself.   Either the XQueryColors call that is choking can be hardcoded
> with 256, or the colormap infrastructure of gtk can be revamped to
> allocate enough slots based on what the server provides.  Though the
> latter is obviously more robust, I don't know enough about X to know if it
> is "The Right Thing To Do" (tm).  If the 2048 value in the Suse server is
> a bug (or an ill-conceived feature), I don't know that gtk ought to have
> big changes to work around it.

If X allows the value not to be 256, then GTK should work with it.

Regards,
                                        Owen