Le samedi 05 novembre 2022 à 23:19 +0800, Hsia-Jun Li a écrit : > > > VIDIOC_ENUM_EXT_PIX_FMT would report NV12 and NV12M, while > > > VIDIOC_ENUM_FMT > > > would just report NV12M. > > > > If NV12 and NV12M are equivalent in Ext API, I don't see why we would > > report both (unless I'm missing something, which is probably the case). > > > > The idea was to deprecate the M-variants one day. > I was thinking the way in DRM API is better, always assuming it would > always in a multiple planes. The only problem is we don't have a way to > let the allocator that allocate contiguous memory for planes when we > need to do that. Its not too late to allow this to be negotiated, but I would move this out of the pixel format definition to stop the explosion of duplicate pixel formats, which is a nightmare to deal with. If I simplify the discussion, we want to negotiate contiguity with the driver. The new FMT structure should have a CONTIGUOUS flag. So if userpace sets: S_FMT(NV12, CONTIGUOUS) The driver can accepts, and return the unmodified structure, or may drop the CONTIGUOUS flag, which would mean its not supported. Could be the other way around too. As for allocation, if you have CONTIGUOUS flag set, userspace does not have to export or map memory for each planes, as they are the same. We simply need to define the offset as relative to their allocation, which I think is the most sensible thing. Nicolas
