Hi Jon
On 06/17/2011 08:57 PM, Jonathan Corbet wrote:
> Here's another videobuf2 question...I've been trying to track down some
> weird behavior, the roots of which were in the fact that start_streaming()
> gets called even though no buffers have been queued. This behavior is
> quite explicit in the code:
>
> /*
> * Let driver notice that streaming state has been enabled.
> */
> ret = call_qop(q, start_streaming, q);
> if (ret) {
> dprintk(1, "streamon: driver refused to start streaming\n");
> return ret;
> }
>
> q->streaming = 1;
>
> /*
> * If any buffers were queued before streamon,
> * we can now pass them to driver for processing.
> */
> list_for_each_entry(vb, &q->queued_list, queued_entry)
> __enqueue_in_driver(vb);
>
> Pretty much every v4l2 capture application I've ever encountered passes all
> of its buffers to VIDIOC_QBUF before starting streaming for a reason - it
> makes little sense to start if there's nothing to stream to. It's really
> tempting to reorder that code, but... it seems you must have done things
> this way for a reason. Why did you need to reorder the operations in this
> way?
AFAIR one of main reasons for doing the operations in that order was to
create consistent conditions for the drivers, regardless of the call sequence
in the user space.
You may find more information in this thread:
http://www.mail-archive.com/linux-media@xxxxxxxxxxxxxxx/msg29348.html
--
Regards,
Sylwester
--
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
