Hello, On Friday, July 01, 2011 12:18 AM Jonathan Corbet wrote: > On Wed, 29 Jun 2011 16:10:45 +0200 > Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> wrote: > > > > I do still wonder why this is an issue - why not pass the buffers > through > > > to the driver at VIDIOC_QBUF time? I assume there must be a reason for > > > doing things this way, I'd like to understand what it is. > > > > I want to delay giving the ownership of the buffers to the driver until > it > > is certain that start_streaming method will be called. This way I achieve > > a well defined states of the queued buffers: > > > > 1. successful start_streaming() -> the driver is processing the queue > buffers > > 2. unsuccessful start_streaming() -> the driver is responsible to discard > all > > queued buffers > > 3. stop_streaming() called -> the driver has finished or discarded all > queued > > buffers > > So it's a buffer ownership thing. I wonder if there would be value in > adding a buf_give_them_all_back_now() callback? You have an implicit > change of buffer ownership now that seems easy for drivers to mess up. It > might be better to send an explicit signal at such times and, perhaps, > even require the driver to explicitly hand each buffer back to vb2? That > would make the rules clear and give some flexibility - stopping and > starting streaming without needing to start over with buffers, for example. You are right that this will make the rules more clear, but wonder if we really need it now in videbuf2. The current V4L2 API states that all buffers are automatically discarded after calling STREAM_OFF, so it is not really possible to implement true pause-like functionality. Maybe we should schedule this for V4L3? ;) Best regards -- Marek Szyprowski Samsung Poland R&D Center -- 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
