On 07/01/2016 12:24 AM, Hans Verkuil wrote:
On 06/15/2016 12:49 AM, Steve Longerbeam wrote:
Add a signal lock status change to the source changes bitmask.
This indicates there was a signal lock or unlock event detected
at the input of a video decoder.

Signed-off-by: Steve Longerbeam <steve_longerb...@mentor.com>
---
  Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 12 ++++++++++--
  include/uapi/linux/videodev2.h                     |  1 +
  2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml 
b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
index c9c3c77..7758ad7 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -233,8 +233,9 @@
            <entry>
              <para>This event is triggered when a source parameter change is
               detected during runtime by the video device. It can be a
-              runtime resolution change triggered by a video decoder or the
-              format change happening on an input connector.
+              runtime resolution change or signal lock status change
+              triggered by a video decoder, or the format change happening
+              on an input connector.
               This event requires that the <structfield>id</structfield>
               matches the input index (when used with a video device node)
               or the pad index (when used with a subdevice node) from which
@@ -461,6 +462,13 @@
            from a video decoder.
            </entry>
          </row>
+         <row>
+           <entry><constant>V4L2_EVENT_SRC_CH_LOCK_STATUS</constant></entry>
+           <entry>0x0002</entry>
+           <entry>This event gets triggered when there is a signal lock or
+           unlock detected at the input of a video decoder.
+           </entry>
+         </row>
I'm not entirely sure I like this. Typically losing lock means that this event
is triggered with the V4L2_EVENT_SRC_CH_RESOLUTION flag set, and userspace has
to check the new timings etc., which will fail if there is no lock anymore.

This information is also available through ENUMINPUT.

I would need to know more about why you think this is needed, because I don't
see what this adds.

Hi Hans,

At least on the ADV718x, a source resolution change (from an autodetected video standard change) and a signal lock status change are distinct events. For example there can be a temporary loss of input signal lock without a change in detected
input video standard/resolution.

Steve

--
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