Re: [PATCH/RFC 1/4] V4L: add three new ioctl()s for multi-size videobuffer management

[Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>]

Hi Guennadi and Laurent,

Guennadi Liakhovetski wrote:
> On Wed, 18 May 2011, Laurent Pinchart wrote:
> 
>> On Tuesday 17 May 2011 07:52:28 Sakari Ailus wrote:
>>> Guennadi Liakhovetski wrote:
> 
> [snip]
> 
>>>>> What about making it possible to pass an array of buffer indices to the
>>>>> user, just like VIDIOC_S_EXT_CTRLS does? I'm not sure if this would be
>>>>> perfect, but it would avoid the problem of requiring continuous ranges
>>>>> of buffer ids.
>>>>>
>>>>> struct v4l2_create_buffers {
>>>>>
>>>>> 	__u32			*index;
>>>>> 	__u32			count;
>>>>> 	__u32			flags;
>>>>> 	enum v4l2_memory        memory;
>>>>> 	__u32			size;
>>>>> 	struct v4l2_format	format;
>>>>>
>>>>> };
>>>>>
>>>>> Index would be a pointer to an array of buffer indices and its length
>>>>> would be count.
>>>>
>>>> I don't understand this. We do _not_ want to allow holes in indices. For
>>>> now we decide to not implement DESTROY at all. In this case indices just
>>>> increment contiguously.
>>>>
>>>> The next stage is to implement DESTROY, but only in strict reverse order
>>>> - without holes and in the same ranges, as buffers have been CREATEd
>>>> before. So, I really don't understand why we need arrays, sorry.
>>>
>>> Well, now that we're defining a second interface to make new buffer
>>> objects, I just thought it should be made as future-proof as we can.
>>
>> I second that. I don't like rushing new APIs to find out we need something 
>> else after 6 months.
> 
> Ok, so, we pass an array from user-space with CREATE of size count. The 
> kernel fills it with as many buffers entries as it has allocated. But 
> currently drivers are also allowed to allocate more buffers, than the 
> user-space has requested. What do we do in such a case?

That's a good point.

But even if there was no array, shouldn't the user be allowed to create
the buffers using a number of separate CREATE_BUF calls? The result
would be still the same n buffers as with a single call allocating the n
buffers at once.

Also, consider the (hopefully!) forthcoming DMA buffer management API
patches. It looks like that those buffers will be referred to by file
handles. To associate several DMA buffer objects to V4L2 buffers at
once, there would have to be an array of those objects.

<URL:http://www.spinics.net/lists/linux-media/msg32448.html>

(See the links, too!)

Thus, I would think that CREATE_BUF can be used to create buffers but
not to enforce how many of them are required by a device on a single
CREATE_BUF call.

I don't have a good answer for the stated problem, but these ones
crossed my mind:

- Have a new ioctl to tell the minimum number of buffers to make
streaming possible.

- Add a field for the minimum number of buffers to CREATE_BUF.

- Use the old REQBUFS to tell the number. It didn't do much other work
in the past either, right?

Regards,

-- 
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com