On Fri, 2019-02-08 at 10:15 +0100, Hans Verkuil wrote: > On 2/8/19 4:18 AM, Vivek Kasireddy wrote: > > Buffers generated with YUV32 format seems to be incorrect, hence use > > VUYA32 instead. > > > > Cc: Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> > > Signed-off-by: Vivek Kasireddy <vivek.kasireddy@xxxxxxxxx> > > Philipp, I wonder whether VUYA32 or VUYX32 should be used? I think the alpha > channel is completely ignored on the source side and on the destination side > it is probably set by some fixed value? > > Note that there exists a control V4L2_CID_ALPHA_COMPONENT that can be used > to let userspace specify the generated alpha value. Oh, that is correct. V4L2_CID_ALPHA_COMPONENT is wired up in the imx-pxp driver to the alpha output override, and the value correctly appears in the VUYA32 output. > What if both source and destination formats have an alpha channel? Can the > hardware preserved the alpha values? The hardware should support preserving the alpha channel, but the driver currently always enables the V4L2_CID_ALPHA_COMPONENT override. Right now it would be correct to allow only VUYX32 on the output queue and both VUYA32 and VUYX32 on the capture queue. For VUYA32 on the output queue we'd have to disable the alpha override and check whether the hardware properly preserves the alpha channel. regards Philipp
