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@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
