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@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
