Hi Steve, Laurent,

On Wed, 2021-01-06 at 09:51 -0800, Steve Longerbeam wrote:

Hi Laurent,

I guess I have fallen behind the times with v4l2, but I wasn't aware 
that the /dev/video nodes and VIDIOC_* APIs are now considered legacy!

I don't think Laurent considers the video node legacy, just the fact
that the current implementation looks at the subdev source pad's active
format in ENUM_FRAMESIZES and ENUM_/G/S/TRY_FMT.

I see the behavior of VIDIOC_ENUM_FMT was extended/defined for MC-
centric devices last year, to allow enumerating all pixel formats or
filter pixel formats for a given mbus format:

e5b6b07a1b45 ("media: v4l2: Extend VIDIOC_ENUM_FMT to support MC-centric devices")
cfe9e707c564 ("media: open.rst: document mc-centric and video-node-centric")

Steve

On 1/5/21 7:27 AM, Laurent Pinchart wrote:

quoted

The i.MX media drivers implement a legacy video node API, where the
format of the video node is influenced by the active format of the
connected subdev (both for enumeration and for the get, set and try
format ioctls), and where controls exposed by the subdevs in the
pipeline are inherited by the video node.

But I don't quite understand why G/S/TRY_FMT should not respect the
connected subdev source pad's active format. Should MC-centric devices
allow to set non-working configurations and only error out on stream
start? Is this documented?

The current "legacy" vb2_ops check the subdev in ENUM_FRAMESIZES and
ENUM_FRAMEINTERVALS, and in TRY_FMT/S_FMT to determine format and
possible interlacing options. If the MC-centric ops just drop that,
there is no way to determine which interlacing combinations are actually
supported.

regards
Philipp