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@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