RFC: Using Composite for pseudocolor visual emulation

[Adam Jackson]

This would be a fairly cool feature, and I've looked at it before and
walked away in disgust.  I looked into it again over the weekend and I
want to write down why I'm having trouble with it; maybe someone has
ideas.

Basically, there's an ordering issue.

1: The driver calls miSetVisualTypes and fbScreenInit to set up a list
of supported visuals.  In the cases we're interested in, this is rgb565
or xrgb8888.  Obviously if we were c8 already we wouldn't care about
emulating c8 visuals.

2: The driver calls fbPictureInit to configure the list of Render
formats.  This gives us formats for a1, x4a4, and [xa]{rgb,bgr}8888 as
required by the protocol, and then also a pile of formats matching the
available visuals.

3: Composite initialization attempts to add synthetic visuals for which
there is not already an existing visual.  To do so, it needs to find a
Render format for that depth; but there won't _be_ a c8 Render format,
because it's not demanded by the protocol, and there's no existing
visual for it because that's the problem we're trying to solve!

What if, in fbPictureInit, we just always created a c8 format?  Well,
you have this in picture.h:

/*
 * gray/color formats use a visual index instead of argb
 */
#define PICT_VISFORMAT(bpp,type,vi)     (((bpp) << 24) |  \
                                         ((type) << 16) | \
                                         ((vi)))

which sort of implies that the visual need already _exist_.  Maybe you
could create one with vi==0 and then fix it up later in Composite?  Iff
there's not already c8 formats, of course.

But then you run into PictureInitIndexedFormats in PictureFinishInit,
which attempts to find a visual for each indexed format that doesn't
correspond to the root window visual, so it can create a colormap for
the format.  Which you can't _do_ yet, because the visual won't actually
exist until Composite init, which is later because it has to be after
Render init.  Presumably you could case out here as well for when vi==0,
and then fix it up in Composite.

Still, as with all the visual channel mask fixups in the drivers, I'm
left wondering why we have core code that does the wrong thing and then
useful code that fixes it later, instead of just getting it right in the
first place.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-devel/attachments/20091102/ad58cb3c/attachment.pgp