Message ID | 1397653162-10179-1-git-send-email-arun.kk@samsung.com (mailing list archive) |
---|---|
State | Superseded, archived |
Delegated to: | Kamil Debski |
Headers |
Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from <linux-media-owner@vger.kernel.org>) id 1WaPRA-0005by-Gs; Wed, 16 Apr 2014 14:59:36 +0200 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.72/mailfrontend-7) with esmtp id 1WaPR8-0002yR-1C; Wed, 16 Apr 2014 14:59:36 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754753AbaDPM7a (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Wed, 16 Apr 2014 08:59:30 -0400 Received: from mail-pd0-f171.google.com ([209.85.192.171]:47818 "EHLO mail-pd0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753240AbaDPM72 (ORCPT <rfc822;linux-media@vger.kernel.org>); Wed, 16 Apr 2014 08:59:28 -0400 Received: by mail-pd0-f171.google.com with SMTP id r10so10749695pdi.30 for <multiple recipients>; Wed, 16 Apr 2014 05:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:date:message-id; bh=7xkIpMCCNf9ZrNLqftk/zoVwii22VHyObzftwgh3alg=; b=pctVt1iYXeBem5A5DlqB3Lh1Qw09U2SiIi7LvCdh5FzCqZ+qmzG30tilIrAA4QljNz hOgQUdhG131HrCps01077KhdsGdSH97kmUYFZzN5t+qMgPsddEbVVV70BcbYct82CZj0 rSbuWJIHlkPVf3pLmDDGvfZpjaHuOiUSxjlolm4uZidFolb7hFquMJEb8qaYJtsmZ7br sC0YQpTSGAE23mgSg8RV7RhEy+YyFa7+qsaQZQBkxb/wq40AJNk05Os+YUNa9iCZ7O8F LKzYcGK7Ug8XuwH2ujcbs7OJ6PT2kjHGdJvXQzYGLxkyLfNoWHW+xb6d598uEFMP4JxU /YAA== X-Received: by 10.68.174.225 with SMTP id bv1mr8483625pbc.12.1397653168327; Wed, 16 Apr 2014 05:59:28 -0700 (PDT) Received: from localhost.localdomain ([115.113.119.130]) by mx.google.com with ESMTPSA id xo9sm109799290pab.18.2014.04.16.05.59.25 for <multiple recipients> (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Apr 2014 05:59:27 -0700 (PDT) From: Arun Kumar K <arun.kk@samsung.com> To: linux-media@vger.kernel.org, linux-samsung-soc@vger.kernel.org Cc: k.debski@samsung.com, s.nawrocki@samsung.com, hverkuil@xs4all.nl, posciak@chromium.org, arunkk.samsung@gmail.com Subject: [PATCH 1/2] v4l: Add resolution change event. Date: Wed, 16 Apr 2014 18:29:21 +0530 Message-Id: <1397653162-10179-1-git-send-email-arun.kk@samsung.com> X-Mailer: git-send-email 1.7.9.5 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.4.16.124820 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DKIM_SIGNATURE 0, FROM_NAME_PHRASE 0, URI_ENDS_IN_HTML 0, __ANY_URI 0, __CP_MEDIA_BODY 0, __CP_URI_IN_BODY 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_MAILING_LIST 0, __MIME_TEXT_ONLY 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS , __YOUTUBE_RCVD 0' |
Commit Message
Arun Kumar K
April 16, 2014, 12:59 p.m. UTC
From: Pawel Osciak <posciak@chromium.org> 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@chromium.org> Signed-off-by: Arun Kumar K <arun.kk@samsung.com> --- .../DocBook/media/v4l/vidioc-subscribe-event.xml | 8 ++++++++ include/uapi/linux/videodev2.h | 1 + 2 files changed, 9 insertions(+)
Comments
Hi Arun, Thank you for the patch. On Wednesday 16 April 2014 18:29:21 Arun Kumar K wrote: > From: Pawel Osciak <posciak@chromium.org> > > 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@chromium.org> > Signed-off-by: Arun Kumar K <arun.kk@samsung.com> > --- > .../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 ? 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. > + <row> > <entry><constant>V4L2_EVENT_PRIVATE_START</constant></entry> > <entry>0x08000000</entry> > <entry>Base event number for driver-private events.</entry> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h > index 6ae7bbe..58488b7 100644 > --- a/include/uapi/linux/videodev2.h > +++ b/include/uapi/linux/videodev2.h > @@ -1733,6 +1733,7 @@ struct v4l2_streamparm { > #define V4L2_EVENT_EOS 2 > #define V4L2_EVENT_CTRL 3 > #define V4L2_EVENT_FRAME_SYNC 4 > +#define V4L2_EVENT_RESOLUTION_CHANGE 5 > #define V4L2_EVENT_PRIVATE_START 0x08000000 > > /* Payload for V4L2_EVENT_VSYNC */
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@chromium.org> >> >> 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@chromium.org> >> Signed-off-by: Arun Kumar K <arun.kk@samsung.com> >> --- >> .../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. > 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. Regards, Hans > >> + <row> >> <entry><constant>V4L2_EVENT_PRIVATE_START</constant></entry> >> <entry>0x08000000</entry> >> <entry>Base event number for driver-private events.</entry> >> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h >> index 6ae7bbe..58488b7 100644 >> --- a/include/uapi/linux/videodev2.h >> +++ b/include/uapi/linux/videodev2.h >> @@ -1733,6 +1733,7 @@ struct v4l2_streamparm { >> #define V4L2_EVENT_EOS 2 >> #define V4L2_EVENT_CTRL 3 >> #define V4L2_EVENT_FRAME_SYNC 4 >> +#define V4L2_EVENT_RESOLUTION_CHANGE 5 >> #define V4L2_EVENT_PRIVATE_START 0x08000000 >> >> /* Payload for V4L2_EVENT_VSYNC */ > -- 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
Hi Laurent and Hans, Thank you for the review. On Wed, Apr 16, 2014 at 7:46 PM, Hans Verkuil <hverkuil@xs4all.nl> 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@chromium.org> >>> >>> 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@chromium.org> >>> Signed-off-by: Arun Kumar K <arun.kk@samsung.com> >>> --- >>> .../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-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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> + <row> <entry><constant>V4L2_EVENT_PRIVATE_START</constant></entry> <entry>0x08000000</entry> <entry>Base event number for driver-private events.</entry> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index 6ae7bbe..58488b7 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -1733,6 +1733,7 @@ struct v4l2_streamparm { #define V4L2_EVENT_EOS 2 #define V4L2_EVENT_CTRL 3 #define V4L2_EVENT_FRAME_SYNC 4 +#define V4L2_EVENT_RESOLUTION_CHANGE 5 #define V4L2_EVENT_PRIVATE_START 0x08000000 /* Payload for V4L2_EVENT_VSYNC */