code:
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later

.. _flash-controls:

***********************
Flash Control Reference
***********************

The V4L2 flash controls are intended to provide generic access to flash
controller devices. Flash controller devices are typically used in
digital cameras.

The interface can support both LED and xenon flash devices. As of
writing this, there is no xenon flash driver using this interface.

.. _flash-controls-use-cases:

Supported use cases
===================

Unsynchronised LED flash (software strobe)
------------------------------------------

Unsynchronised LED flash is controlled directly by the host as the
sensor. The flash must be enabled by the host before the exposure of the
image starts and disabled once it ends. The host is fully responsible
for the timing of the flash.

Example of such device: Nokia N900.

Synchronised LED flash (hardware strobe)
----------------------------------------

The synchronised LED flash is pre-programmed by the host (power and
timeout) but controlled by the sensor through a strobe signal from the
sensor to the flash.

The sensor controls the flash duration and timing. This information
typically must be made available to the sensor.

LED flash as torch
------------------

LED flash may be used as torch in conjunction with another use case
involving camera or individually.

.. _flash-control-id:

Flash Control IDs
-----------------

``V4L2_CID_FLASH_CLASS (class)``
    The FLASH class descriptor.

``V4L2_CID_FLASH_LED_MODE (menu)``
    Defines the mode of the flash LED, the high-power white LED attached
    to the flash controller. Setting this control may not be possible in
    presence of some faults. See V4L2_CID_FLASH_FAULT.

.. tabularcolumns:: |p{5.7cm}|p{11.8cm}|

.. flat-table::
    :header-rows:  0
    :stub-columns: 0

    * - ``V4L2_FLASH_LED_MODE_NONE``
      - Off.
    * - ``V4L2_FLASH_LED_MODE_FLASH``
      - Flash mode.
    * - ``V4L2_FLASH_LED_MODE_TORCH``
      - Torch mode.

        See V4L2_CID_FLASH_TORCH_INTENSITY.

``V4L2_CID_FLASH_STROBE_SOURCE (menu)``
    Defines the source of the flash LED strobe.

.. tabularcolumns:: |p{7.5cm}|p{7.5cm}|

.. flat-table::
    :header-rows:  0
    :stub-columns: 0

    * - ``V4L2_FLASH_STROBE_SOURCE_SOFTWARE``
      - The flash strobe is triggered by using the
	V4L2_CID_FLASH_STROBE control.
    * - ``V4L2_FLASH_STROBE_SOURCE_EXTERNAL``
      - The flash strobe is triggered by an external source. Typically
	this is a sensor, which makes it possible to synchronise the
	flash strobe start to exposure start.

``V4L2_CID_FLASH_STROBE (button)``
    Strobe flash. Valid when V4L2_CID_FLASH_LED_MODE is set to
    V4L2_FLASH_LED_MODE_FLASH and V4L2_CID_FLASH_STROBE_SOURCE
    is set to V4L2_FLASH_STROBE_SOURCE_SOFTWARE. Setting this
    control may not be possible in presence of some faults. See
    V4L2_CID_FLASH_FAULT.

``V4L2_CID_FLASH_STROBE_STOP (button)``
    Stop flash strobe immediately.

``V4L2_CID_FLASH_STROBE_STATUS (boolean)``
    Strobe status: whether the flash is strobing at the moment or not.
    This is a read-only control.

``V4L2_CID_FLASH_TIMEOUT (integer)``
    Hardware timeout for flash. The flash strobe is stopped after this
    period of time has passed from the start of the strobe.

``V4L2_CID_FLASH_INTENSITY (integer)``
    Intensity of the flash strobe when the flash LED is in flash mode
    (V4L2_FLASH_LED_MODE_FLASH). The unit should be milliamps (mA)
    if possible.

``V4L2_CID_FLASH_TORCH_INTENSITY (integer)``
    Intensity of the flash LED in torch mode
    (V4L2_FLASH_LED_MODE_TORCH). The unit should be milliamps (mA)
    if possible. Setting this control may not be possible in presence of
    some faults. See V4L2_CID_FLASH_FAULT.

``V4L2_CID_FLASH_INDICATOR_INTENSITY (integer)``
    Intensity of the indicator LED. The indicator LED may be fully
    independent of the flash LED. The unit should be microamps (uA) if
    possible.

``V4L2_CID_FLASH_FAULT (bitmask)``
    Faults related to the flash. The faults tell about specific problems
    in the flash chip itself or the LEDs attached to it. Faults may
    prevent further use of some of the flash controls. In particular,
    V4L2_CID_FLASH_LED_MODE is set to V4L2_FLASH_LED_MODE_NONE
    if the fault affects the flash LED. Exactly which faults have such
    an effect is chip dependent. Reading the faults resets the control
    and returns the chip to a usable state if possible.

.. tabularcolumns:: |p{8.4cm}|p{9.1cm}|

.. flat-table::
    :header-rows:  0
    :stub-columns: 0

    * - ``V4L2_FLASH_FAULT_OVER_VOLTAGE``
      - Flash controller voltage to the flash LED has exceeded the limit
	specific to the flash controller.
    * - ``V4L2_FLASH_FAULT_TIMEOUT``
      - The flash strobe was still on when the timeout set by the user ---
	V4L2_CID_FLASH_TIMEOUT control --- has expired. Not all flash
	controllers may set this in all such conditions.
    * - ``V4L2_FLASH_FAULT_OVER_TEMPERATURE``
      - The flash controller has overheated.
    * - ``V4L2_FLASH_FAULT_SHORT_CIRCUIT``
      - The short circuit protection of the flash controller has been
	triggered.
    * - ``V4L2_FLASH_FAULT_OVER_CURRENT``
      - Current in the LED power supply has exceeded the limit specific to
	the flash controller.
    * - ``V4L2_FLASH_FAULT_INDICATOR``
      - The flash controller has detected a short or open circuit
	condition on the indicator LED.
    * - ``V4L2_FLASH_FAULT_UNDER_VOLTAGE``
      - Flash controller voltage to the flash LED has been below the
	minimum limit specific to the flash controller.
    * - ``V4L2_FLASH_FAULT_INPUT_VOLTAGE``
      - The input voltage of the flash controller is below the limit under
	which strobing the flash at full current will not be possible.The
	condition persists until this flag is no longer set.
    * - ``V4L2_FLASH_FAULT_LED_OVER_TEMPERATURE``
      - The temperature of the LED has exceeded its allowed upper limit.

``V4L2_CID_FLASH_CHARGE (boolean)``
    Enable or disable charging of the xenon flash capacitor.

``V4L2_CID_FLASH_READY (boolean)``
    Is the flash ready to strobe? Xenon flashes require their capacitors
    charged before strobing. LED flashes often require a cooldown period
    after strobe during which another strobe will not be possible. This
    is a read-only control.


code:
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later

.. _fm-rx-controls:

*****************************
FM Receiver Control Reference
*****************************

The FM Receiver (FM_RX) class includes controls for common features of
FM Reception capable devices.

.. _fm-rx-control-id:

FM_RX Control IDs
=================

``V4L2_CID_FM_RX_CLASS (class)``
    The FM_RX class descriptor. Calling
    :ref:`VIDIOC_QUERYCTRL` for this control will
    return a description of this control class.

``V4L2_CID_RDS_RECEPTION (boolean)``
    Enables/disables RDS reception by the radio tuner

``V4L2_CID_RDS_RX_PTY (integer)``
    Gets RDS Programme Type field. This encodes up to 31 pre-defined
    programme types.

``V4L2_CID_RDS_RX_PS_NAME (string)``
    Gets the Programme Service name (PS_NAME). It is intended for
    static display on a receiver. It is the primary aid to listeners in
    programme service identification and selection. In Annex E of
    :ref:`iec62106`, the RDS specification, there is a full
    description of the correct character encoding for Programme Service
    name strings. Also from RDS specification, PS is usually a single
    eight character text. However, it is also possible to find receivers
    which can scroll strings sized as 8 x N characters. So, this control
    must be configured with steps of 8 characters. The result is it must
    always contain a string with size multiple of 8.

``V4L2_CID_RDS_RX_RADIO_TEXT (string)``
    Gets the Radio Text info. It is a textual description of what is
    being broadcasted. RDS Radio Text can be applied when broadcaster
    wishes to transmit longer PS names, programme-related information or
    any other text. In these cases, RadioText can be used in addition to
    ``V4L2_CID_RDS_RX_PS_NAME``. The encoding for Radio Text strings is
    also fully described in Annex E of :ref:`iec62106`. The length of
    Radio Text strings depends on which RDS Block is being used to
    transmit it, either 32 (2A block) or 64 (2B block). However, it is
    also possible to find receivers which can scroll strings sized as 32
    x N or 64 x N characters. So, this control must be configured with
    steps of 32 or 64 characters. The result is it must always contain a
    string with size multiple of 32 or 64.

``V4L2_CID_RDS_RX_TRAFFIC_ANNOUNCEMENT (boolean)``
    If set, then a traffic announcement is in progress.

``V4L2_CID_RDS_RX_TRAFFIC_PROGRAM (boolean)``
    If set, then the tuned programme carries traffic announcements.

``V4L2_CID_RDS_RX_MUSIC_SPEECH (boolean)``
    If set, then this channel broadcasts music. If cleared, then it
    broadcasts speech. If the transmitter doesn't make this distinction,
    then it will be set.

``V4L2_CID_TUNE_DEEMPHASIS``
    (enum)

enum v4l2_deemphasis -
    Configures the de-emphasis value for reception. A de-emphasis filter
    is applied to the broadcast to accentuate the high audio
    frequencies. Depending on the region, a time constant of either 50
    or 75 useconds is used. The enum v4l2_deemphasis defines possible
    values for de-emphasis. Here they are:

.. flat-table::
    :header-rows:  0
    :stub-columns: 0

    * - ``V4L2_DEEMPHASIS_DISABLED``
      - No de-emphasis is applied.
    * - ``V4L2_DEEMPHASIS_50_uS``
      - A de-emphasis of 50 uS is used.
    * - ``V4L2_DEEMPHASIS_75_uS``
      - A de-emphasis of 75 uS is used.

repo_name: angery/linux


code:
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later

.. _fm-tx-controls:

********************************
FM Transmitter Control Reference
********************************

The FM Transmitter (FM_TX) class includes controls for common features
of FM transmissions capable devices. Currently this class includes
parameters for audio compression, pilot tone generation, audio deviation
limiter, RDS transmission and tuning power features.

.. _fm-tx-control-id:

FM_TX Control IDs
=================

``V4L2_CID_FM_TX_CLASS (class)``
    The FM_TX class descriptor. Calling
    :ref:`VIDIOC_QUERYCTRL` for this control will
    return a description of this control class.

``V4L2_CID_RDS_TX_DEVIATION (integer)``
    Configures RDS signal frequency deviation level in Hz. The range and
    step are driver-specific.

``V4L2_CID_RDS_TX_PI (integer)``
    Sets the RDS Programme Identification field for transmission.

``V4L2_CID_RDS_TX_PTY (integer)``
    Sets the RDS Programme Type field for transmission. This encodes up
    to 31 pre-defined programme types.

``V4L2_CID_RDS_TX_PS_NAME (string)``
    Sets the Programme Service name (PS_NAME) for transmission. It is
    intended for static display on a receiver. It is the primary aid to
    listeners in programme service identification and selection. In
    Annex E of :ref:`iec62106`, the RDS specification, there is a full
    description of the correct character encoding for Programme Service
    name strings. Also from RDS specification, PS is usually a single
    eight character text. However, it is also possible to find receivers
    which can scroll strings sized as 8 x N characters. So, this control
    must be configured with steps of 8 characters. The result is it must
    always contain a string with size multiple of 8.

``V4L2_CID_RDS_TX_RADIO_TEXT (string)``
    Sets the Radio Text info for transmission. It is a textual
    description of what is being broadcasted. RDS Radio Text can be
    applied when broadcaster wishes to transmit longer PS names,
    programme-related information or any other text. In these cases,
    RadioText should be used in addition to ``V4L2_CID_RDS_TX_PS_NAME``.
    The encoding for Radio Text strings is also fully described in Annex
    E of :ref:`iec62106`. The length of Radio Text strings depends on
    which RDS Block is being used to transmit it, either 32 (2A block)
    or 64 (2B block). However, it is also possible to find receivers
    which can scroll strings sized as 32 x N or 64 x N characters. So,
    this control must be configured with steps of 32 or 64 characters.
    The result is it must always contain a string with size multiple of
    32 or 64.

``V4L2_CID_RDS_TX_MONO_STEREO (boolean)``
    Sets the Mono/Stereo bit of the Decoder Identification code. If set,
    then the audio was recorded as stereo.

``V4L2_CID_RDS_TX_ARTIFICIAL_HEAD (boolean)``
    Sets the
    `Artificial Head <http://en.wikipedia.org/wiki/Artificial_head>`__
    bit of the Decoder Identification code. If set, then the audio was
    recorded using an artificial head.

``V4L2_CID_RDS_TX_COMPRESSED (boolean)``
    Sets the Compressed bit of the Decoder Identification code. If set,
    then the audio is compressed.

``V4L2_CID_RDS_TX_DYNAMIC_PTY (boolean)``
    Sets the Dynamic PTY bit of the Decoder Identification code. If set,
    then the PTY code is dynamically switched.

``V4L2_CID_RDS_TX_TRAFFIC_ANNOUNCEMENT (boolean)``
    If set, then a traffic announcement is in progress.

``V4L2_CID_RDS_TX_TRAFFIC_PROGRAM (boolean)``
    If set, then the tuned programme carries traffic announcements.

``V4L2_CID_RDS_TX_MUSIC_SPEECH (boolean)``
    If set, then this channel broadcasts music. If cleared, then it
    broadcasts speech. If the transmitter doesn't make this distinction,
    then it should be set.

``V4L2_CID_RDS_TX_ALT_FREQS_ENABLE (boolean)``
    If set, then transmit alternate frequencies.

``V4L2_CID_RDS_TX_ALT_FREQS (__u32 array)``
    The alternate frequencies in kHz units. The RDS standard allows for
    up to 25 frequencies to be defined. Drivers may support fewer
    frequencies so check the array size.

``V4L2_CID_AUDIO_LIMITER_ENABLED (boolean)``
    Enables or disables the audio deviation limiter feature. The limiter
    is useful when trying to maximize the audio volume, minimize
    receiver-generated distortion and prevent overmodulation.

``V4L2_CID_AUDIO_LIMITER_RELEASE_TIME (integer)``
    Sets the audio deviation limiter feature release time. Unit is in
    useconds. Step and range are driver-specific.

``V4L2_CID_AUDIO_LIMITER_DEVIATION (integer)``
    Configures audio frequency deviation level in Hz. The range and step
    are driver-specific.

``V4L2_CID_AUDIO_COMPRESSION_ENABLED (boolean)``
    Enables or disables the audio compression feature. This feature
    amplifies signals below the threshold by a fixed gain and compresses
    audio signals above the threshold by the ratio of Threshold/(Gain +
    Threshold).

``V4L2_CID_AUDIO_COMPRESSION_GAIN (integer)``
    Sets the gain for audio compression feature. It is a dB value. The
    range and step are driver-specific.

``V4L2_CID_AUDIO_COMPRESSION_THRESHOLD (integer)``
    Sets the threshold level for audio compression freature. It is a dB
    value. The range and step are driver-specific.

``V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME (integer)``
    Sets the attack time for audio compression feature. It is a useconds
    value. The range and step are driver-specific.

``V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME (integer)``
    Sets the release time for audio compression feature. It is a
    useconds value. The range and step are driver-specific.

``V4L2_CID_PILOT_TONE_ENABLED (boolean)``
    Enables or disables the pilot tone generation feature.

``V4L2_CID_PILOT_TONE_DEVIATION (integer)``
    Configures pilot tone frequency deviation level. Unit is in Hz. The
    range and step are driver-specific.

``V4L2_CID_PILOT_TONE_FREQUENCY (integer)``
    Configures pilot tone frequency value. Unit is in Hz. The range and
    step are driver-specific.

``V4L2_CID_TUNE_PREEMPHASIS``
    (enum)

enum v4l2_preemphasis -
    Configures the pre-emphasis value for broadcasting. A pre-emphasis
    filter is applied to the broadcast to accentuate the high audio
    frequencies. Depending on the region, a time constant of either 50
    or 75 useconds is used. The enum v4l2_preemphasis defines possible
    values for pre-emphasis. Here they are:

.. flat-table::
    :header-rows:  0
    :stub-columns: 0

    * - ``V4L2_PREEMPHASIS_DISABLED``
      - No pre-emphasis is applied.
    * - ``V4L2_PREEMPHASIS_50_uS``
      - A pre-emphasis of 50 uS is used.
    * - ``V4L2_PREEMPHASIS_75_uS``
      - A pre-emphasis of 75 uS is used.

``V4L2_CID_TUNE_POWER_LEVEL (integer)``
    Sets the output power level for signal transmission. Unit is in
    dBuV. Range and step are driver-specific.

``V4L2_CID_TUNE_ANTENNA_CAPACITOR (integer)``
    This selects the value of antenna tuning capacitor manually or
    automatically if set to zero. Unit, range and step are
    driver-specific.

For more details about RDS specification, refer to :ref:`iec62106`
document, from CENELEC.


code:
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later

.. _image-process-controls:

*******************************
Image Process Control Reference
*******************************

The Image Process control class is intended for low-level control of
image processing functions. Unlike ``V4L2_CID_IMAGE_SOURCE_CLASS``, the
controls in this class affect processing the image, and do not control
capturing of it.

.. _image-process-control-id:

Image Process Control IDs
=========================

``V4L2_CID_IMAGE_PROC_CLASS (class)``
    The IMAGE_PROC class descriptor.

.. _v4l2-cid-link-freq:

``V4L2_CID_LINK_FREQ (integer menu)``
    The frequency of the data bus (e.g. parallel or CSI-2).

.. _v4l2-cid-pixel-rate:

``V4L2_CID_PIXEL_RATE (64-bit integer)``
    Pixel sampling rate in the device's pixel array. This control is
    read-only and its unit is pixels / second.

    Some devices use horizontal and vertical balanking to configure the frame
    rate. The frame rate can be calculated from the pixel rate, analogue crop
    rectangle as well as horizontal and vertical blanking. The pixel rate
    control may be present in a different sub-device than the blanking controls
    and the analogue crop rectangle configuration.

    The configuration of the frame rate is performed by selecting the desired
    horizontal and vertical blanking. The unit of this control is Hz.

``V4L2_CID_TEST_PATTERN (menu)``
    Some capture/display/sensor devices have the capability to generate
    test pattern images. These hardware specific test patterns can be
    used to test if a device is working properly.

``V4L2_CID_DEINTERLACING_MODE (menu)``
    The video deinterlacing mode (such as Bob, Weave, ...). The menu items are
    driver specific and are documented in :ref:`uapi-v4l-drivers`.

``V4L2_CID_DIGITAL_GAIN (integer)``
    Digital gain is the value by which all colour components
    are multiplied by. Typically the digital gain applied is the
    control value divided by e.g. 0x100, meaning that to get no
    digital gain the control value needs to be 0x100. The no-gain
    configuration is also typically the default.


code:
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later

.. _image-source-controls:

******************************
Image Source Control Reference
******************************

The Image Source control class is intended for low-level control of
image source devices such as image sensors. The devices feature an
analogue to digital converter and a bus transmitter to transmit the
image data out of the device.

.. _image-source-control-id:

Image Source Control IDs
========================

``V4L2_CID_IMAGE_SOURCE_CLASS (class)``
    The IMAGE_SOURCE class descriptor.

``V4L2_CID_VBLANK (integer)``
    Vertical blanking. The idle period after every frame during which no
    image data is produced. The unit of vertical blanking is a line.
    Every line has length of the image width plus horizontal blanking at
    the pixel rate defined by ``V4L2_CID_PIXEL_RATE`` control in the
    same sub-device.

``V4L2_CID_HBLANK (integer)``
    Horizontal blanking. The idle period after every line of image data
    during which no image data is produced. The unit of horizontal
    blanking is pixels.

``V4L2_CID_ANALOGUE_GAIN (integer)``
    Analogue gain is gain affecting all colour components in the pixel
    matrix. The gain operation is performed in the analogue domain
    before A/D conversion.

``V4L2_CID_TEST_PATTERN_RED (integer)``
    Test pattern red colour component.

``V4L2_CID_TEST_PATTERN_GREENR (integer)``
    Test pattern green (next to red) colour component.

``V4L2_CID_TEST_PATTERN_BLUE (integer)``
    Test pattern blue colour component.

``V4L2_CID_TEST_PATTERN_GREENB (integer)``
    Test pattern green (next to blue) colour component.

``V4L2_CID_UNIT_CELL_SIZE (struct)``
    This control returns the unit cell size in nanometers. The struct
    :c:type:`v4l2_area` provides the width and the height in separate
    fields to take into consideration asymmetric pixels.
    This control does not take into consideration any possible hardware
    binning.
    The unit cell consists of the whole area of the pixel, sensitive and
    non-sensitive.
    This control is required for automatic calibration of sensors/cameras.

.. c:type:: v4l2_area

.. flat-table:: struct v4l2_area
    :header-rows:  0
    :stub-columns: 0
    :widths:       1 1 2

    * - __u32
      - ``width``
      - Width of the area.
    * - __u32
      - ``height``
      - Height of the area.

``V4L2_CID_NOTIFY_GAINS (integer array)``
    The sensor is notified what gains will be applied to the different
    colour channels by subsequent processing (such as by an ISP). The
    sensor is merely informed of these values in case it performs
    processing that requires them, but it does not apply them itself to
    the output pixels.

    Currently it is defined only for Bayer sensors, and is an array
    control taking 4 gain values, being the gains for each of the
    Bayer channels. The gains are always in the order B, Gb, Gr and R,
    irrespective of the exact Bayer order of the sensor itself.

    The use of an array allows this control to be extended to sensors
    with, for example, non-Bayer CFAs (colour filter arrays).

    The units for the gain values are linear, with the default value
    representing a gain of exactly 1.0. For example, if this default value
    is reported as being (say) 128, then a value of 192 would represent
    a gain of exactly 1.5.


code:
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later

.. _jpeg-controls:

**********************
JPEG Control Reference
**********************

The JPEG class includes controls for common features of JPEG encoders
and decoders. Currently it includes features for codecs implementing
progressive baseline DCT compression process with Huffman entrophy
coding.

.. _jpeg-control-id:

JPEG Control IDs
================

``V4L2_CID_JPEG_CLASS (class)``
    The JPEG class descriptor. Calling
    :ref:`VIDIOC_QUERYCTRL` for this control will
    return a description of this control class.

``V4L2_CID_JPEG_CHROMA_SUBSAMPLING (menu)``
    The chroma subsampling factors describe how each component of an
    input image is sampled, in respect to maximum sample rate in each
    spatial dimension. See :ref:`itu-t81`, clause A.1.1. for more
    details. The ``V4L2_CID_JPEG_CHROMA_SUBSAMPLING`` control determines
    how Cb and Cr components are downsampled after converting an input
    image from RGB to Y'CbCr color space.

.. tabularcolumns:: |p{7.5cm}|p{10.0cm}|

.. flat-table::
    :header-rows:  0
    :stub-columns: 0

    * - ``V4L2_JPEG_CHROMA_SUBSAMPLING_444``
      - No chroma subsampling, each pixel has Y, Cr and Cb values.
    * - ``V4L2_JPEG_CHROMA_SUBSAMPLING_422``
      - Horizontally subsample Cr, Cb components by a factor of 2.
    * - ``V4L2_JPEG_CHROMA_SUBSAMPLING_420``
      - Subsample Cr, Cb components horizontally and vertically by 2.
    * - ``V4L2_JPEG_CHROMA_SUBSAMPLING_411``
      - Horizontally subsample Cr, Cb components by a factor of 4.
    * - ``V4L2_JPEG_CHROMA_SUBSAMPLING_410``
      - Subsample Cr, Cb components horizontally by 4 and vertically by 2.
    * - ``V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY``
      - Use only luminance component.

``V4L2_CID_JPEG_RESTART_INTERVAL (integer)``
    The restart interval determines an interval of inserting RSTm
    markers (m = 0..7). The purpose of these markers is to additionally
    reinitialize the encoder process, in order to process blocks of an
    image independently. For the lossy compression processes the restart
    interval unit is MCU (Minimum Coded Unit) and its value is contained
    in DRI (Define Restart Interval) marker. If
    ``V4L2_CID_JPEG_RESTART_INTERVAL`` control is set to 0, DRI and RSTm
    markers will not be inserted.

.. _jpeg-quality-control:

``V4L2_CID_JPEG_COMPRESSION_QUALITY (integer)``
    Determines trade-off between image quality and size.
    It provides simpler method for applications to control image quality,
    without a need for direct reconfiguration of luminance and chrominance
    quantization tables. In cases where a driver uses quantization tables
    configured directly by an application, using interfaces defined
    elsewhere, ``V4L2_CID_JPEG_COMPRESSION_QUALITY`` control should be set by
    driver to 0.

    The value range of this control is driver-specific. Only positive,
    non-zero values are meaningful. The recommended range is 1 - 100,
    where larger values correspond to better image quality.

.. _jpeg-active-marker-control:

``V4L2_CID_JPEG_ACTIVE_MARKER (bitmask)``
    Specify which JPEG markers are included in compressed stream. This
    control is valid only for encoders.

.. flat-table::
    :header-rows:  0
    :stub-columns: 0

    * - ``V4L2_JPEG_ACTIVE_MARKER_APP0``
      - Application data segment APP\ :sub:`0`.
    * - ``V4L2_JPEG_ACTIVE_MARKER_APP1``
      - Application data segment APP\ :sub:`1`.
    * - ``V4L2_JPEG_ACTIVE_MARKER_COM``
      - Comment segment.
    * - ``V4L2_JPEG_ACTIVE_MARKER_DQT``
      - Quantization tables segment.
    * - ``V4L2_JPEG_ACTIVE_MARKER_DHT``
      - Huffman tables segment.

For more details about JPEG specification, refer to :ref:`itu-t81`,
:ref:`jfif`, :ref:`w3c-jpeg-jfif`.


code:
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later

.. _rf-tuner-controls:

**************************
RF Tuner Control Reference
**************************

The RF Tuner (RF_TUNER) class includes controls for common features of
devices having RF tuner.

In this context, RF tuner is radio receiver circuit between antenna and
demodulator. It receives radio frequency (RF) from the antenna and
converts that received signal to lower intermediate frequency (IF) or
baseband frequency (BB). Tuners that could do baseband output are often
called Zero-IF tuners. Older tuners were typically simple PLL tuners
inside a metal box, while newer ones are highly integrated chips
without a metal box "silicon tuners". These controls are mostly
applicable for new feature rich silicon tuners, just because older
tuners does not have much adjustable features.

For more information about RF tuners see
`Tuner (radio) <http://en.wikipedia.org/wiki/Tuner_%28radio%29>`__
and `RF front end <http://en.wikipedia.org/wiki/RF_front_end>`__
from Wikipedia.

.. _rf-tuner-control-id:

RF_TUNER Control IDs
====================

``V4L2_CID_RF_TUNER_CLASS (class)``
    The RF_TUNER class descriptor. Calling
    :ref:`VIDIOC_QUERYCTRL` for this control will
    return a description of this control class.

``V4L2_CID_RF_TUNER_BANDWIDTH_AUTO (boolean)``
    Enables/disables tuner radio channel bandwidth configuration. In
    automatic mode bandwidth configuration is performed by the driver.

``V4L2_CID_RF_TUNER_BANDWIDTH (integer)``
    Filter(s) on tuner signal path are used to filter signal according
    to receiving party needs. Driver configures filters to fulfill
    desired bandwidth requirement. Used when
    V4L2_CID_RF_TUNER_BANDWIDTH_AUTO is not set. Unit is in Hz. The
    range and step are driver-specific.

``V4L2_CID_RF_TUNER_LNA_GAIN_AUTO (boolean)``
    Enables/disables LNA automatic gain control (AGC)

``V4L2_CID_RF_TUNER_MIXER_GAIN_AUTO (boolean)``
    Enables/disables mixer automatic gain control (AGC)

``V4L2_CID_RF_TUNER_IF_GAIN_AUTO (boolean)``
    Enables/disables IF automatic gain control (AGC)

``V4L2_CID_RF_TUNER_RF_GAIN (integer)``
    The RF amplifier is the very first amplifier on the receiver signal
    path, just right after the antenna input. The difference between the
    LNA gain and the RF gain in this document is that the LNA gain is
    integrated in the tuner chip while the RF gain is a separate chip.
    There may be both RF and LNA gain controls in the same device. The
    range and step are driver-specific.

``V4L2_CID_RF_TUNER_LNA_GAIN (integer)``
    LNA (low noise amplifier) gain is first gain stage on the RF tuner
    signal path. It is located very close to tuner antenna input. Used
    when ``V4L2_CID_RF_TUNER_LNA_GAIN_AUTO`` is not set. See
    ``V4L2_CID_RF_TUNER_RF_GAIN`` to understand how RF gain and LNA gain
    differs from the each others. The range and step are
    driver-specific.

``V4L2_CID_RF_TUNER_MIXER_GAIN (integer)``
    Mixer gain is second gain stage on the RF tuner signal path. It is
    located inside mixer block, where RF signal is down-converted by the
    mixer. Used when ``V4L2_CID_RF_TUNER_MIXER_GAIN_AUTO`` is not set.
    The range and step are driver-specific.

``V4L2_CID_RF_TUNER_IF_GAIN (integer)``
    IF gain is last gain stage on the RF tuner signal path. It is
    located on output of RF tuner. It controls signal level of
    intermediate frequency output or baseband output. Used when
    ``V4L2_CID_RF_TUNER_IF_GAIN_AUTO`` is not set. The range and step
    are driver-specific.

``V4L2_CID_RF_TUNER_PLL_LOCK (boolean)``
    Is synthesizer PLL locked? RF tuner is receiving given frequency
    when that control is set. This is a read-only control.


code:
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later

.. _extended-controls:

*********************
Extended Controls API
*********************

Introduction
============

The control mechanism as originally designed was meant to be used for
user settings (brightness, saturation, etc). However, it turned out to
be a very useful model for implementing more complicated driver APIs
where each driver implements only a subset of a larger API.

The MPEG encoding API was the driving force behind designing and
implementing this extended control mechanism: the MPEG standard is quite
large and the currently supported hardware MPEG encoders each only
implement a subset of this standard. Further more, many parameters
relating to how the video is encoded into an MPEG stream are specific to
the MPEG encoding chip since the MPEG standard only defines the format
of the resulting MPEG stream, not how the video is actually encoded into
that format.

Unfortunately, the original control API lacked some features needed for
these new uses and so it was extended into the (not terribly originally
named) extended control API.

Even though the MPEG encoding API was the first effort to use the
Extended Control API, nowadays there are also other classes of Extended
Controls, such as Camera Controls and FM Transmitter Controls. The
Extended Controls API as well as all Extended Controls classes are
described in the following text.

The Extended Control API
========================

Three new ioctls are available:
:ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`,
:ref:`VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` and
:ref:`VIDIOC_TRY_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`. These ioctls act
on arrays of controls (as opposed to the
:ref:`VIDIOC_G_CTRL <VIDIOC_G_CTRL>` and
:ref:`VIDIOC_S_CTRL <VIDIOC_G_CTRL>` ioctls that act on a single
control). This is needed since it is often required to atomically change
several controls at once.

Each of the new ioctls expects a pointer to a struct
:c:type:`v4l2_ext_controls`. This structure
contains a pointer to the control array, a count of the number of
controls in that array and a control class. Control classes are used to
group similar controls into a single class. For example, control class
``V4L2_CTRL_CLASS_USER`` contains all user controls (i. e. all controls
that can also be set using the old :ref:`VIDIOC_S_CTRL <VIDIOC_G_CTRL>`
ioctl). Control class ``V4L2_CTRL_CLASS_CODEC`` contains controls
relating to codecs.

All controls in the control array must belong to the specified control
class. An error is returned if this is not the case.

It is also possible to use an empty control array (``count`` == 0) to check
whether the specified control class is supported.

The control array is a struct
:c:type:`v4l2_ext_control` array. The
struct :c:type:`v4l2_ext_control` is very similar to
struct :c:type:`v4l2_control`, except for the fact that
it also allows for 64-bit values and pointers to be passed.

Since the struct :c:type:`v4l2_ext_control` supports
pointers it is now also possible to have controls with compound types
such as N-dimensional arrays and/or structures. You need to specify the
``V4L2_CTRL_FLAG_NEXT_COMPOUND`` when enumerating controls to actually
be able to see such compound controls. In other words, these controls
with compound types should only be used programmatically.

Since such compound controls need to expose more information about
themselves than is possible with :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>`
the :ref:`VIDIOC_QUERY_EXT_CTRL <VIDIOC_QUERYCTRL>` ioctl was added. In
particular, this ioctl gives the dimensions of the N-dimensional array if
this control consists of more than one element.

.. note::

   #. It is important to realize that due to the flexibility of controls it is
      necessary to check whether the control you want to set actually is
      supported in the driver and what the valid range of values is. So use
      :ref:`VIDIOC_QUERYCTRL` to check this.

   #. It is possible that some of the menu indices in a control of
      type ``V4L2_CTRL_TYPE_MENU`` may not be supported (``VIDIOC_QUERYMENU``
      will return an error). A good example is the list of supported MPEG
      audio bitrates. Some drivers only support one or two bitrates, others
      support a wider range.

All controls use machine endianness.

Enumerating Extended Controls
=============================

The recommended way to enumerate over the extended controls is by using
:ref:`VIDIOC_QUERYCTRL` in combination with the
``V4L2_CTRL_FLAG_NEXT_CTRL`` flag:

.. code-block:: c

    struct v4l2_queryctrl qctrl;

    qctrl.id = V4L2_CTRL_FLAG_NEXT_CTRL;
    while (0 == ioctl (fd, VIDIOC_QUERYCTRL, &qctrl)) {
	/* ... */
	qctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL;
    }

The initial control ID is set to 0 ORed with the
``V4L2_CTRL_FLAG_NEXT_CTRL`` flag. The ``VIDIOC_QUERYCTRL`` ioctl will
return the first control with a higher ID than the specified one. When
no such controls are found an error is returned.

If you want to get all controls within a specific control class, then
you can set the initial ``qctrl.id`` value to the control class and add
an extra check to break out of the loop when a control of another
control class is found:

.. code-block:: c

    qctrl.id = V4L2_CTRL_CLASS_CODEC | V4L2_CTRL_FLAG_NEXT_CTRL;
    while (0 == ioctl(fd, VIDIOC_QUERYCTRL, &qctrl)) {
	if (V4L2_CTRL_ID2CLASS(qctrl.id) != V4L2_CTRL_CLASS_CODEC)
	    break;
	/* ... */
	qctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL;
    }

The 32-bit ``qctrl.id`` value is subdivided into three bit ranges: the
top 4 bits are reserved for flags (e. g. ``V4L2_CTRL_FLAG_NEXT_CTRL``)
and are not actually part of the ID. The remaining 28 bits form the
control ID, of which the most significant 12 bits define the control
class and the least significant 16 bits identify the control within the
control class. It is guaranteed that these last 16 bits are always
non-zero for controls. The range of 0x1000 and up are reserved for
driver-specific controls. The macro ``V4L2_CTRL_ID2CLASS(id)`` returns
the control class ID based on a control ID.

If the driver does not support extended controls, then
``VIDIOC_QUERYCTRL`` will fail when used in combination with
``V4L2_CTRL_FLAG_NEXT_CTRL``. In that case the old method of enumerating
control should be used (see :ref:`enum_all_controls`). But if it is
supported, then it is guaranteed to enumerate over all controls,
including driver-private controls.

Creating Control Panels
=======================

It is possible to create control panels for a graphical user interface
where the user can select the various controls. Basically you will have
to iterate over all controls using the method described above. Each
control class starts with a control of type
``V4L2_CTRL_TYPE_CTRL_CLASS``. ``VIDIOC_QUERYCTRL`` will return the name
of this control class which can be used as the title of a tab page
within a control panel.

The flags field of struct :ref:`v4l2_queryctrl <v4l2-queryctrl>` also
contains hints on the behavior of the control. See the
:ref:`VIDIOC_QUERYCTRL` documentation for more
details.


code:
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later

.. _field-order:

***********
Field Order
***********

We have to distinguish between progressive and interlaced video.
Progressive video transmits all lines of a video image sequentially.
Interlaced video divides an image into two fields, containing only the
odd and even lines of the image, respectively. Alternating the so called
odd and even field are transmitted, and due to a small delay between
fields a cathode ray TV displays the lines interleaved, yielding the
original frame. This curious technique was invented because at refresh
rates similar to film the image would fade out too quickly. Transmitting
fields reduces the flicker without the necessity of doubling the frame
rate and with it the bandwidth required for each channel.

It is important to understand a video camera does not expose one frame
at a time, merely transmitting the frames separated into fields. The
fields are in fact captured at two different instances in time. An
object on screen may well move between one field and the next. For
applications analysing motion it is of paramount importance to recognize
which field of a frame is older, the *temporal order*.

When the driver provides or accepts images field by field rather than
interleaved, it is also important applications understand how the fields
combine to frames. We distinguish between top (aka odd) and bottom (aka
even) fields, the *spatial order*: The first line of the top field is
the first line of an interlaced frame, the first line of the bottom
field is the second line of that frame.

However because fields were captured one after the other, arguing
whether a frame commences with the top or bottom field is pointless. Any
two successive top and bottom, or bottom and top fields yield a valid
frame. Only when the source was progressive to begin with, e. g. when
transferring film to video, two fields may come from the same frame,
creating a natural order.

Counter to intuition the top field is not necessarily the older field.
Whether the older field contains the top or bottom lines is a convention
determined by the video standard. Hence the distinction between temporal
and spatial order of fields. The diagrams below should make this
clearer.

In V4L it is assumed that all video cameras transmit fields on the media
bus in the same order they were captured, so if the top field was
captured first (is the older field), the top field is also transmitted
first on the bus.

All video capture and output devices must report the current field
order. Some drivers may permit the selection of a different order, to
this end applications initialize the ``field`` field of struct
:c:type:`v4l2_pix_format` before calling the
:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl. If this is not desired it
should have the value ``V4L2_FIELD_ANY`` (0).

enum v4l2_field
===============

.. c:type:: v4l2_field

.. tabularcolumns:: |p{5.8cm}|p{0.6cm}|p{10.9cm}|

.. cssclass:: longtable

.. flat-table::
    :header-rows:  0
    :stub-columns: 0
    :widths:       3 1 4

    * - ``V4L2_FIELD_ANY``
      - 0
      - Applications request this field order when any field format
	is acceptable. Drivers choose depending on hardware capabilities or
	e.g. the requested image size, and return the actual field order.
	Drivers must never return ``V4L2_FIELD_ANY``.
	If multiple field orders are possible the
	driver must choose one of the possible field orders during
	:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` or
	:ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>`. struct
	:c:type:`v4l2_buffer` ``field`` can never be
	``V4L2_FIELD_ANY``.
    * - ``V4L2_FIELD_NONE``
      - 1
      - Images are in progressive (frame-based) format, not interlaced
        (field-based).
    * - ``V4L2_FIELD_TOP``
      - 2
      - Images consist of the top (aka odd) field only.
    * - ``V4L2_FIELD_BOTTOM``
      - 3
      - Images consist of the bottom (aka even) field only. Applications
	may wish to prevent a device from capturing interlaced images
	because they will have "comb" or "feathering" artefacts around
	moving objects.
    * - ``V4L2_FIELD_INTERLACED``
      - 4
      - Images contain both fields, interleaved line by line. The temporal
	order of the fields (whether the top or bottom field is older)
	depends on the current video standard. In M/NTSC the bottom
	field is the older field. In all other standards the top field
	is the older field.
    * - ``V4L2_FIELD_SEQ_TB``
      - 5
      - Images contain both fields, the top field lines are stored first
	in memory, immediately followed by the bottom field lines. Fields
	are always stored in temporal order, the older one first in
	memory. Image sizes refer to the frame, not fields.
    * - ``V4L2_FIELD_SEQ_BT``
      - 6
      - Images contain both fields, the bottom field lines are stored
	first in memory, immediately followed by the top field lines.
	Fields are always stored in temporal order, the older one first in
	memory. Image sizes refer to the frame, not fields.
    * - ``V4L2_FIELD_ALTERNATE``
      - 7
      - The two fields of a frame are passed in separate buffers, in
	temporal order, i. e. the older one first. To indicate the field
	parity (whether the current field is a top or bottom field) the
	driver or application, depending on data direction, must set
	struct :c:type:`v4l2_buffer` ``field`` to
	``V4L2_FIELD_TOP`` or ``V4L2_FIELD_BOTTOM``. Any two successive
	fields pair to build a frame. If fields are successive, without
	any dropped fields between them (fields can drop individually),
	can be determined from the struct
	:c:type:`v4l2_buffer` ``sequence`` field. This
	format cannot be selected when using the read/write I/O method
	since there is no way to communicate if a field was a top or
	bottom field.
    * - ``V4L2_FIELD_INTERLACED_TB``
      - 8
      - Images contain both fields, interleaved line by line, top field
	first. The top field is the older field.
    * - ``V4L2_FIELD_INTERLACED_BT``
      - 9
      - Images contain both fields, interleaved line by line, top field
	first. The bottom field is the older field.

.. _fieldseq-tb:

Field Order, Top Field First Transmitted
========================================

.. kernel-figure:: fieldseq_tb.svg
    :alt:    fieldseq_tb.svg
    :align:  center

    Field Order, Top Field First Transmitted

.. _fieldseq-bt:

Field Order, Bottom Field First Transmitted
===========================================

.. kernel-figure:: fieldseq_bt.svg
    :alt:    fieldseq_bt.svg
    :align:  center

    Field Order, Bottom Field First Transmitted