Re: [PATCH 1/2] v4l: Add resolution change event.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Laurent and Hans,

Thank you for the review.

On Wed, Apr 16, 2014 at 7:46 PM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote:
> On 04/16/2014 04:09 PM, Laurent Pinchart wrote:
>> Hi Arun,
>>
>> Thank you for the patch.
>> On Wednesday 16 April 2014 18:29:21 Arun Kumar K wrote:
>>> From: Pawel Osciak <posciak@xxxxxxxxxxxx>
>>>
>>> This event indicates that the decoder has reached a point in the stream,
>>> at which the resolution changes. The userspace is expected to provide a new
>>> set of CAPTURE buffers for the new format before decoding can continue.
>>>
>>> Signed-off-by: Pawel Osciak <posciak@xxxxxxxxxxxx>
>>> Signed-off-by: Arun Kumar K <arun.kk@xxxxxxxxxxx>
>>> ---
>>>  .../DocBook/media/v4l/vidioc-subscribe-event.xml   |    8 ++++++++
>>>  include/uapi/linux/videodev2.h                     |    1 +
>>>  2 files changed, 9 insertions(+)
>>>
>>> diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
>>> b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index
>>> 5c70b61..d848628 100644
>>> --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
>>> +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
>>> @@ -155,6 +155,14 @@
>>>          </entry>
>>>        </row>
>>>        <row>
>>> +        <entry><constant>V4L2_EVENT_RESOLUTION_CHANGE</constant></entry>
>>> +        <entry>5</entry>
>>> +        <entry>This event is triggered when a resolution change is detected
>>> +        during runtime by the video decoder. Application may need to
>>> +        reinitialize buffers before proceeding further.
>>> +        </entry>
>>> +      </row>
>>
>> Would it make sense to report the new resolution in the event data ? I suppose
>> it might not be available in all cases though. If we can't report it, would it
>> make sense to document how applications should proceed to retrieve it ?
>
> I wouldn't report that. We played with this in Cisco, and in the end you just
> want to know something changed and you can take it from there. Besides, what
> constitutes a 'resolution' change? If my HDMI input switches from 720p60 to
> 720p30 the resolution stays the same, but I most definitely have to get the new
> timings.
>
> So I would call the event something different: EVENT_SOURCE_CHANGE or something
> like that.
>
> Getting the new timings is done through QUERYSTD or QUERY_DV_TIMINGS.
>

Ok will use the name V4L2_EVENT_SOURCE_CHANGE and update description
to reflect the generic usecase (not just for video decoders).

>> A similar resolution change event might be useful on subdevs, in which case we
>> would need to add a pad number to the event data. We could possibly leave that
>> for later, but it would be worth considering the problem already.
>
> Actually, I would add that right away. That's some thing that the adv7604
> driver can implement right away: it has multiple inputs and it can detect
> when something is plugged in or unplugged.
>

Ok will add support for mentioning pad number in event data.

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




[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  Powered by Linux