CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe.I wonder whether we need to keep the pixel formats in videodev2.h anymore. If we would like to use the modifiers from drm_fourcc.h, why don't we use their pixel formats, they should be the same values of non-M variant pixel formats of v4l2.
Le samedi 05 novembre 2022 à 23:19 +0800, Hsia-Jun Li a écrit :
I was thinking the way in DRM API is better, always assuming it wouldVIDIOC_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.
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.
negotiate contiguity with the driver. The new FMT structure should have aI wonder whether we would allow some planes being contiguous while some would not. For example, the graphics planes could be in a contiguous memory address while its compression metadata are not.
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