Em 17-02-2011 17:26, Guennadi Liakhovetski escreveu: > Hi Mauro > > Thanks for your comments. > > On Thu, 17 Feb 2011, Mauro Carvalho Chehab wrote: > >> Em 16-02-2011 08:35, Guennadi Liakhovetski escreveu: > > [snip] > >>> (2) cleanly separate setting video data format (S_FMT) from specifying the >>> allocated buffer size. >> >> This would break existing applications. Too late for that, except if negotiated >> with a "SETCAP" like approach. > > Sorry, don't see how my proposal from my last mail would change existing > applications. As long as no explicit buffer-queue management is performed, > no new queues are allocated, the driver will just implicitly allocate one > queue and use it. I.e., no change in behaviour. Using the same ioctl to explicitly or to implicitly allocating memory depending on the context would make the API more complicated than it should be. >> There's an additional problem with that: assume that streaming is happening, >> and a S_FMT changing the resolution was sent. There's no way to warrant that >> the very next frame will have the new resolution. So, a meta-data with the >> frame resolution (and format) would be needed. > > Sorry, we are not going to allow format changes during a running capture. > You have to stop streaming, set new formats (possibly switch to another > queue) and restart streaming. > What am I missing? If you're stopping the stream, the current API will work as-is. If all of your concerns is about reserving a bigger buffer queue, I think that one of the reasons for the CMA allocator it for such usage. Am I missing something? Cheers, Mauro -- 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
