From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: "Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>
Cc: Helen Koike <helen.koike@collabora.com>,
Hans Verkuil <hverkuil@xs4all.nl>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
linux-media@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Hans Verkuil <hverkuil-cisco@xs4all.nl>
Subject: Re: [PATCH v8 3/6] media: v4l2: Extend VIDIOC_ENUM_FMT to support MC-centric devices
Date: Wed, 22 Apr 2020 20:26:37 +0300 [thread overview]
Message-ID: <20200422172637.GF5381@paasikivi.fi.intel.com> (raw)
In-Reply-To: <20200421135743.1381930-4-niklas.soderlund+renesas@ragnatech.se>
On Tue, Apr 21, 2020 at 03:57:40PM +0200, Niklas Söderlund wrote:
> From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> 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@ideasonboard.com>
> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
--
Sakari Ailus
next prev parent reply other threads:[~2020-04-22 17:26 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-21 13:57 [PATCH v8 0/6] v4l2-dev/ioctl: Add V4L2_CAP_IO_MC Niklas Söderlund
2020-04-21 13:57 ` [PATCH v8 1/6] " Niklas Söderlund
2020-04-21 13:57 ` [PATCH v8 2/6] media: pci: Fill v4l2_fmtdesc with designated initializers Niklas Söderlund
2020-04-21 13:57 ` [PATCH v8 3/6] media: v4l2: Extend VIDIOC_ENUM_FMT to support MC-centric devices Niklas Söderlund
2020-04-22 17:26 ` Sakari Ailus [this message]
2020-04-23 10:38 ` Hans Verkuil
2020-04-24 13:43 ` [PATCH v8.1 " Laurent Pinchart
2020-04-29 16:27 ` Mauro Carvalho Chehab
2020-04-29 16:38 ` Laurent Pinchart
2020-04-29 18:01 ` Mauro Carvalho Chehab
2020-04-29 18:50 ` Laurent Pinchart
2020-04-29 19:46 ` Mauro Carvalho Chehab
2020-04-29 20:08 ` Sakari Ailus
2020-05-05 14:27 ` Hans Verkuil
2020-05-06 9:53 ` Mauro Carvalho Chehab
2020-05-06 9:51 ` Mauro Carvalho Chehab
2020-04-21 13:57 ` [PATCH v8 4/6] rcar-vin: Make use of V4L2_CAP_IO_MC Niklas Söderlund
2020-04-21 13:57 ` [PATCH v8 5/6] staging/intel-ipu3: " Niklas Söderlund
2020-04-21 13:57 ` [PATCH v8 6/6] vimc: " Niklas Söderlund
2020-04-22 17:22 ` [PATCH v8 0/6] v4l2-dev/ioctl: Add V4L2_CAP_IO_MC Laurent Pinchart
2020-04-23 9:46 ` Hans Verkuil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200422172637.GF5381@paasikivi.fi.intel.com \
--to=sakari.ailus@linux.intel.com \
--cc=helen.koike@collabora.com \
--cc=hverkuil-cisco@xs4all.nl \
--cc=hverkuil@xs4all.nl \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=niklas.soderlund+renesas@ragnatech.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).