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? Thanks Guennadi --- 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
