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:
> > 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
