[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Colormap issues with mozilla on 8-bit screen - XRENDER extension?



On Sun, Mar 28, 2004 at 08:48:37PM +0100, Julian Gilbey wrote:
> I've got an interesting problem.  I've recently upgraded my XWindows
> packages and mozilla (all in unstable) from about a month ago, and now
> mozilla can't get a decent set of colo(u)rs.  I'm working on an 8-bit
> display :-/ and I remember Branden saying something a while back about
> possible issues with the XRENDER library hogging 6x6x6=216 of the
> available colo(u)rs.  Could this be part of this problem, and if so,
> is there a way to disable it at runtime to test this theory?

Hmm, I thought the color cube was made smaller in XFree86 4.3.0.

Michel Dänzer suggested 'Option "RenderColormapMode"'.

Unfortunately, this option is *completely* undocumented, but a bit of
source grepping turns up:

  { FLAG_RENDER_COLORMAP_MODE,  "RenderColormapMode",           OPTV_STRING,
        {0}, FALSE },

...so we know it takes a string argument.

int
PictureParseCmapPolicy (const char *name)
{
    if ( strcmp (name, "default" ) == 0)
        return PictureCmapPolicyDefault;
    else if ( strcmp (name, "mono" ) == 0)
        return PictureCmapPolicyMono;
    else if ( strcmp (name, "gray" ) == 0)
        return PictureCmapPolicyGray;
    else if ( strcmp (name, "color" ) == 0)
        return PictureCmapPolicyColor;
    else if ( strcmp (name, "all" ) == 0)
        return PictureCmapPolicyAll;
    else
        return PictureCmapPolicyInvalid;
}

So it looks like acceptable values are "default", "mono", "gray",
"color", and "all".

If someone would care to explain the meanings of those to me, I'd be
happy to write a patch to XF86Config.man to document it.

-- 
G. Branden Robinson                |    I'm sorry if the following sounds
Debian GNU/Linux                   |    combative and excessively personal,
branden@debian.org                 |    but that's my general style.
http://people.debian.org/~branden/ |    -- Ian Jackson

Attachment: signature.asc
Description: Digital signature


Reply to: