[PATCH xserver 3/3] render: Fix default picture format initialization

[Adam Jackson]

On Fri, 2018-02-23 at 15:57 -0800, Keith Packard wrote:

> > You might be right that we _should not_ expose formats not present in
> > the hardware, though Render has kinda already lost that fight by making
> > a1 and a4 mandatory. But the Render code today, and forever, is making
> > the assertion that the code above it _will_ handle these formats.
> 
> We just need to make sure we don't promise to store bits beyond the
> depth of the drawable.

So let's again consider:

  pict format:
        format id:    0x2b
        type:         Direct
        depth:        30
        alpha:         0 mask 0x0
        red:          16 mask 0xff
        green:         8 mask 0xff
        blue:          0 mask 0xff

What exactly does an 'x' channel mean in Render? Is it "alpha wired to
1.0"? If so, is that true for writes as well as reads? If so, is there
any GL hardware that's going to let you write to only six bits of .x?

We also have:

  pict format:
        format id:    0x27
        type:         Direct
        depth:        32
        alpha:         0 mask 0x0
        red:          16 mask 0xff
        green:         8 mask 0xff
        blue:          0 mask 0xff
  pict format:
        format id:    0x2a
        type:         Direct
        depth:        24
        alpha:         0 mask 0x0
        red:          16 mask 0xff
        green:         8 mask 0xff
        blue:          0 mask 0xff

If you're saying both "the format promises not to write to bits beyond
the given depth" and "x is a=1.0", then 0x27 might write to the x bits,
but 0x2a would not. I'm reasonably confident that's not what glamor
implements since we're never calling glColorMask; I'm fairly sure
that's not what fb/pixman implements either.

- ajax