[RFC PATCH] vb2: regression fix for vbi capture & poll

[RFC PATCH] vb2: regression fix for vbi capture & poll

[Hans Verkuil]

(My proposal to fix this. Note that it is untested, I plan to do that this
evening)

Commit 9241650d62f7 broke vbi capture applications that expect POLLERR to be
returned if STREAMON wasn't called.

Rather than checking whether buffers were queued AND vb2 was not yet streaming,
just check whether streaming is in progress and return POLLERR if not.

This change makes it impossible to poll in one thread and call STREAMON in
another, but doing that breaks existing applications and is also not according
to the spec. So be it.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>

diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c
index 7e6aff6..0452fb2 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2583,10 +2583,10 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table *wait)
 	}
 
 	/*
-	 * There is nothing to wait for if no buffer has been queued and the
-	 * queue isn't streaming, or if the error flag is set.
+	 * There is nothing to wait for if the queue isn't streaming, or if
+	 * the error flag is set.
 	 */
-	if ((list_empty(&q->queued_list) && !vb2_is_streaming(q)) || q->error)
+	if (!vb2_is_streaming(q) || q->error)
 		return res | POLLERR;
 
 	/*

[RFC PATCH] vb2: regression fix for vbi capture & poll

[Hans Verkuil]

(My proposal to fix this. Note that it is untested, I plan to do that this
evening)

Commit 9241650d62f7 broke vbi capture applications that expect POLLERR to be
returned if STREAMON wasn't called.

Rather than checking whether buffers were queued AND vb2 was not yet streaming,
just check whether streaming is in progress and return POLLERR if not.

This change makes it impossible to poll in one thread and call STREAMON in
another, but doing that breaks existing applications and is also not according
to the spec. So be it.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>

diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c
index 7e6aff6..0452fb2 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2583,10 +2583,10 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table *wait)
 	}
 
 	/*
-	 * There is nothing to wait for if no buffer has been queued and the
-	 * queue isn't streaming, or if the error flag is set.
+	 * There is nothing to wait for if the queue isn't streaming, or if
+	 * the error flag is set.
 	 */
-	if ((list_empty(&q->queued_list) && !vb2_is_streaming(q)) || q->error)
+	if (!vb2_is_streaming(q) || q->error)
 		return res | POLLERR;
 
 	/*

Re: [RFC PATCH] vb2: regression fix for vbi capture & poll

[Laurent Pinchart]

Hi Hans,

Thank you for the patch.

On Tuesday 16 September 2014 12:28:50 Hans Verkuil wrote:
> (My proposal to fix this. Note that it is untested, I plan to do that this
> evening)
> 
> Commit 9241650d62f7 broke vbi capture applications that expect POLLERR to be
> returned if STREAMON wasn't called.
> 
> Rather than checking whether buffers were queued AND vb2 was not yet
> streaming, just check whether streaming is in progress and return POLLERR
> if not.
> 
> This change makes it impossible to poll in one thread and call STREAMON in
> another, but doing that breaks existing applications and is also not
> according to the spec. So be it.

I like this approach better than reverting the offending patch, as it doesn't 
break my use case :-)

If we decide that this is the right fix, we should update the V4L2 
specification to reflect that.

I've proposed an alternative solution in a reply to the "[PATCH/RFC v2 1/2] 
v4l: vb2: Don't return POLLERR during transient buffer underruns" mail thread. 
I think I like this patch better, as the behaviour is simpler, even if it 
doesn't strictly conform to the spec.

> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> b/drivers/media/v4l2-core/videobuf2-core.c index 7e6aff6..0452fb2 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -2583,10 +2583,10 @@ unsigned int vb2_poll(struct vb2_queue *q, struct
> file *file, poll_table *wait) }
> 
>  	/*
> -	 * There is nothing to wait for if no buffer has been queued and the
> -	 * queue isn't streaming, or if the error flag is set.
> +	 * There is nothing to wait for if the queue isn't streaming, or if
> +	 * the error flag is set.
>  	 */
> -	if ((list_empty(&q->queued_list) && !vb2_is_streaming(q)) || q->error)
> +	if (!vb2_is_streaming(q) || q->error)
>  		return res | POLLERR;
> 
>  	/*

-- 
Regards,

Laurent Pinchart

Re: [RFC PATCH] vb2: regression fix for vbi capture & poll

[Mauro Carvalho Chehab]

Em Tue, 16 Sep 2014 11:28:16 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:

> (My proposal to fix this. Note that it is untested, I plan to do that this
> evening)
> 
> Commit 9241650d62f7 broke vbi capture applications that expect POLLERR to be
> returned if STREAMON wasn't called.
> 
> Rather than checking whether buffers were queued AND vb2 was not yet streaming,
> just check whether streaming is in progress and return POLLERR if not.
> 
> This change makes it impossible to poll in one thread and call STREAMON in
> another, but doing that breaks existing applications and is also not according
> to the spec. So be it.
> 
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c
> index 7e6aff6..0452fb2 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -2583,10 +2583,10 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table *wait)
>  	}
>  
>  	/*
> -	 * There is nothing to wait for if no buffer has been queued and the
> -	 * queue isn't streaming, or if the error flag is set.
> +	 * There is nothing to wait for if the queue isn't streaming, or if
> +	 * the error flag is set.
>  	 */
> -	if ((list_empty(&q->queued_list) && !vb2_is_streaming(q)) || q->error)
> +	if (!vb2_is_streaming(q) || q->error)
>  		return res | POLLERR;

This makes the code even more different than what VB1 does. I suspect
that this will likely cause even more regressions.

The following (untested) patch seems to be what matches best what VB1
does, and are likely to cause less harm, but needs test of course. 

diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c
index 5b808e25fc09..0d86526cbcb0 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2586,6 +2586,9 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table *wait)
 	 * There is nothing to wait for if no buffer has been queued and the
 	 * queue isn't streaming, or if the error flag is set.
 	 */
+	if (!vb2_is_streaming(q))
+		vb2_internal_streamon(q, q->type);
+
 	if ((list_empty(&q->queued_list) && !vb2_is_streaming(q)) || q->error)
 		return res | POLLERR;
 

Re: [RFC PATCH] vb2: regression fix for vbi capture & poll

[Hans Verkuil]

On 09/16/14 15:50, Mauro Carvalho Chehab wrote:
> Em Tue, 16 Sep 2014 11:28:16 +0200
> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> 
>> (My proposal to fix this. Note that it is untested, I plan to do that this
>> evening)
>>
>> Commit 9241650d62f7 broke vbi capture applications that expect POLLERR to be
>> returned if STREAMON wasn't called.
>>
>> Rather than checking whether buffers were queued AND vb2 was not yet streaming,
>> just check whether streaming is in progress and return POLLERR if not.
>>
>> This change makes it impossible to poll in one thread and call STREAMON in
>> another, but doing that breaks existing applications and is also not according
>> to the spec. So be it.
>>
>> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>>
>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c
>> index 7e6aff6..0452fb2 100644
>> --- a/drivers/media/v4l2-core/videobuf2-core.c
>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
>> @@ -2583,10 +2583,10 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table *wait)
>>  	}
>>  
>>  	/*
>> -	 * There is nothing to wait for if no buffer has been queued and the
>> -	 * queue isn't streaming, or if the error flag is set.
>> +	 * There is nothing to wait for if the queue isn't streaming, or if
>> +	 * the error flag is set.
>>  	 */
>> -	if ((list_empty(&q->queued_list) && !vb2_is_streaming(q)) || q->error)
>> +	if (!vb2_is_streaming(q) || q->error)
>>  		return res | POLLERR;
> 
> This makes the code even more different than what VB1 does. I suspect
> that this will likely cause even more regressions.
> 
> The following (untested) patch seems to be what matches best what VB1
> does, and are likely to cause less harm, but needs test of course. 
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c
> index 5b808e25fc09..0d86526cbcb0 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -2586,6 +2586,9 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table *wait)
>  	 * There is nothing to wait for if no buffer has been queued and the
>  	 * queue isn't streaming, or if the error flag is set.
>  	 */
> +	if (!vb2_is_streaming(q))
> +		vb2_internal_streamon(q, q->type);
> +

As mentioned in my previous email, this is certainly not what vb1 does.
VB1 returns POLLERR and does not start streaming, that's what I saw when
debugging this yesterday. The automatic streaming when poll is called is
valid only if REQBUFS was never called since it assumes read() mode.

Regards,

	Hans

>  	if ((list_empty(&q->queued_list) && !vb2_is_streaming(q)) || q->error)
>  		return res | POLLERR;
>  
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>