Re: [PATCH v3] V4L: add two new ioctl()s for multi-size videobuffer management

From: Sakari Ailus <sakari.ailus@iki.fi>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Mauro Carvalho Chehab <mchehab@infradead.org>,
	Pawel Osciak <pawel@osciak.com>
Subject: Re: [PATCH v3] V4L: add two new ioctl()s for multi-size videobuffer management
Date: Tue, 02 Aug 2011 11:08:34 +0300	[thread overview]
Message-ID: <4E37B082.4090105@iki.fi> (raw)
In-Reply-To: <Pine.LNX.4.64.1108011704290.30975@axis700.grange>

Guennadi Liakhovetski wrote:
> On Mon, 1 Aug 2011, Sakari Ailus wrote:
> 
>> Guennadi Liakhovetski wrote:
>>> On Tue, 26 Jul 2011, Hans Verkuil wrote:
>>>
>>>> On Tuesday, July 26, 2011 13:44:28 Sakari Ailus wrote:
>>>>> Hi Hans and Guennadi,
>>>>
>>>> <snip>
>>>>
>>>>>> I realized that it is not clear from the documentation whether it is possible to call
>>>>>> VIDIOC_REQBUFS and make additional calls to VIDIOC_CREATE_BUFS afterwards.
>>>>>
>>>>> That's actually a must if one wants to release buffers. Currently no other
>>>>> method than requesting 0 buffers using REQBUFS is provided (apart from
>>>>> closing the file handle).
>>>>
>>>> I was referring to the non-0 use-case :-)
>>>>
>>>>>> I can't remember whether the code allows it or not, but it should be clearly documented.
>>>>>
>>>>> I would guess no user application would have to call REQBUFS with other than
>>>>> zero buffers when using CREATE_BUFS. This must be an exception if mixing
>>>>> REQBUFS and CREATE_BUFS is not allowed in general. That said, I don't see a
>>>>> reason to prohibit either, but perhaps Guennadi has more informed opinion
>>>>> on this.
>>>>  
>>>> <snip>
>>>>
>>>>>>>>> Future functionality which would be nice:
>>>>>>>>>
>>>>>>>>> - Format counters. Every format set by S_FMT (or gotten by G_FMT) should
>>>>>>>>>   come with a counter value so that the user would know the format of
>>>>>>>>>   dequeued buffers when setting the format on-the-fly. Currently there are
>>>>>>>>>   only bytesperline and length, but the format can't be explicitly
>>>>>>>>>   determined from those.
>>>>>>
>>>>>> Actually, the index field will give you that information. When you create the
>>>>>> buffers you know that range [index, index + count - 1] is associated with that
>>>>>> specific format.
>>>>>
>>>>> Some hardware is able to change the format while streaming is ongoing (for
>>>>> example: OMAP 3). The problem is that the user should be able to know which
>>>>> frame has the new format.
>>>
>>> How exactly does this work or should it work? You mean, you just configure 
>>> your hardware with new frame size parameters without stopping the current 
>>> streaming, and the ISP will change frame sizes, beginning with some future 
>>> frame? How does the driver then get to know, which frame already has the 
>>
>> That's correct.
>>
>>> new sizes? You actually want to know this in advance to already queue a 
>>> suitably sized buffer to the hardware?
>>
>> The driver knows that since it has configured the hardware to produce
>> that frame size.
>>
>> The assumption is that all the buffers have suitable size for all the
>> formats. This must be checked by the driver, something which also must
>> be taken into account.
> 
> Hm, but do you then at all need different buffers?

Not in this case, but this is a different case after all: streaming with
buffers of different size, not still capture.

-- 
Sakari Ailus
sakari.ailus@iki.fi