On Tue, Apr 21, 2020 at 03:57:40PM +0200, Niklas Söderlund wrote: > From: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > > The VIDIOC_ENUM_FMT ioctl enumerates all formats supported by a video > node. For MC-centric devices, its behaviour has always been ill-defined, > with drivers implementing one of the following behaviours: > > - No support for VIDIOC_ENUM_FMT at all > - Enumerating all formats supported by the video node, regardless of the > configuration of the pipeline > - Enumerating formats supported by the video node for the active > configuration of the connected subdevice > > The first behaviour is obviously useless for applications. The second > behaviour provides the most information, but doesn't offer a way to find > what formats are compatible with a given pipeline configuration. The > third behaviour fixes that, but with the drawback that applications > can't enumerate all supported formats anymore, and have to modify the > active configuration of the pipeline to enumerate formats. > > The situation is messy as none of the implemented behaviours are ideal, > and userspace can't predict what will happen as the behaviour is > driver-specific. > > To fix this, let's extend the VIDIOC_ENUM_FMT with a missing capability: > enumerating pixel formats for a given media bus code. The media bus code > is passed through the v4l2_fmtdesc structure in a new mbus_code field > (repurposed from the reserved fields). With this capability in place, > applications can enumerate pixel formats for a given media bus code > without modifying the active configuration of the device. > > The current behaviour of the ioctl is preserved when the new mbus_code > field is set to 0, ensuring compatibility with existing userspace. The > API extension is documented as mandatory for MC-centric devices (as > advertised through the V4L2_CAP_IO_MC capability), allowing applications > and compliance tools to easily determine the availability of the > VIDIOC_ENUM_FMT extension. > > Signed-off-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@xxxxxxxxxxxx> > Reviewed-by: Hans Verkuil <hverkuil-cisco@xxxxxxxxx> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@xxxxxxxxxxxx> Acked-by: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> -- Sakari Ailus
