vidioc-query-dv-timings.rst 2.6 KB
Newer Older
1 2
.. -*- coding: utf-8; mode: rst -*-

3
.. _VIDIOC_QUERY_DV_TIMINGS:
4 5 6 7 8

*****************************
ioctl VIDIOC_QUERY_DV_TIMINGS
*****************************

9 10
NAME
====
11

12
VIDIOC_QUERY_DV_TIMINGS - VIDIOC_SUBDEV_QUERY_DV_TIMINGS - Sense the DV preset received by the current input
13

14
SYNOPSIS
15 16
========

17
.. cpp:function:: int ioctl( int fd, int request, struct v4l2_dv_timings *argp )
18

19 20

ARGUMENTS
21 22 23 24 25 26 27 28 29 30 31
=========

``fd``
    File descriptor returned by :ref:`open() <func-open>`.

``request``
    VIDIOC_QUERY_DV_TIMINGS, VIDIOC_SUBDEV_QUERY_DV_TIMINGS

``argp``


32
DESCRIPTION
33 34 35 36
===========

The hardware may be able to detect the current DV timings automatically,
similar to sensing the video standard. To do so, applications call
37
:ref:`VIDIOC_QUERY_DV_TIMINGS` with a pointer to a struct
38 39 40 41 42 43
:ref:`v4l2_dv_timings <v4l2-dv-timings>`. Once the hardware detects
the timings, it will fill in the timings structure.

Please note that drivers shall *not* switch timings automatically if new
timings are detected. Instead, drivers should send the
``V4L2_EVENT_SOURCE_CHANGE`` event (if they support this) and expect
44
that userspace will take action by calling :ref:`VIDIOC_QUERY_DV_TIMINGS`.
45 46 47
The reason is that new timings usually mean different buffer sizes as
well, and you cannot change buffer sizes on the fly. In general,
applications that receive the Source Change event will have to call
48
:ref:`VIDIOC_QUERY_DV_TIMINGS`, and if the detected timings are valid they
49 50 51 52 53
will have to stop streaming, set the new timings, allocate new buffers
and start streaming again.

If the timings could not be detected because there was no signal, then
ENOLINK is returned. If a signal was detected, but it was unstable and
54
the receiver could not lock to the signal, then ``ENOLCK`` is returned. If
55 56 57
the receiver could lock to the signal, but the format is unsupported
(e.g. because the pixelclock is out of range of the hardware
capabilities), then the driver fills in whatever timings it could find
58
and returns ``ERANGE``. In that case the application can call
59
:ref:`VIDIOC_DV_TIMINGS_CAP` to compare the
60 61 62 63
found timings with the hardware's capabilities in order to give more
precise feedback to the user.


64
RETURN VALUE
65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82
============

On success 0 is returned, on error -1 and the ``errno`` variable is set
appropriately. The generic error codes are described at the
:ref:`Generic Error Codes <gen-errors>` chapter.

ENODATA
    Digital video timings are not supported for this input or output.

ENOLINK
    No timings could be detected because no signal was found.

ENOLCK
    The signal was unstable and the hardware could not lock on to it.

ERANGE
    Timings were found, but they are out of range of the hardware
    capabilities.