Hi Philipp,
(CC'ing Sakari)
On Mon, Jan 11, 2021 at 09:40:17AM +0100, Philipp Zabel wrote:
> On Sat, 2021-01-09 at 03:09 +0200, Laurent Pinchart wrote:
> > Could you elaborate a little bit here ? We don't have an API to
> > explicitly enumerate supported interlacing types. This can be done by
> > calling VIDIOC_TRY_FMT with all field types and see which ones are
> > supported. You can still do so with the MC-based API, the video node
> > will return from VIDIOC_TRY_FMT the interlacing types intrinsicly
> > supported by the video node, and you can query from the source subdev
> > the interlacing types supported by the source. Userspace can then
> > combine the information to find what is supported.
>
> The i.MX6 CSI always captures whole frames, so SEQ_TB or SEQ_BT at its
> source pad.
> The IDMAC supports "interlaced scan" of SEQ_TB into INTERLACED_TB and
> SEQ_BT into INTERLACED_BT when writing to memory. It can't change the
> field timing order (BT <-> TB) as that was already decided at the CSI.
>
> So for capture of interlaced material, the video device currently allows
> either SEQ_TB and INTERLACED_TB or SEQ_BT and INTERLACED_BT, depending
> on which field order is configured at the CSI source pad.
>
> See d969291d8479 ("media: imx: Fix field negotiation") for details.
Thanks for the explanation.
With the MC-based API, and unless I'm mistaken, userspace can determine
what interlacing options are supported as follows. Sakari, please feel
free to confirm, or infirm.
- The video node would report support for V4L2_FIELD_NONE,
V4L2_FIELD_SEQ_(TB|BT) and V4L2_FIELD_INTERLACED_(TB|BT).
- The CSI subdev's source pad would report V4L2_FIELD_NONE for
progressive sources, and V4L2_FIELD_ALTERNATE for interlaced sources.
At the bus level top and bottom frames alternate, so
V4L2_FIELD_SEQ_(TB|BT) isn't valid as it's defined based on buffers.
V4L2_FIELD_INTERLACED_(TB|BT) isn't valid either in this case when
frames alternate between top and bottom (they're not interleaved on
the bus).
- When starting the video stream, the driver would reject a mismatch
between the source pad and the video node (V4L2_FIELD_NONE on the
source pad and V4L2_FIELD_SEQ_* or V4L2_FIELD_INTERLACED_* on the
video node, or the other way around).
- From a userspace point of view, the fact that both V4L2_FIELD_SEQ_*
and V4L2_FIELD_INTERLACED_* are supported on the video node (which can
be queried using VIDIOC_S_FMT or VIDIOC_TRY_FMT) means that the DMA
engine can interleave interlaced content. If the IDMAC wasn't able to
interleave lines, but was only able to capture the two fields
sequentially in the same buffer, it would only report
V4L2_FIELD_SEQ_*, not V4L2_FIELD_INTERLACED_*.
Does this make sense ?
--
Regards,
Laurent Pinchart
