Skip to content

glamor: Fix xRGB->ARGB composite in certain cases

Isaac Bosompem requested to merge mrisaacb/xserver:glamorcomposite into master

I came across an issue when experimenting with XWayland/Glamor in rootless mode. In rootless mode, when a window of depth 32 is created and used, compNewPixmap will do a composition operation from the screen pixmap to the newly allocated one.

With this in mind we end with a case that has (see compNewPixmap for the different depth case):

  • 0x0 source/screen pixmap (xRGB, 24)
  • 960x600 dest pixmap (ARGB, 32)
  • PictOpSrc
  • RepeatNone repeat mode on src

The source pixmap will be expanded by glamor_convert_gradient_picture (see glamor_composite_clipped_region) and then used for the subsequent composition operation. This will result in the destination surface being filled with fully opaque black pixels (as it is doing a straight conversion of xRGB->ARGB).

However, forcing Glamor to bail on this and use software composition results in transparent pixels being written into the destination.

It says from the spec:

  1. Source and Mask Transformations

When fetching pixels from the source or mask pictures, Render provides four options for pixel values which fall outside the drawable (this includes pixels within a window geometry obscured by other windows).

  • None. Missing values are replaced with transparent.

Given this, I would assume all pixels fetched from the source would be outside the drawable for RepeatNone?

The patch I've provided here will enable RepeatFix and use the original pixmap for the bounds calculations to resolve this case.

Edited by Isaac Bosompem

Merge request reports