Hi Laurent Pinchart,

Thanks you for reply.
It makes sense.

Best regards,
Jonghun Han

> -----Original Message-----
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
> Sent: Tuesday, December 14, 2010 8:00 PM
> To: Jonghun Han
> Cc: linux-media@vger.kernel.org; 'Hans Verkuil'; mche...@redhat.com
> Subject: Re: Should a index be passed on the fly with the VIDIOC_QBUF
ioctl in
> V4L2_MEMORY_USERPTR case ?
> 
> Hi Jonghun,
> 
> On Tuesday 14 December 2010 11:51:17 Jonghun Han wrote:
> > Hi,
> >
> > Any comment for this ?
> >
> > In my opinion v4l2 spec is not accurate in this topic.
> > Because VIDIOC_REQBUFS describes count is only used in
> V4L2_MEMORY_MMAP as
> > below.
> > __u32       count   The number of buffers requested or granted. This
field is
> > only used when memory is set to V4L2_MEMORY_MMAP.
> >
> > But there is no comment in QBUF and DQBUF part about index.
> > So I am confused. If an index isn't needed, how to driver handle it ?
> 
> The spec should be fixed. VIDIOC_REQBUFS needs to be called for USERPTR as
> well, and the buffer count is definitely used.
> 
> > On Saturday, December 11, 2010 2:10 PM Jonghun Han wrote:
> > >
> > > I wonder that a index should be passed on the fly with the VIDIOC_QBUF
> > > ioctl in V4L2_MEMORY_USERPTR case.
> > > If it isn't needed, should driver return virtual address gotten from
> > > application on the fly with the VIDIOC_DQBUF ioctl ?
> 
> VIDIOC_DQBUF is supposed to fill the v4l2_buffer structure with the index
and
> the userspace virtual address (among other information). If it doesn't,
it's a
> driver bug.
> 
> --
> Regards,
> 
> Laurent Pinchart
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to