Hi Jon,
On Fri, Jun 17, 2011 at 11:57, Jonathan Corbet <corbet@xxxxxxx> 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?
>
I don't see a reason why these couldn't be reordered (Marek should be
able to confirm, he wrote those lines). But this wouldn't fix
everything, as the V4L2 API permits streamon without queuing any
buffers first (for capture devices). So even reordered, it's possible
for start_streaming to be called without passing any buffers to the
driver first.
--
Best regards,
Pawel Osciak
--
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
