Writeback Assumptions for XRGB

[Maxime Ripard]

Hi!

On Tue, Mar 08, 2022 at 10:26:24AM +0200, Pekka Paalanen wrote:
> On Fri, 4 Mar 2022 15:46:07 +0100
> Maxime Ripard <maxime at cerno.tech> wrote:
> 
> > Indeed, while the input buffer uses 0xff for the X component, we'll get
> > back 0x00 from the hardware, and thus the hashes are not identical. We
> > can force the hardware to always set it to 0xff, but that doesn't seem
> > right. It would make more sense to ignore the X component entirely in
> > that case.
> 
> Hi,
> 
> I tried hard to send a slightly longer response, but gmail refuses to
> deliver to anyone without explanation.

For reference (and archives), this was your original message:

> > if a pixel component is marked X, then its value must not have any
> > observable effect when passed over an interface to another
> > component. To me there is no doubt about that.
> >
> > OTOH, if both output and writeback FBs had ARGB instead of XRGB,
> > things would be more complicated. Quite likely the CRTC background
> > color is opaque (or maybe HDMI and DP cannot transmit alpha meaning
> > that writeback with alpha < 1.0 makes no sense), which means that no
> > matter what A values goes in, writeback A will always come out as
> > 0xff (on 8 bpc). One might be able to argue otherwise on this.
> >
> > I would actually recommend IGT to put pseudo-random garbage on X
> > channels to catch drivers and hardware that unexpectedly uses the X
> > values. I've used this trick with weston-simple-shm:
> > https://ppaalanen.blogspot.com/2012/04/improved-appearance-for-simplest.html
> >
> > Pixel component values 0x00 and 0xff are weak for testing blending
> > and composition.
>
> So here's a summary of my opinion:
> 
> - KMS must ignore X channel contents on read
> - IGT must ignore X channel contents when comparing results
> - it would be nice if IGT filled image X channels with garbage to
>   verify the first two points

That works for me :)

I'll work on a series of patches addressing this then

Thanks!
Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20220308/c17f310c/attachment-0001.sig>