On Thu, 2018-09-06 at 12:54 +0200, Hans Verkuil wrote: [...] > > The application usually doesn't need to know whether the driver changed > > the requested ycbcr_enc because it doesn't have CSC matrix support at > > all, or because it doesn't implement a specific conversion. And if the > > application needs to know for some reason, it can always check > > VIDIOC_ENUM_FMT. > > > > > I don't think so, but I think that > > > is already true for the existing flag V4L2_PIX_FMT_FLAG_PREMUL_ALPHA. > > > > The only drivers using V4L2_PIX_FMT_FLAG_PREMUL_ALPHA I can see are > > vsp1_brx and vsp1_rpf. They never write to the v4l2_pix_format flags > > field. > > But they honor it. The problem is that I can set this flag and call S_FMT > on e.g. the vivid driver, and S_FMT will return the flag. But it actually > doesn't use the flag at all, so userspace has no way of knowing if the > flag is actually used. Userspace can see if its requested colorspace, etc. were changed by the driver, though. > Although it can call G_FMT and then the flag is cleared. So if drivers were to clear the flag, would they clear it if they don't support the flag at all, or also if they support the flag in principle, but can't convert into the specific requested value? Would all drivers have to be modified to clear those flags? I suppose rather the framework should be extended to set the flags on ENUM_FMT and to mask the TRY/S_FMT flags with those. > > > I wonder if V4L2_PIX_FMT_FLAG_PREMUL_ALPHA should also get an equivalent > > > flag for v4l2_fmtdesc. > > > > Isn't this useless to introduce after the fact, if there are already > > applications that use this feature? They can't depend on the existence > > of this flag to check for support anyway. > > Those applications are already hardcoded for the vsp1. So they won't break > by adding v4l2_fmtdesc flags. > > But apps like gstreamer and friends can start using these flags and deduce > what the HW is capable of. I see. In that case I agree. regards Philipp
