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
 |