From: Hans Verkuil <hverkuil@xs4all.nl>
To: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: linux-media@vger.kernel.org, linux-sh@vger.kernel.org,
Sakari Ailus <sakari.ailus@iki.fi>,
Katsuya MATSUBARA <matsu@igel.co.jp>,
Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
Subject: Re: [PATCH v5 2/9] Documentation: media: Clarify the VIDIOC_CREATE_BUFS format requirements
Date: Fri, 02 Aug 2013 11:43:52 +0200 [thread overview]
Message-ID: <51FB7F58.2070101@xs4all.nl> (raw)
In-Reply-To: <1375405408-17134-3-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Hi Laurent,
On 08/02/2013 03:03 AM, Laurent Pinchart wrote:
> The VIDIOC_CREATE_BUFS ioctl takes a format argument that must contain a
> valid format supported by the driver. Clarify the documentation.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> Documentation/DocBook/media/v4l/vidioc-create-bufs.xml | 15 ++++++++-------
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
> index cd99436..407937a 100644
> --- a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
> +++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
> @@ -69,10 +69,11 @@ the <structname>v4l2_create_buffers</structname> structure. They set the
> structure, to the respective stream or buffer type.
> <structfield>count</structfield> must be set to the number of required buffers.
> <structfield>memory</structfield> specifies the required I/O method. The
> -<structfield>format</structfield> field shall typically be filled in using
> -either the <constant>VIDIOC_TRY_FMT</constant> or
> -<constant>VIDIOC_G_FMT</constant> ioctl(). Additionally, applications can adjust
> -<structfield>sizeimage</structfield> fields to fit their specific needs. The
> +<structfield>format</structfield> field must be a valid format supported by the
> +driver. Applications shall typically fill it using either the
> +<constant>VIDIOC_TRY_FMT</constant> or <constant>VIDIOC_G_FMT</constant>
> +ioctl(). Any format that would be modified by the
> +<constant>VIDIOC_TRY_FMT</constant> ioctl() will be rejected with an error. The
I'm a bit unhappy with this formulation. How about: "The format must be a valid format,
otherwise an error will be returned."
The main reason for this is that changes made to the 'field' and 'colorspace' format
fields by TRY_FMT do not affect CREATE_BUFS. Does a wrong colorspace mean that
CREATE_BUFS should return an error? I'm not sure we want to do that, frankly.
You also removed the bit about the sizeimage field. That should be kept, although admittedly
it needs some improvement. The reason for that is that applications cannot set sizeimage
when calling S_FMT: that field is set by the driver. Only through CREATE_BUFS can apps
select a different (larger) sizeimage.
I think it would be useful if there was a link to CREATE_BUFS was added to the 'sizeimage'
description of struct v4l2_pix_format in DocBook. It is not exactly obvious that CREATE_BUFS
can be used for that purpose. It's really a workaround for a limitation in the spec, of
course.
Regards,
Hans
> <structfield>reserved</structfield> array must be zeroed.</para>
>
> <para>When the ioctl is called with a pointer to this structure the driver
> @@ -144,9 +145,9 @@ mapped</link> I/O.</para>
> <varlistentry>
> <term><errorcode>EINVAL</errorcode></term>
> <listitem>
> - <para>The buffer type (<structfield>type</structfield> field) or the
> -requested I/O method (<structfield>memory</structfield>) is not
> -supported.</para>
> + <para>The buffer type (<structfield>type</structfield> field),
> +requested I/O method (<structfield>memory</structfield>) or format
> +(<structfield>format</structfield> field) is not valid.</para>
> </listitem>
> </varlistentry>
> </variablelist>
>
next prev parent reply other threads:[~2013-08-02 9:44 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-02 1:03 [PATCH v5 0/9] Renesas VSP1 driver Laurent Pinchart
2013-08-02 1:03 ` [PATCH v5 1/9] media: Add support for circular graph traversal Laurent Pinchart
2013-08-02 9:44 ` Hans Verkuil
2013-08-02 1:03 ` [PATCH v5 2/9] Documentation: media: Clarify the VIDIOC_CREATE_BUFS format requirements Laurent Pinchart
2013-08-02 9:43 ` Hans Verkuil [this message]
2013-08-02 1:03 ` [PATCH v5 3/9] videobuf2: Clarify queue_setup() and buf_prepare() usage documentation Laurent Pinchart
2013-08-02 9:45 ` Hans Verkuil
2013-08-02 1:03 ` [PATCH v5 4/9] v4l: Fix V4L2_MBUS_FMT_YUV10_1X30 media bus pixel code value Laurent Pinchart
2013-08-02 9:45 ` Hans Verkuil
2013-08-02 1:03 ` [PATCH v5 5/9] v4l: Add media format codes for ARGB8888 and AYUV8888 on 32-bit busses Laurent Pinchart
2013-08-02 9:47 ` Hans Verkuil
2013-08-02 1:03 ` [PATCH v5 6/9] v4l: Add V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV61M formats Laurent Pinchart
2013-08-02 9:54 ` Hans Verkuil
2013-08-02 1:03 ` [PATCH v5 7/9] v4l: Renesas R-Car VSP1 driver Laurent Pinchart
2013-08-02 9:23 ` Hans Verkuil
2013-08-02 10:57 ` Laurent Pinchart
2013-08-02 11:14 ` Hans Verkuil
2013-08-02 11:16 ` Laurent Pinchart
2013-08-02 1:03 ` [PATCH v5 8/9] vsp1: Fix lack of the sink entity registration for enabled links Laurent Pinchart
2013-08-02 9:55 ` Hans Verkuil
2013-08-02 1:03 ` [PATCH v5 9/9] vsp1: Use the maximum number of entities defined in platform data Laurent Pinchart
2013-08-02 9:55 ` 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=51FB7F58.2070101@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=matsu@igel.co.jp \
--cc=sakari.ailus@iki.fi \
--cc=sylvester.nawrocki@gmail.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).