On Wed, 18 May 2011, Sakari Ailus wrote:
> 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>
So, does this mean now, that we have to wait for those APIs to become
solid before or even implemented we proceed with this one?
Thanks
Guennadi
>
> (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@xxxxxxxxxxxxxxxxxxxxxxxxxx
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
