[PATCH xserver 02/10] glamor: Require that 16bpp pixmap depths match for Render copies.

[Michel Dänzer]

On 22/09/16 05:45 PM, Eric Anholt wrote:
> The copy optimization in d37329cba42fa8e72fe4be8a7be18e512268b5bd
> replicated a bug from last time we did a copy optimization, and didn't
> get rendercheck run on it.  This is effectively a re-cherry-pick of
> 510c8605641803f1f5b5d2de6d3bb422b148e0e7.
> 
> Fixes rendercheck -t blend -o src -f x4r4g4b4,x3r4g4b4
> 
> Signed-off-by: Eric Anholt <eric at anholt.net>
> ---
>  glamor/glamor_render.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
> index c590580412c9..26dee05b5ce1 100644
> --- a/glamor/glamor_render.c
> +++ b/glamor/glamor_render.c
> @@ -1423,6 +1423,12 @@ glamor_composite_clipped_region(CARD8 op,
>      /* Is the composite operation equivalent to a copy? */
>      if (!mask && !source->alphaMap && !dest->alphaMap
>          && source->pDrawable && !source->transform
> +        && source->pDrawable->depth == dest->pDrawable->depth

This clause ensures the depths match...


> +        /* We can't do direct copies between different depths at 16bpp
> +         * because r,g,b are allocated to different bits.
> +         */
> +        && !(dest->pDrawable->bitsPerPixel == 16 &&
> +             dest->pDrawable->depth != source->pDrawable->depth)

So this clause will always be true?


Anyway, this patch doesn't fix

 rendercheck -t blend -o src -f x4r4g4b4,x3r4g4b4

for me. Am I missing another patch? (Patch 1 of this series is a NOP,
right?)


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer