All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil@xs4all.nl>
To: Tomasz Stanislawski <t.stanislaws@samsung.com>,
	linux-media@vger.kernel.org
Cc: pawel@osciak.com, Hans Verkuil <hans.verkuil@cisco.com>
Subject: Re: [REVIEWv2 PATCH 02/13] vb2: fix handling of data_offset and v4l2_plane.reserved[]
Date: Fri, 11 Apr 2014 15:03:37 +0200	[thread overview]
Message-ID: <5347E829.2030102@xs4all.nl> (raw)
In-Reply-To: <5347E49E.6020302@samsung.com>

On 04/11/2014 02:48 PM, Tomasz Stanislawski wrote:
> On 04/07/2014 03:11 PM, Hans Verkuil wrote:
>> From: Hans Verkuil <hans.verkuil@cisco.com>
>>
>> The videobuf2-core did not zero the 'planes' array in __qbuf_userptr()
>> and __qbuf_dmabuf(). That's now memset to 0. Without this the reserved
>> array in struct v4l2_plane would be non-zero, causing v4l2-compliance
>> errors.
>>
>> More serious is the fact that data_offset was not handled correctly:
>>
>> - for capture devices it was never zeroed, which meant that it was
>>   uninitialized. Unless the driver sets it it was a completely random
>>   number. With the memset above this is now fixed.
>>
>> - __qbuf_dmabuf had a completely incorrect length check that included
>>   data_offset.
> 
> Hi Hans,
> 
> I may understand it wrongly but IMO allowing non-zero data offset
> simplifies buffer sharing using dmabuf.
> I remember a problem that occurred when someone wanted to use
> a single dmabuf with multiplanar API.
> 
> For example, MFC shares a buffer with DRM. Assume that DRM device
> forces the whole image to be located in one dmabuf.
> 
> The MFC uses multiplanar API therefore application must use
> the same dmabuf to describe luma and chroma planes.
> 
> It is intuitive to use the same dmabuf for both planes and
> data_offset=0 for luma plane and data_offset = luma_size
> for chroma offset.
> 
> The check:
> 
>> -		if (planes[plane].length < planes[plane].data_offset +
>> -		    q->plane_sizes[plane]) {
> 
> assured that the logical plane does not overflow the dmabuf.
> 
> Am I wrong?

Yes :-)

For video capture the data_offset field is set by the *driver*, not the
application. In practice data_offset is the size of a header that is in
front of the actual image.

You cannot use data_offset for the purpose you describe. To do that a new
offset field would have to be added (user_offset?). I'm not opposed to
that, I think it is a valid use-case for both dmabuf and userptr and
even mmap in combination with CREATE_BUFS.

Regards,

	Hans

  reply	other threads:[~2014-04-11 13:04 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-07 13:10 [REVIEWv2 PATCH 00/13] vb2: various small fixes/improvements Hans Verkuil
2014-04-07 13:11 ` [REVIEWv2 PATCH 01/13] vb2: stop_streaming should return void Hans Verkuil
2014-04-07 13:11 ` [REVIEWv2 PATCH 02/13] vb2: fix handling of data_offset and v4l2_plane.reserved[] Hans Verkuil
2014-04-10  0:46   ` Pawel Osciak
2014-04-10  6:40     ` Hans Verkuil
2014-04-11 12:48   ` Tomasz Stanislawski
2014-04-11 13:03     ` Hans Verkuil [this message]
2014-04-11 13:48       ` Tomasz Stanislawski
2014-04-11 14:07         ` Hans Verkuil
2014-04-07 13:11 ` [REVIEWv2 PATCH 03/13] vb2: if bytesused is 0, then fill with output buffer length Hans Verkuil
2014-04-07 13:11 ` [REVIEWv2 PATCH 04/13] vb2: use correct prefix Hans Verkuil
2014-04-10  0:51   ` Pawel Osciak
2014-04-10  0:52   ` Pawel Osciak
2014-04-07 13:11 ` [REVIEWv2 PATCH 05/13] vb2: move __qbuf_mmap before __qbuf_userptr Hans Verkuil
2014-04-07 13:11 ` [REVIEWv2 PATCH 06/13] vb2: set timestamp when using write() Hans Verkuil
2014-04-10  0:55   ` Pawel Osciak
2014-04-07 13:11 ` [REVIEWv2 PATCH 07/13] vb2: reject output buffers with V4L2_FIELD_ALTERNATE Hans Verkuil
2014-04-10  0:57   ` Pawel Osciak
2014-04-07 13:11 ` [REVIEWv2 PATCH 08/13] vb2: simplify a confusing condition Hans Verkuil
2014-04-07 13:11 ` [REVIEWv2 PATCH 09/13] vb2: add vb2_fileio_is_active and check it more often Hans Verkuil
2014-04-10  1:06   ` Pawel Osciak
2014-04-07 13:11 ` [REVIEWv2 PATCH 10/13] vb2: set v4l2_buffer.bytesused to 0 for mp buffers Hans Verkuil
2014-04-10  1:08   ` Pawel Osciak
2014-04-10  1:10     ` Pawel Osciak
2014-04-07 13:11 ` [REVIEWv2 PATCH 11/13] vb2: allow read/write as long as the format is single planar Hans Verkuil
2014-04-07 13:11 ` [REVIEWv2 PATCH 12/13] vb2: start messages with a lower-case for consistency Hans Verkuil
2014-04-10  1:11   ` Pawel Osciak
2014-04-07 13:11 ` [REVIEWv2 PATCH 13/13] DocBook media: update bytesused field description 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=5347E829.2030102@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=hans.verkuil@cisco.com \
    --cc=linux-media@vger.kernel.org \
    --cc=pawel@osciak.com \
    --cc=t.stanislaws@samsung.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.