Hi Guennadi,
On Mon, Jun 06, 2011 at 03:10:54PM +0200, Guennadi Liakhovetski wrote:
> 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?
No. But I think we should take into account the foreseeable future. Any
which form the buffer id passing mechanism will take, it will very likely
involve referring to individual memory buffers the ids of which are not
contiguous ranges in a general case. In short, my point is that CREATE_BUF
should allow associating generic buffer ids to V4L2 buffers.
If the hardware requires more than one buffer to operate, STREAMON could
return ERANGE in a case there ane not enough queued, for example.
Regards,
--
Sakari Ailus
sakari.ailus@xxxxxx
--
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
