:header-rows: 1
:stub-columns: 0
-
- - .. row 1
-
- - Device Type
-
- - File Name
-
- - Minor Numbers
-
- - .. row 2
-
- - Video capture and overlay
-
- - ``/dev/video`` and ``/dev/bttv0``\ [#f1]_, ``/dev/video0`` to
- ``/dev/video63``
-
- - 0-63
-
- - .. row 3
-
- - Radio receiver
-
- - ``/dev/radio``\ [#f2]_, ``/dev/radio0`` to ``/dev/radio63``
-
- - 64-127
-
- - .. row 4
-
- - Raw VBI capture
-
- - ``/dev/vbi``, ``/dev/vbi0`` to ``/dev/vbi31``
-
- - 224-255
+ * - Device Type
+ - File Name
+ - Minor Numbers
+ * - Video capture and overlay
+ - ``/dev/video`` and ``/dev/bttv0``\ [#f1]_, ``/dev/video0`` to
+ ``/dev/video63``
+ - 0-63
+ * - Radio receiver
+ - ``/dev/radio``\ [#f2]_, ``/dev/radio0`` to ``/dev/radio63``
+ - 64-127
+ * - Raw VBI capture
+ - ``/dev/vbi``, ``/dev/vbi0`` to ``/dev/vbi31``
+ - 224-255
V4L prohibits (or used to prohibit) multiple opens of a device file.
The V4L ``VIDIOCGCAP`` ioctl is equivalent to V4L2's
:ref:`VIDIOC_QUERYCAP`.
-The ``name`` field in struct :c:type:`struct video_capability` became
-``card`` in struct :ref:`v4l2_capability <v4l2-capability>`, ``type``
+The ``name`` field in struct ``video_capability`` became
+``card`` in struct :c:type:`v4l2_capability`, ``type``
was replaced by ``capabilities``. Note V4L2 does not distinguish between
device types like this, better think of basic video input, video output
and radio devices supporting a set of related functions like video
capturing, video overlay and VBI capturing. See :ref:`open` for an
introduction.
+.. tabularcolumns:: |p{5.5cm}|p{6.5cm}|p{5.5cm}
+.. cssclass:: longtable
.. flat-table::
:header-rows: 1
:stub-columns: 0
-
- - .. row 1
-
- - struct :c:type:`struct video_capability` ``type``
-
- - struct :ref:`v4l2_capability <v4l2-capability>`
- ``capabilities`` flags
-
- - Purpose
-
- - .. row 2
-
- - ``VID_TYPE_CAPTURE``
-
- - ``V4L2_CAP_VIDEO_CAPTURE``
-
- - The :ref:`video capture <capture>` interface is supported.
-
- - .. row 3
-
- - ``VID_TYPE_TUNER``
-
- - ``V4L2_CAP_TUNER``
-
- - The device has a :ref:`tuner or modulator <tuner>`.
-
- - .. row 4
-
- - ``VID_TYPE_TELETEXT``
-
- - ``V4L2_CAP_VBI_CAPTURE``
-
- - The :ref:`raw VBI capture <raw-vbi>` interface is supported.
-
- - .. row 5
-
- - ``VID_TYPE_OVERLAY``
-
- - ``V4L2_CAP_VIDEO_OVERLAY``
-
- - The :ref:`video overlay <overlay>` interface is supported.
-
- - .. row 6
-
- - ``VID_TYPE_CHROMAKEY``
-
- - ``V4L2_FBUF_CAP_CHROMAKEY`` in field ``capability`` of struct
- :ref:`v4l2_framebuffer <v4l2-framebuffer>`
-
- - Whether chromakey overlay is supported. For more information on
- overlay see :ref:`overlay`.
-
- - .. row 7
-
- - ``VID_TYPE_CLIPPING``
-
- - ``V4L2_FBUF_CAP_LIST_CLIPPING`` and
- ``V4L2_FBUF_CAP_BITMAP_CLIPPING`` in field ``capability`` of
- struct :ref:`v4l2_framebuffer <v4l2-framebuffer>`
-
- - Whether clipping the overlaid image is supported, see
- :ref:`overlay`.
-
- - .. row 8
-
- - ``VID_TYPE_FRAMERAM``
-
- - ``V4L2_FBUF_CAP_EXTERNOVERLAY`` *not set* in field ``capability``
- of struct :ref:`v4l2_framebuffer <v4l2-framebuffer>`
-
- - Whether overlay overwrites frame buffer memory, see
- :ref:`overlay`.
-
- - .. row 9
-
- - ``VID_TYPE_SCALES``
-
- - ``-``
-
- - This flag indicates if the hardware can scale images. The V4L2 API
- implies the scale factor by setting the cropping dimensions and
- image size with the :ref:`VIDIOC_S_CROP <VIDIOC_G_CROP>` and
- :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, respectively. The
- driver returns the closest sizes possible. For more information on
- cropping and scaling see :ref:`crop`.
-
- - .. row 10
-
- - ``VID_TYPE_MONOCHROME``
-
- - ``-``
-
- - Applications can enumerate the supported image formats with the
- :ref:`VIDIOC_ENUM_FMT` ioctl to determine if
- the device supports grey scale capturing only. For more
- information on image formats see :ref:`pixfmt`.
-
- - .. row 11
-
- - ``VID_TYPE_SUBCAPTURE``
-
- - ``-``
-
- - Applications can call the :ref:`VIDIOC_G_CROP <VIDIOC_G_CROP>`
- ioctl to determine if the device supports capturing a subsection
- of the full picture ("cropping" in V4L2). If not, the ioctl
- returns the ``EINVAL`` error code. For more information on cropping
- and scaling see :ref:`crop`.
-
- - .. row 12
-
- - ``VID_TYPE_MPEG_DECODER``
-
- - ``-``
-
- - Applications can enumerate the supported image formats with the
- :ref:`VIDIOC_ENUM_FMT` ioctl to determine if
- the device supports MPEG streams.
-
- - .. row 13
-
- - ``VID_TYPE_MPEG_ENCODER``
-
- - ``-``
-
- - See above.
-
- - .. row 14
-
- - ``VID_TYPE_MJPEG_DECODER``
-
- - ``-``
-
- - See above.
-
- - .. row 15
-
- - ``VID_TYPE_MJPEG_ENCODER``
-
- - ``-``
-
- - See above.
+ * - ``struct video_capability`` ``type``
+ - struct :c:type:`v4l2_capability`
+ ``capabilities`` flags
+ - Purpose
+ * - ``VID_TYPE_CAPTURE``
+ - ``V4L2_CAP_VIDEO_CAPTURE``
+ - The :ref:`video capture <capture>` interface is supported.
+ * - ``VID_TYPE_TUNER``
+ - ``V4L2_CAP_TUNER``
+ - The device has a :ref:`tuner or modulator <tuner>`.
+ * - ``VID_TYPE_TELETEXT``
+ - ``V4L2_CAP_VBI_CAPTURE``
+ - The :ref:`raw VBI capture <raw-vbi>` interface is supported.
+ * - ``VID_TYPE_OVERLAY``
+ - ``V4L2_CAP_VIDEO_OVERLAY``
+ - The :ref:`video overlay <overlay>` interface is supported.
+ * - ``VID_TYPE_CHROMAKEY``
+ - ``V4L2_FBUF_CAP_CHROMAKEY`` in field ``capability`` of struct
+ :c:type:`v4l2_framebuffer`
+ - Whether chromakey overlay is supported. For more information on
+ overlay see :ref:`overlay`.
+ * - ``VID_TYPE_CLIPPING``
+ - ``V4L2_FBUF_CAP_LIST_CLIPPING`` and
+ ``V4L2_FBUF_CAP_BITMAP_CLIPPING`` in field ``capability`` of
+ struct :c:type:`v4l2_framebuffer`
+ - Whether clipping the overlaid image is supported, see
+ :ref:`overlay`.
+ * - ``VID_TYPE_FRAMERAM``
+ - ``V4L2_FBUF_CAP_EXTERNOVERLAY`` *not set* in field ``capability``
+ of struct :c:type:`v4l2_framebuffer`
+ - Whether overlay overwrites frame buffer memory, see
+ :ref:`overlay`.
+ * - ``VID_TYPE_SCALES``
+ - ``-``
+ - This flag indicates if the hardware can scale images. The V4L2 API
+ implies the scale factor by setting the cropping dimensions and
+ image size with the :ref:`VIDIOC_S_CROP <VIDIOC_G_CROP>` and
+ :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, respectively. The
+ driver returns the closest sizes possible. For more information on
+ cropping and scaling see :ref:`crop`.
+ * - ``VID_TYPE_MONOCHROME``
+ - ``-``
+ - Applications can enumerate the supported image formats with the
+ :ref:`VIDIOC_ENUM_FMT` ioctl to determine if
+ the device supports grey scale capturing only. For more
+ information on image formats see :ref:`pixfmt`.
+ * - ``VID_TYPE_SUBCAPTURE``
+ - ``-``
+ - Applications can call the :ref:`VIDIOC_G_CROP <VIDIOC_G_CROP>`
+ ioctl to determine if the device supports capturing a subsection
+ of the full picture ("cropping" in V4L2). If not, the ioctl
+ returns the ``EINVAL`` error code. For more information on cropping
+ and scaling see :ref:`crop`.
+ * - ``VID_TYPE_MPEG_DECODER``
+ - ``-``
+ - Applications can enumerate the supported image formats with the
+ :ref:`VIDIOC_ENUM_FMT` ioctl to determine if
+ the device supports MPEG streams.
+ * - ``VID_TYPE_MPEG_ENCODER``
+ - ``-``
+ - See above.
+ * - ``VID_TYPE_MJPEG_DECODER``
+ - ``-``
+ - See above.
+ * - ``VID_TYPE_MJPEG_ENCODER``
+ - ``-``
+ - See above.
The ``audios`` field was replaced by ``capabilities`` flag
=============
V4L provides the ``VIDIOCGCHAN`` and ``VIDIOCSCHAN`` ioctl using struct
-:c:type:`struct video_channel` to enumerate the video inputs of a V4L
+``video_channel`` to enumerate the video inputs of a V4L
device. The equivalent V4L2 ioctls are
:ref:`VIDIOC_ENUMINPUT`,
:ref:`VIDIOC_G_INPUT <VIDIOC_G_INPUT>` and
:ref:`VIDIOC_S_INPUT <VIDIOC_G_INPUT>` using struct
-:ref:`v4l2_input <v4l2-input>` as discussed in :ref:`video`.
+:c:type:`v4l2_input` as discussed in :ref:`video`.
The ``channel`` field counting inputs was renamed to ``index``, the
video input types were renamed as follows:
:header-rows: 1
:stub-columns: 0
-
- - .. row 1
-
- - struct :c:type:`struct video_channel` ``type``
-
- - struct :ref:`v4l2_input <v4l2-input>` ``type``
-
- - .. row 2
-
- - ``VIDEO_TYPE_TV``
-
- - ``V4L2_INPUT_TYPE_TUNER``
-
- - .. row 3
-
- - ``VIDEO_TYPE_CAMERA``
-
- - ``V4L2_INPUT_TYPE_CAMERA``
+ * - struct ``video_channel`` ``type``
+ - struct :c:type:`v4l2_input` ``type``
+ * - ``VIDEO_TYPE_TV``
+ - ``V4L2_INPUT_TYPE_TUNER``
+ * - ``VIDEO_TYPE_CAMERA``
+ - ``V4L2_INPUT_TYPE_CAMERA``
Unlike the ``tuners`` field expressing the number of tuners of this
However a tuner can have more than one input, i. e. RF connectors, and a
device can have multiple tuners. The index number of the tuner
associated with the input, if any, is stored in field ``tuner`` of
-struct :ref:`v4l2_input <v4l2-input>`. Enumeration of tuners is
+struct :c:type:`v4l2_input`. Enumeration of tuners is
discussed in :ref:`tuner`.
The redundant ``VIDEO_VC_TUNER`` flag was dropped. Video inputs
======
The V4L ``VIDIOCGTUNER`` and ``VIDIOCSTUNER`` ioctl and struct
-:c:type:`struct video_tuner` can be used to enumerate the tuners of a
+``video_tuner`` can be used to enumerate the tuners of a
V4L TV or radio device. The equivalent V4L2 ioctls are
:ref:`VIDIOC_G_TUNER <VIDIOC_G_TUNER>` and
:ref:`VIDIOC_S_TUNER <VIDIOC_G_TUNER>` using struct
-:ref:`v4l2_tuner <v4l2-tuner>`. Tuners are covered in :ref:`tuner`.
+:c:type:`v4l2_tuner`. Tuners are covered in :ref:`tuner`.
The ``tuner`` field counting tuners was renamed to ``index``. The fields
``name``, ``rangelow`` and ``rangehigh`` remained unchanged.
The ``VIDEO_TUNER_PAL``, ``VIDEO_TUNER_NTSC`` and ``VIDEO_TUNER_SECAM``
flags indicating the supported video standards were dropped. This
information is now contained in the associated struct
-:ref:`v4l2_input <v4l2-input>`. No replacement exists for the
+:c:type:`v4l2_input`. No replacement exists for the
``VIDEO_TUNER_NORM`` flag indicating whether the video standard can be
switched. The ``mode`` field to select a different video standard was
replaced by a whole new set of ioctls and structures described in
The ``VIDEO_TUNER_STEREO_ON`` flag indicating stereo reception became
``V4L2_TUNER_SUB_STEREO`` in field ``rxsubchans``. This field also
permits the detection of monaural and bilingual audio, see the
-definition of struct :ref:`v4l2_tuner <v4l2-tuner>` for details.
+definition of struct :c:type:`v4l2_tuner` for details.
Presently no replacement exists for the ``VIDEO_TUNER_RDS_ON`` and
``VIDEO_TUNER_MBS_ON`` flags.
The ``VIDEO_TUNER_LOW`` flag was renamed to ``V4L2_TUNER_CAP_LOW`` in
-the struct :ref:`v4l2_tuner <v4l2-tuner>` ``capability`` field.
+the struct :c:type:`v4l2_tuner` ``capability`` field.
The ``VIDIOCGFREQ`` and ``VIDIOCSFREQ`` ioctl to change the tuner
frequency where renamed to
:ref:`VIDIOC_G_FREQUENCY <VIDIOC_G_FREQUENCY>` and
:ref:`VIDIOC_S_FREQUENCY <VIDIOC_G_FREQUENCY>`. They take a pointer
-to a struct :ref:`v4l2_frequency <v4l2-frequency>` instead of an
+to a struct :c:type:`v4l2_frequency` instead of an
unsigned long integer.
================
V4L2 has no equivalent of the ``VIDIOCGPICT`` and ``VIDIOCSPICT`` ioctl
-and struct :c:type:`struct video_picture`. The following fields where
+and struct ``video_picture``. The following fields where
replaced by V4L2 controls accessible with the
:ref:`VIDIOC_QUERYCTRL`,
:ref:`VIDIOC_G_CTRL <VIDIOC_G_CTRL>` and
:header-rows: 1
:stub-columns: 0
-
- - .. row 1
-
- - struct :c:type:`struct video_picture`
-
- - V4L2 Control ID
-
- - .. row 2
-
- - ``brightness``
-
- - ``V4L2_CID_BRIGHTNESS``
-
- - .. row 3
-
- - ``hue``
-
- - ``V4L2_CID_HUE``
-
- - .. row 4
-
- - ``colour``
-
- - ``V4L2_CID_SATURATION``
-
- - .. row 5
-
- - ``contrast``
-
- - ``V4L2_CID_CONTRAST``
-
- - .. row 6
-
- - ``whiteness``
-
- - ``V4L2_CID_WHITENESS``
+ * - struct ``video_picture``
+ - V4L2 Control ID
+ * - ``brightness``
+ - ``V4L2_CID_BRIGHTNESS``
+ * - ``hue``
+ - ``V4L2_CID_HUE``
+ * - ``colour``
+ - ``V4L2_CID_SATURATION``
+ * - ``contrast``
+ - ``V4L2_CID_CONTRAST``
+ * - ``whiteness``
+ - ``V4L2_CID_WHITENESS``
The V4L picture controls are assumed to range from 0 to 65535 with no
implied by the selected image format. V4L2 does not explicitly provide
such information assuming applications recognizing the format are aware
of the image depth and others need not know. The ``palette`` field moved
-into the struct :ref:`v4l2_pix_format <v4l2-pix-format>`:
+into the struct :c:type:`v4l2_pix_format`:
:header-rows: 1
:stub-columns: 0
-
- - .. row 1
-
- - struct :c:type:`struct video_picture` ``palette``
-
- - struct :ref:`v4l2_pix_format <v4l2-pix-format>` ``pixfmt``
-
- - .. row 2
-
- - ``VIDEO_PALETTE_GREY``
-
- - :ref:`V4L2_PIX_FMT_GREY <V4L2-PIX-FMT-GREY>`
-
- - .. row 3
-
- - ``VIDEO_PALETTE_HI240``
-
- - :ref:`V4L2_PIX_FMT_HI240 <pixfmt-reserved>` [#f3]_
-
- - .. row 4
-
- - ``VIDEO_PALETTE_RGB565``
-
- - :ref:`V4L2_PIX_FMT_RGB565 <pixfmt-rgb>`
-
- - .. row 5
-
- - ``VIDEO_PALETTE_RGB555``
-
- - :ref:`V4L2_PIX_FMT_RGB555 <pixfmt-rgb>`
-
- - .. row 6
-
- - ``VIDEO_PALETTE_RGB24``
-
- - :ref:`V4L2_PIX_FMT_BGR24 <pixfmt-rgb>`
-
- - .. row 7
-
- - ``VIDEO_PALETTE_RGB32``
-
- - :ref:`V4L2_PIX_FMT_BGR32 <pixfmt-rgb>` [#f4]_
-
- - .. row 8
-
- - ``VIDEO_PALETTE_YUV422``
-
- - :ref:`V4L2_PIX_FMT_YUYV <V4L2-PIX-FMT-YUYV>`
-
- - .. row 9
-
- - ``VIDEO_PALETTE_YUYV``\ [#f5]_
-
- - :ref:`V4L2_PIX_FMT_YUYV <V4L2-PIX-FMT-YUYV>`
-
- - .. row 10
-
- - ``VIDEO_PALETTE_UYVY``
-
- - :ref:`V4L2_PIX_FMT_UYVY <V4L2-PIX-FMT-UYVY>`
-
- - .. row 11
-
- - ``VIDEO_PALETTE_YUV420``
-
- - None
-
- - .. row 12
-
- - ``VIDEO_PALETTE_YUV411``
-
- - :ref:`V4L2_PIX_FMT_Y41P <V4L2-PIX-FMT-Y41P>` [#f6]_
-
- - .. row 13
-
- - ``VIDEO_PALETTE_RAW``
-
- - None [#f7]_
-
- - .. row 14
-
- - ``VIDEO_PALETTE_YUV422P``
-
- - :ref:`V4L2_PIX_FMT_YUV422P <V4L2-PIX-FMT-YUV422P>`
-
- - .. row 15
-
- - ``VIDEO_PALETTE_YUV411P``
-
- - :ref:`V4L2_PIX_FMT_YUV411P <V4L2-PIX-FMT-YUV411P>` [#f8]_
-
- - .. row 16
-
- - ``VIDEO_PALETTE_YUV420P``
-
- - :ref:`V4L2_PIX_FMT_YVU420 <V4L2-PIX-FMT-YVU420>`
-
- - .. row 17
-
- - ``VIDEO_PALETTE_YUV410P``
-
- - :ref:`V4L2_PIX_FMT_YVU410 <V4L2-PIX-FMT-YVU410>`
+ * - struct ``video_picture`` ``palette``
+ - struct :c:type:`v4l2_pix_format` ``pixfmt``
+ * - ``VIDEO_PALETTE_GREY``
+ - :ref:`V4L2_PIX_FMT_GREY <V4L2-PIX-FMT-GREY>`
+ * - ``VIDEO_PALETTE_HI240``
+ - :ref:`V4L2_PIX_FMT_HI240 <pixfmt-reserved>` [#f3]_
+ * - ``VIDEO_PALETTE_RGB565``
+ - :ref:`V4L2_PIX_FMT_RGB565 <pixfmt-rgb>`
+ * - ``VIDEO_PALETTE_RGB555``
+ - :ref:`V4L2_PIX_FMT_RGB555 <pixfmt-rgb>`
+ * - ``VIDEO_PALETTE_RGB24``
+ - :ref:`V4L2_PIX_FMT_BGR24 <pixfmt-rgb>`
+ * - ``VIDEO_PALETTE_RGB32``
+ - :ref:`V4L2_PIX_FMT_BGR32 <pixfmt-rgb>` [#f4]_
+ * - ``VIDEO_PALETTE_YUV422``
+ - :ref:`V4L2_PIX_FMT_YUYV <V4L2-PIX-FMT-YUYV>`
+ * - ``VIDEO_PALETTE_YUYV``\ [#f5]_
+ - :ref:`V4L2_PIX_FMT_YUYV <V4L2-PIX-FMT-YUYV>`
+ * - ``VIDEO_PALETTE_UYVY``
+ - :ref:`V4L2_PIX_FMT_UYVY <V4L2-PIX-FMT-UYVY>`
+ * - ``VIDEO_PALETTE_YUV420``
+ - None
+ * - ``VIDEO_PALETTE_YUV411``
+ - :ref:`V4L2_PIX_FMT_Y41P <V4L2-PIX-FMT-Y41P>` [#f6]_
+ * - ``VIDEO_PALETTE_RAW``
+ - None [#f7]_
+ * - ``VIDEO_PALETTE_YUV422P``
+ - :ref:`V4L2_PIX_FMT_YUV422P <V4L2-PIX-FMT-YUV422P>`
+ * - ``VIDEO_PALETTE_YUV411P``
+ - :ref:`V4L2_PIX_FMT_YUV411P <V4L2-PIX-FMT-YUV411P>` [#f8]_
+ * - ``VIDEO_PALETTE_YUV420P``
+ - :ref:`V4L2_PIX_FMT_YVU420 <V4L2-PIX-FMT-YVU420>`
+ * - ``VIDEO_PALETTE_YUV410P``
+ - :ref:`V4L2_PIX_FMT_YVU410 <V4L2-PIX-FMT-YVU410>`
V4L2 image formats are defined in :ref:`pixfmt`. The image format can
=====
The ``VIDIOCGAUDIO`` and ``VIDIOCSAUDIO`` ioctl and struct
-:c:type:`struct video_audio` are used to enumerate the audio inputs
+``video_audio`` are used to enumerate the audio inputs
of a V4L device. The equivalent V4L2 ioctls are
:ref:`VIDIOC_G_AUDIO <VIDIOC_G_AUDIO>` and
:ref:`VIDIOC_S_AUDIO <VIDIOC_G_AUDIO>` using struct
-:ref:`v4l2_audio <v4l2-audio>` as discussed in :ref:`audio`.
+:c:type:`v4l2_audio` as discussed in :ref:`audio`.
The ``audio`` "channel number" field counting audio inputs was renamed
to ``index``.
specification, there is no way to query the selected mode. On
``VIDIOCGAUDIO`` the driver returns the *actually received* audio
programmes in this field. In the V4L2 API this information is stored in
-the struct :ref:`v4l2_tuner <v4l2-tuner>` ``rxsubchans`` and
+the struct :c:type:`v4l2_tuner` ``rxsubchans`` and
``audmode`` fields, respectively. See :ref:`tuner` for more
information on tuners. Related to audio modes struct
-:ref:`v4l2_audio <v4l2-audio>` also reports if this is a mono or
+:c:type:`v4l2_audio` also reports if this is a mono or
stereo input, regardless if the source is a tuner.
The following fields where replaced by V4L2 controls accessible with the
:header-rows: 1
:stub-columns: 0
-
- - .. row 1
-
- - struct :c:type:`struct video_audio`
-
- - V4L2 Control ID
-
- - .. row 2
-
- - ``volume``
-
- - ``V4L2_CID_AUDIO_VOLUME``
-
- - .. row 3
-
- - ``bass``
-
- - ``V4L2_CID_AUDIO_BASS``
-
- - .. row 4
-
- - ``treble``
-
- - ``V4L2_CID_AUDIO_TREBLE``
-
- - .. row 5
-
- - ``balance``
-
- - ``V4L2_CID_AUDIO_BALANCE``
+ * - struct ``video_audio``
+ - V4L2 Control ID
+ * - ``volume``
+ - ``V4L2_CID_AUDIO_VOLUME``
+ * - ``bass``
+ - ``V4L2_CID_AUDIO_BASS``
+ * - ``treble``
+ - ``V4L2_CID_AUDIO_TREBLE``
+ * - ``balance``
+ - ``V4L2_CID_AUDIO_BALANCE``
To determine which of these controls are supported by a driver V4L
``V4L2_CID_AUDIO_MUTE`` control.
All V4L2 controls have a ``step`` attribute replacing the struct
-:c:type:`struct video_audio` ``step`` field. The V4L audio controls
+``video_audio`` ``step`` field. The V4L audio controls
are assumed to range from 0 to 65535 with no particular reset value. The
V4L2 API permits arbitrary limits and defaults which can be queried with
the :ref:`VIDIOC_QUERYCTRL` ioctl. For general
The V4L2 ioctls equivalent to ``VIDIOCGFBUF`` and ``VIDIOCSFBUF`` are
:ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` and
:ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>`. The ``base`` field of struct
-:c:type:`struct video_buffer` remained unchanged, except V4L2 defines
+``video_buffer`` remained unchanged, except V4L2 defines
a flag to indicate non-destructive overlays instead of a ``NULL``
pointer. All other fields moved into the struct
-:ref:`v4l2_pix_format <v4l2-pix-format>` ``fmt`` substructure of
-struct :ref:`v4l2_framebuffer <v4l2-framebuffer>`. The ``depth``
+:c:type:`v4l2_pix_format` ``fmt`` substructure of
+struct :c:type:`v4l2_framebuffer`. The ``depth``
field was replaced by ``pixelformat``. See :ref:`pixfmt-rgb` for a
list of RGB formats and their respective color depths.
uses the general-purpose data format negotiation ioctls
:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` and
:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`. They take a pointer to a struct
-:ref:`v4l2_format <v4l2-format>` as argument. Here the ``win`` member
+:c:type:`v4l2_format` as argument. Here the ``win`` member
of the ``fmt`` union is used, a struct
-:ref:`v4l2_window <v4l2-window>`.
+:c:type:`v4l2_window`.
The ``x``, ``y``, ``width`` and ``height`` fields of struct
-:c:type:`struct video_window` moved into struct
-:ref:`v4l2_rect <v4l2-rect>` substructure ``w`` of struct
-:c:type:`struct v4l2_window`. The ``chromakey``, ``clips``, and
+``video_window`` moved into struct
+:c:type:`v4l2_rect` substructure ``w`` of struct
+:c:type:`v4l2_window`. The ``chromakey``, ``clips``, and
``clipcount`` fields remained unchanged. Struct
-:c:type:`struct video_clip` was renamed to struct
-:ref:`v4l2_clip <v4l2-clip>`, also containing a struct
-:c:type:`struct v4l2_rect`, but the semantics are still the same.
+``video_clip`` was renamed to struct
+:c:type:`v4l2_clip`, also containing a struct
+:c:type:`v4l2_rect`, but the semantics are still the same.
The ``VIDEO_WINDOW_INTERLACE`` flag was dropped. Instead applications
must set the ``field`` field to ``V4L2_FIELD_ANY`` or
``V4L2_FIELD_INTERLACED``. The ``VIDEO_WINDOW_CHROMAKEY`` flag moved
-into struct :ref:`v4l2_framebuffer <v4l2-framebuffer>`, under the new
+into struct :c:type:`v4l2_framebuffer`, under the new
name ``V4L2_FBUF_FLAG_CHROMAKEY``.
In V4L, storing a bitmap pointer in ``clips`` and setting ``clipcount``
to ``VIDEO_CLIP_BITMAP`` (-1) requests bitmap clipping, using a fixed
-size bitmap of 1024 × 625 bits. Struct :c:type:`struct v4l2_window`
+size bitmap of 1024 × 625 bits. Struct :c:type:`v4l2_window`
has a separate ``bitmap`` pointer field for this purpose and the bitmap
size is determined by ``w.width`` and ``w.height``.
To capture only a subsection of the full picture V4L defines the
``VIDIOCGCAPTURE`` and ``VIDIOCSCAPTURE`` ioctls using struct
-:c:type:`struct video_capture`. The equivalent V4L2 ioctls are
+``video_capture``. The equivalent V4L2 ioctls are
:ref:`VIDIOC_G_CROP <VIDIOC_G_CROP>` and
:ref:`VIDIOC_S_CROP <VIDIOC_G_CROP>` using struct
-:ref:`v4l2_crop <v4l2-crop>`, and the related
+:c:type:`v4l2_crop`, and the related
:ref:`VIDIOC_CROPCAP` ioctl. This is a rather
complex matter, see :ref:`crop` for details.
The ``x``, ``y``, ``width`` and ``height`` fields moved into struct
-:ref:`v4l2_rect <v4l2-rect>` substructure ``c`` of struct
-:c:type:`struct v4l2_crop`. The ``decimation`` field was dropped. In
+:c:type:`v4l2_rect` substructure ``c`` of struct
+:c:type:`v4l2_crop`. The ``decimation`` field was dropped. In
the V4L2 API the scaling factor is implied by the size of the cropping
rectangle and the size of the captured or overlaid image.
The ``VIDEO_CAPTURE_ODD`` and ``VIDEO_CAPTURE_EVEN`` flags to capture
only the odd or even field, respectively, were replaced by
``V4L2_FIELD_TOP`` and ``V4L2_FIELD_BOTTOM`` in the field named
-``field`` of struct :ref:`v4l2_pix_format <v4l2-pix-format>` and
-struct :ref:`v4l2_window <v4l2-window>`. These structures are used to
+``field`` of struct :c:type:`v4l2_pix_format` and
+struct :c:type:`v4l2_window`. These structures are used to
select a capture or overlay format with the
:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl.
``VIDIOCSWIN`` ioctls. V4L2 uses the general-purpose data format
negotiation ioctls :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` and
:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`. They take a pointer to a struct
-:ref:`v4l2_format <v4l2-format>` as argument, here the struct
-:ref:`v4l2_pix_format <v4l2-pix-format>` named ``pix`` of its
+:c:type:`v4l2_format` as argument, here the struct
+:c:type:`v4l2_pix_format` named ``pix`` of its
``fmt`` union is used.
For more information about the V4L2 read interface see :ref:`rw`.
:header-rows: 1
:stub-columns: 0
-
- - .. row 1
-
- - V4L
-
- - V4L2
-
- - .. row 2
-
- -
- - The image format must be selected before buffers are allocated,
- with the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl. When no
- format is selected the driver may use the last, possibly by
- another application requested format.
-
- - .. row 3
-
- - Applications cannot change the number of buffers. The it is built
- into the driver, unless it has a module option to change the
- number when the driver module is loaded.
-
- - The :ref:`VIDIOC_REQBUFS` ioctl allocates the
- desired number of buffers, this is a required step in the
- initialization sequence.
-
- - .. row 4
-
- - Drivers map all buffers as one contiguous range of memory. The
- ``VIDIOCGMBUF`` ioctl is available to query the number of buffers,
- the offset of each buffer from the start of the virtual file, and
- the overall amount of memory used, which can be used as arguments
- for the :ref:`mmap() <func-mmap>` function.
-
- - Buffers are individually mapped. The offset and size of each
- buffer can be determined with the
- :ref:`VIDIOC_QUERYBUF` ioctl.
-
- - .. row 5
-
- - The ``VIDIOCMCAPTURE`` ioctl prepares a buffer for capturing. It
- also determines the image format for this buffer. The ioctl
- returns immediately, eventually with an ``EAGAIN`` error code if no
- video signal had been detected. When the driver supports more than
- one buffer applications can call the ioctl multiple times and thus
- have multiple outstanding capture requests.
-
- The ``VIDIOCSYNC`` ioctl suspends execution until a particular
- buffer has been filled.
-
- - Drivers maintain an incoming and outgoing queue.
- :ref:`VIDIOC_QBUF` enqueues any empty buffer into
- the incoming queue. Filled buffers are dequeued from the outgoing
- queue with the :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. To wait
- until filled buffers become available this function,
- :ref:`select() <func-select>` or :ref:`poll() <func-poll>` can
- be used. The :ref:`VIDIOC_STREAMON` ioctl
- must be called once after enqueuing one or more buffers to start
- capturing. Its counterpart
- :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` stops capturing and
- dequeues all buffers from both queues. Applications can query the
- signal status, if known, with the
- :ref:`VIDIOC_ENUMINPUT` ioctl.
+ * - V4L
+ - V4L2
+ * -
+ - The image format must be selected before buffers are allocated,
+ with the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl. When no
+ format is selected the driver may use the last, possibly by
+ another application requested format.
+ * - Applications cannot change the number of buffers. The it is built
+ into the driver, unless it has a module option to change the
+ number when the driver module is loaded.
+ - The :ref:`VIDIOC_REQBUFS` ioctl allocates the
+ desired number of buffers, this is a required step in the
+ initialization sequence.
+ * - Drivers map all buffers as one contiguous range of memory. The
+ ``VIDIOCGMBUF`` ioctl is available to query the number of buffers,
+ the offset of each buffer from the start of the virtual file, and
+ the overall amount of memory used, which can be used as arguments
+ for the :ref:`mmap() <func-mmap>` function.
+ - Buffers are individually mapped. The offset and size of each
+ buffer can be determined with the
+ :ref:`VIDIOC_QUERYBUF` ioctl.
+ * - The ``VIDIOCMCAPTURE`` ioctl prepares a buffer for capturing. It
+ also determines the image format for this buffer. The ioctl
+ returns immediately, eventually with an ``EAGAIN`` error code if no
+ video signal had been detected. When the driver supports more than
+ one buffer applications can call the ioctl multiple times and thus
+ have multiple outstanding capture requests.
+
+ The ``VIDIOCSYNC`` ioctl suspends execution until a particular
+ buffer has been filled.
+ - Drivers maintain an incoming and outgoing queue.
+ :ref:`VIDIOC_QBUF` enqueues any empty buffer into
+ the incoming queue. Filled buffers are dequeued from the outgoing
+ queue with the :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. To wait
+ until filled buffers become available this function,
+ :ref:`select() <func-select>` or :ref:`poll() <func-poll>` can
+ be used. The :ref:`VIDIOC_STREAMON` ioctl
+ must be called once after enqueuing one or more buffers to start
+ capturing. Its counterpart
+ :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` stops capturing and
+ dequeues all buffers from both queues. Applications can query the
+ signal status, if known, with the
+ :ref:`VIDIOC_ENUMINPUT` ioctl.
For a more in-depth discussion of memory mapping and examples, see
:header-rows: 1
:stub-columns: 0
-
- - .. row 1
-
- - struct :ref:`v4l2_vbi_format <v4l2-vbi-format>`
-
- - V4L, BTTV driver
-
- - .. row 2
-
- - sampling_rate
-
- - 28636363 Hz NTSC (or any other 525-line standard); 35468950 Hz PAL
- and SECAM (625-line standards)
-
- - .. row 3
-
- - offset
-
- - ?
-
- - .. row 4
-
- - samples_per_line
-
- - 2048
-
- - .. row 5
-
- - sample_format
-
- - V4L2_PIX_FMT_GREY. The last four bytes (a machine endianness
- integer) contain a frame counter.
-
- - .. row 6
-
- - start[]
-
- - 10, 273 NTSC; 22, 335 PAL and SECAM
-
- - .. row 7
-
- - count[]
-
- - 16, 16 [#f9]_
-
- - .. row 8
-
- - flags
-
- - 0
+ * - struct :c:type:`v4l2_vbi_format`
+ - V4L, BTTV driver
+ * - sampling_rate
+ - 28636363 Hz NTSC (or any other 525-line standard); 35468950 Hz PAL
+ and SECAM (625-line standards)
+ * - offset
+ - ?
+ * - samples_per_line
+ - 2048
+ * - sample_format
+ - V4L2_PIX_FMT_GREY. The last four bytes (a machine endianness
+ integer) contain a frame counter.
+ * - start[]
+ - 10, 273 NTSC; 22, 335 PAL and SECAM
+ * - count[]
+ - 16, 16 [#f9]_
+ * - flags
+ - 0
Undocumented in the V4L specification, in Linux 2.3 the
``VIDIOCGVBIFMT`` and ``VIDIOCSVBIFMT`` ioctls using struct
-:c:type:`struct vbi_format` were added to determine the VBI image
+``vbi_format`` were added to determine the VBI image
parameters. These ioctls are only partially compatible with the V4L2 VBI
interface specified in :ref:`raw-vbi`.
An ``offset`` field does not exist, ``sample_format`` is supposed to be
``VIDEO_PALETTE_RAW``, equivalent to ``V4L2_PIX_FMT_GREY``. The
remaining fields are probably equivalent to struct
-:ref:`v4l2_vbi_format <v4l2-vbi-format>`.
+:c:type:`v4l2_vbi_format`.
Apparently only the Zoran (ZR 36120) driver implements these ioctls. The
semantics differ from those specified for V4L2 in two ways. The
projects / cascardo / linux.git / blobdiff