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?
Thanks
Guennadi
> > But even with single index, it's always possible to issue the ioctl more
> > than once and achieve the same result as if there was an array of indices.
> >
> > What would be the reason to disallow creating holes to index range? I
> > don't see much reason from application or implementation point of view,
> > as we're even being limited to such low numbers.
> >
> > Speaking of which; perhaps I'm bringing this up rather late, but should
> > we define the API to allow larger numbers than VIDEO_MAX_FRAME? 32 isn't
> > all that much after all --- this might become a limiting factor later on
> > when there are devices with huge amounts of memory.
> >
> > Allowing CREATE_BUF to do that right now would be possible since
> > applications using it are new users and can be expected to be using it
> > properly. :-)
>
> --
> Regards,
>
> Laurent Pinchart
>
---
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
