On 03/10/2014 01:12 PM, Archit Taneja wrote:
> Hi Hans,
> 
> On Friday 07 March 2014 07:17 PM, Archit Taneja wrote:
>> On Friday 07 March 2014 07:02 PM, Hans Verkuil wrote:
>>> On 03/07/2014 02:22 PM, Archit Taneja wrote:
> 
>>>
>>> Disregard what I said, it's OK to upstream it. But if you could just
>>> spend
>>> some hours fixing the problems, that would really be best.
>>
>> Sure, I'll try to fix these issues and then post a v3.
> 
> I fixed most of the compliance errors. There were some things I needed 
> to change in .utils/v4l2-compliance/v4l2-test-buffers.cpp'. I added 
> those with some questions in the comments:
> 
> diff --git a/utils/v4l2-compliance/v4l2-test-buffers.cpp 
> b/utils/v4l2-compliance/v4l2-test-buffers.cpp
> index 6576d11..532a5b6 100644
> --- a/utils/v4l2-compliance/v4l2-test-buffers.cpp
> +++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp
> @@ -219,7 +219,13 @@ static int checkQueryBuf(struct node *node, const 
> struct v4l2_buffer &buf,
>               fail_on_test(!(buf.flags & (V4L2_BUF_FLAG_DONE | 
> V4L2_BUF_FLAG_ERROR)));
>               if (node->is_video) {
>                       fail_on_test(buf.field == V4L2_FIELD_ALTERNATE);
> -                     fail_on_test(buf.field == V4L2_FIELD_ANY);
> +                     /*
> +                      * the OUTPUT buffers are queued with V4L2_FIELD_ANY
> +                      * field type by the application. Is it the driver's
> +                      * job to change this to NONE in buf_prepare?

Yes, it is. Applications may pass in FIELD_ANY, but the driver must never return
it, it should always be replaced by what the driver actually uses.

> +                      */
> +
> +                     /* fail_on_test(buf.field == V4L2_FIELD_ANY); */
>                       if (cur_fmt.fmt.pix.field == V4L2_FIELD_ALTERNATE) {
>                               fail_on_test(buf.field != V4L2_FIELD_BOTTOM &&
>                                               buf.field != V4L2_FIELD_TOP);
> @@ -651,9 +657,17 @@ static int captureBufs(struct node *node, const 
> struct v4l2_requestbuffers &bufs
>                       } else if (node->is_m2m && timestamp == 
> V4L2_BUF_FLAG_TIMESTAMP_COPY) {
>                               fail_on_test(buffer_info.find(buf.timestamp) == 
> buffer_info.end());
>                               struct v4l2_buffer &orig_buf = 
> buffer_info[buf.timestamp];
> -                             fail_on_test(buf.field != orig_buf.field);
> -                             fail_on_test((buf.flags & valid_output_flags) !=
> -                                          (orig_buf.flags & 
> valid_output_flags));
> +                             /* same issue as as in checkQueryBuf */
> +                             /* fail_on_test(buf.field != orig_buf.field); */
> +
> +                             /*
> +                              * the queued buffers are filled with flags like
> +                              * V4L2_BUF_FLAG_KEYFRAME, these are lost when
> +                              * the captured buffers are dequed. How do we
> +                              * fix this?

Well, the driver has to copy them :-)

Note that v4l2-compliance assumes that there is a 1 to 1 mapping between buffers
coming into the codec and buffers coming out of the codec. If that's not the
case, then copying such flags does not make any sense. On the other hand, in
that case using V4L2_BUF_FLAG_TIMESTAMP_COPY probably makes no sense either.

Regards,

        Hans

> +                              */
> +                             /*fail_on_test((buf.flags & valid_output_flags) 
> !=
> +                                          (orig_buf.flags & 
> valid_output_flags)); */
>                               if (buf.flags & V4L2_BUF_FLAG_TIMECODE)
>                                       fail_on_test(memcmp(&buf.timecode, 
> &orig_buf.timecode,
>                                                               
> sizeof(buf.timecode)));
> 
> 
> Thanks,
> Archit
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to