mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Helen Koike <helen.koike@collabora.com>
To: Hans Verkuil <hverkuil@xs4all.nl>, linux-media@vger.kernel.org
Cc: mchehab@kernel.org, hans.verkuil@cisco.com, kernel@collabora.com,
	linux-kernel@vger.kernel.org, tfiga@chromium.org
Subject: Re: [PATCH 2/3] media: videodev2.h: clarify v4l2_pix_format_mplane.sizeimage docs when to set to zero
Date: Mon, 25 Jan 2021 12:02:53 -0300	[thread overview]
Message-ID: <2afcfc92-eaec-6175-cfc4-0cfe760bed9f@collabora.com> (raw)
In-Reply-To: <acae9f51-f8ca-b5f6-9af0-f0acc04e911d@xs4all.nl>



On 1/25/21 6:31 AM, Hans Verkuil wrote:
> On 14/01/2021 19:01, Helen Koike wrote:
>> sizeimage field should be set to zero for unused planes, even when
>> v4l2_pix_format_mplane.num_planes is smaller then the index of planes.
> 
> then -> than

Ack.

> 
>>
>> Signed-off-by: Helen Koike <helen.koike@collabora.com>
>>
>> ---
>>
>> I caught this with v4l2-compliance, which throws an error if we dirty
>> planes, even if invalid, so I would like to make it clear in the docs.
> 
> What is the error? And with which driver?

I was implementing conversions to/from Ext API, and I thought v4l2-compliance
wasn't happy if I didn't zero the other entries, but I'm trying to reproduce
it now by adding a non-zero value to sizeimage and I can't reproduce it, so
it was probably my mistake.
Please ignore this patch and sorry for the noise.

> 
> I wonder if this isn't a v4l2-compliance bug. And if we want this to be
> zeroed, then it wouldn't it be better to do that in the V4L2 core rather
> than bother drivers with this?
> 
>> ---
>>  include/uapi/linux/videodev2.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>> index 79dbde3bcf8d..d9b7c9177605 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -2227,6 +2227,7 @@ struct v4l2_mpeg_vbi_fmt_ivtv {
>>   * struct v4l2_plane_pix_format - additional, per-plane format definition
>>   * @sizeimage:		maximum size in bytes required for data, for which
>>   *			this plane will be used
>> + *			Drivers should be set it zero for unused planes.
> 
> This sentence is a bit garbled.
> 
> You probably meant: Drivers must set this to zero for unused planes.
> 
> But it makes no sense to just zero this field. I would zero the whole struct
> contents for the unused planes.
> 
>>   * @bytesperline:	distance in bytes between the leftmost pixels in two
>>   *			adjacent lines
>>   */
>>
> 
> The API doesn't mention whether unused plane formats should be zeroed or not,
> but it does make sense that they are. I don't think that the userspace API
> should be changed (esp. since there are apparently already drivers that do
> not zero these unused plane formats), but it makes sense that the compliance
> test does verify this, and that the V4L2 core would zero unused plane formats.
> 
> I never like it when undefined values are allowed in an API, so it makes sense
> that this is done.


Ack.

Thanks
Helen


> 
> Regards,
> 
> 	Hans
> 

  reply	other threads:[~2021-01-26  6:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-14 18:01 [PATCH 0/3] v4l2 framework minor improvements Helen Koike
2021-01-14 18:01 ` [PATCH 1/3] media: v4l2-ioctl: print capabilities in v4l_print_create_buffers() Helen Koike
2021-01-14 18:01 ` [PATCH 2/3] media: videodev2.h: clarify v4l2_pix_format_mplane.sizeimage docs when to set to zero Helen Koike
2021-01-15 13:19   ` Jacopo Mondi
2021-01-16 23:21   ` Sakari Ailus
2021-01-25  9:31   ` Hans Verkuil
2021-01-25 15:02     ` Helen Koike [this message]
2021-01-14 18:01 ` [PATCH 3/3] media: videobuf2-v4l2: remove redundant error test Helen Koike
2021-01-16 23:22   ` Sakari Ailus

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=2afcfc92-eaec-6175-cfc4-0cfe760bed9f@collabora.com \
    --to=helen.koike@collabora.com \
    --cc=hans.verkuil@cisco.com \
    --cc=hverkuil@xs4all.nl \
    --cc=kernel@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=tfiga@chromium.org \
    /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

all inboxes | Powered by JetHome®