linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: linux-media@vger.kernel.org, tomi.valkeinen@ideasonboard.com,
	bingbu.cao@intel.com, hongju.wang@intel.com
Subject: Re: [RFC 7/7] media: v4l: Support line-based metadata capture
Date: Fri, 2 Jun 2023 13:50:54 +0300	[thread overview]
Message-ID: <20230602105054.GA26944@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20230505215257.60704-8-sakari.ailus@linux.intel.com>

Hi Sakari,

Thank you for the patch.

On Sat, May 06, 2023 at 12:52:57AM +0300, Sakari Ailus wrote:
> many camera sensors, among other devices, transmit embedded data and image

s/many/Many/

> data for each CSI-2 frame. This embedded data typically contains register
> configuration of the sensor that has been used to capture the image data
> of the same frame.
> 
> The embedded data is received by the CSI-2 receiver and has the same
> properties as the image data, including that it is line based: it has
> width, height and bytesperline (stride).
> 
> Add these fields to struct v4l2_meta_format and document them.
> 
> Also add V4L2_FMT_FLAG_META_LINE_BASED to tell a given format is
> line-based i.e. these fields of struct v4l2_meta_format are valid for it.
> 
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> ---
>  .../userspace-api/media/v4l/dev-meta.rst          | 15 +++++++++++++++
>  .../userspace-api/media/v4l/vidioc-enum-fmt.rst   |  7 +++++++
>  include/uapi/linux/videodev2.h                    | 10 ++++++++++
>  3 files changed, 32 insertions(+)
> 
> diff --git a/Documentation/userspace-api/media/v4l/dev-meta.rst b/Documentation/userspace-api/media/v4l/dev-meta.rst
> index 0e7e1ee1471a..7d3a64514db0 100644
> --- a/Documentation/userspace-api/media/v4l/dev-meta.rst
> +++ b/Documentation/userspace-api/media/v4l/dev-meta.rst
> @@ -65,3 +65,18 @@ to 0.
>        - ``buffersize``
>        - Maximum buffer size in bytes required for data. The value is set by the
>          driver.
> +    * - __u32
> +      - ``width``
> +      - Width of a line of metadata in bytes. Valid when :c:type`v4l2_fmtdesc`

This departs from pixel formats, where the width is defined in pixels. I
wonder what the implications will be for userspace. Seeing one
implementation, both in a kernel driver and in libcamera, will help
validating the API.

> +	flag ``V4L2_FMT_FLAG_META_LINE_BASED`` is set, otherwise zero. See
> +	:c:func:`VIDIOC_ENUM_FMT`.
> +    * - __u32
> +      - ``height``
> +      - Height of a line of metadata in bytes. Valid when :c:type`v4l2_fmtdesc`

The "height of a line" seems like a weird concept, especially if the
height is expressed in bytes. I assume this is a bad copy&paste.

> +	flag ``V4L2_FMT_FLAG_META_LINE_BASED`` is set, otherwise zero. See
> +	:c:func:`VIDIOC_ENUM_FMT`.
> +    * - __u32
> +      - ``bytesperlines``
> +      - Offset in bytes between the beginning of two consecutive lines. Valid
> +	when :c:type`v4l2_fmtdesc` flag ``V4L2_FMT_FLAG_META_LINE_BASED`` is
> +	set, otherwise zero. See :c:func:`VIDIOC_ENUM_FMT`.
> diff --git a/Documentation/userspace-api/media/v4l/vidioc-enum-fmt.rst b/Documentation/userspace-api/media/v4l/vidioc-enum-fmt.rst
> index 000c154b0f98..6d7664345a4e 100644
> --- a/Documentation/userspace-api/media/v4l/vidioc-enum-fmt.rst
> +++ b/Documentation/userspace-api/media/v4l/vidioc-enum-fmt.rst
> @@ -227,6 +227,13 @@ the ``mbus_code`` field is handled differently:
>  	The application can ask to configure the quantization of the capture
>  	device when calling the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl with
>  	:ref:`V4L2_PIX_FMT_FLAG_SET_CSC <v4l2-pix-fmt-flag-set-csc>` set.
> +    * - ``V4L2_FMT_FLAG_META_LINE_BASED``
> +      - 0x0200
> +      - The metadata format is line-based. In this case the ``width``,
> +	``height`` and ``bytesperline`` fields of :c:type:`v4l2_meta_format` are
> +	valid. The buffer consists of ``height`` lines, each having ``width``
> +	bytes of data and offset between the beginning of each two consecutive
> +	lines is ``bytesperline``.

If we add width and height for metadata formats, does it mean that
drivers have to (or can) implement VIDIOC_ENUM_FRAMESIZES ? This should
be documented.

>  
>  Return Value
>  ============
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index adcbdc15dcdb..3681b2c15901 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -873,6 +873,7 @@ struct v4l2_fmtdesc {
>  #define V4L2_FMT_FLAG_CSC_YCBCR_ENC		0x0080
>  #define V4L2_FMT_FLAG_CSC_HSV_ENC		V4L2_FMT_FLAG_CSC_YCBCR_ENC
>  #define V4L2_FMT_FLAG_CSC_QUANTIZATION		0x0100
> +#define V4L2_FMT_FLAG_META_LINE_BASED		0x0200
>  
>  	/* Frame Size and frame rate enumeration */
>  /*
> @@ -2407,10 +2408,19 @@ struct v4l2_sdr_format {
>   * struct v4l2_meta_format - metadata format definition
>   * @dataformat:		little endian four character code (fourcc)
>   * @buffersize:		maximum size in bytes required for data
> + * @width:		number of bytes of data per line (valid for line based
> + *			formats only, see format documentation)
> + * @height:		number of lines of data per buffer (valid for line based
> + *			formats only)
> + * @bytesperline:	offset between the beginnings of two adjacent lines in
> + *			bytes (valid for line based formats only)
>   */
>  struct v4l2_meta_format {
>  	__u32				dataformat;
>  	__u32				buffersize;
> +	__u32				width;
> +	__u32				height;
> +	__u32				bytesperline;
>  } __attribute__ ((packed));
>  
>  /**

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2023-06-02 10:51 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-05 21:52 [RFC 0/7] Generic line based metadata support, internal pads Sakari Ailus
2023-05-05 21:52 ` [RFC 1/7] media: mc: Add INTERNAL_SOURCE pad type flag Sakari Ailus
2023-05-08  9:52   ` Tomi Valkeinen
2023-05-08 12:04     ` Sakari Ailus
2023-05-08 12:07       ` Tomi Valkeinen
2023-05-08 12:28         ` Sakari Ailus
2023-06-02  9:18   ` Laurent Pinchart
2023-06-02 15:05     ` Sakari Ailus
2023-06-08  7:59   ` Hans Verkuil
2023-06-09 12:44     ` Sakari Ailus
2023-05-05 21:52 ` [RFC 2/7] media: v4l: subdev: Support INTERNAL_SOURCE pads in routing IOCTLs Sakari Ailus
2023-05-08 10:14   ` Tomi Valkeinen
2023-05-08 12:24     ` Sakari Ailus
2023-06-02  9:44       ` Laurent Pinchart
2023-06-02  9:46         ` Laurent Pinchart
2023-06-02 13:10           ` Sakari Ailus
2023-06-04 14:26             ` Laurent Pinchart
2023-06-05  8:06               ` Sakari Ailus
2023-06-05  8:23                 ` Laurent Pinchart
2023-06-08  8:06   ` Hans Verkuil
2023-05-05 21:52 ` [RFC 3/7] media: uapi: v4l: Document source routes Sakari Ailus
2023-05-08 10:33   ` Tomi Valkeinen
2023-05-08 16:26     ` Sakari Ailus
2023-05-08 16:35       ` Tomi Valkeinen
2023-05-08 17:41         ` Sakari Ailus
2023-06-02  9:56           ` Laurent Pinchart
2023-06-02  9:56         ` Laurent Pinchart
2023-06-09 12:55           ` Sakari Ailus
2023-06-08  8:20   ` Hans Verkuil
2023-05-05 21:52 ` [RFC 4/7] media: mc: Check pad flag validity Sakari Ailus
2023-06-02  9:58   ` Laurent Pinchart
2023-06-09 14:41     ` Sakari Ailus
2023-05-05 21:52 ` [RFC 5/7] media: uapi: Add generic serial metadata mbus formats Sakari Ailus
2023-06-02 10:36   ` Laurent Pinchart
2023-06-09 14:45     ` Sakari Ailus
2023-06-08  8:35   ` Hans Verkuil
2023-06-09 13:34     ` Sakari Ailus
2023-06-08  8:46   ` Hans Verkuil
2023-06-09 13:38     ` Sakari Ailus
2023-05-05 21:52 ` [RFC 6/7] media: uapi: Add generic 8-bit metadata format definitions Sakari Ailus
2023-06-08  8:54   ` Hans Verkuil
2023-06-09 14:27     ` Sakari Ailus
2023-05-05 21:52 ` [RFC 7/7] media: v4l: Support line-based metadata capture Sakari Ailus
2023-06-02 10:50   ` Laurent Pinchart [this message]
2023-06-09 13:46     ` Sakari Ailus
2023-06-02  7:54 ` [RFC 0/7] Generic line based metadata support, internal pads Naushir Patuck
2023-06-02  8:46   ` Sakari Ailus
2023-06-02  9:35     ` Naushir Patuck
2023-06-02 12:05       ` Sakari Ailus
2023-06-02  9:12   ` Laurent Pinchart
2023-06-02  9:43     ` Naushir Patuck
2023-06-09 13:20     ` Sakari Ailus
2023-06-09 13:59 ` Dave Stevenson
2023-06-09 14:41   ` Sakari Ailus
2023-08-03 22:36     ` Laurent Pinchart

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=20230602105054.GA26944@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=bingbu.cao@intel.com \
    --cc=hongju.wang@intel.com \
    --cc=linux-media@vger.kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=tomi.valkeinen@ideasonboard.com \
    /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).