First part of documentation fixups

index 8013c921256b..ea5f6ef25d6b 100644
@@ -25,7 +25,7 @@ kernel_doc_mode = "kernel-doc"
 # ------------------------------------------------------------------------------
 
 project   = u'LINUX MEDIA INFRASTRUCTURE API'
-copyright = u'2009-2015 : LinuxTV Developers'
+copyright = u'2009-2016 : LinuxTV Developers'
 author    = u'The LinuxTV Developers'
 
 # The version info for the project you're documenting, acts as replacement for

index 42b3d4520942..e6df371243d8 100644
@@ -1,10 +1,12 @@
 .. -*- coding: utf-8; mode: rst -*-
 
+.. include:: <isonum.txt>
+
 ##############################
 LINUX MEDIA INFRASTRUCTURE API
 ##############################
 
-**Copyright** 2009-2015 : LinuxTV Developers
+**Copyright** |copy| 2009-2016 : LinuxTV Developers
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.1 or

index 5e513ac86052..daeeb4d64917 100644
@@ -1,5 +1,7 @@
 .. -*- coding: utf-8; mode: rst -*-
 
+.. include:: <isonum.txt>
+
 .. _dvbapi:
 
 #############

@@ -41,9 +43,9 @@ Revision and Copyright
 :address:   [email protected]
 :contrib:   Ported document to Docbook XML.
 
-**Copyright** 2002, 2003 : Convergence GmbH
+**Copyright** |copy| 2002, 2003 : Convergence GmbH
 
-**Copyright** 2009-2015 : Mauro Carvalho Chehab
+**Copyright** |copy| 2009-2016 : Mauro Carvalho Chehab
 
 :revision: 2.1.0 / 2015-05-29 (*mcc*)
 

index e6df371243d8..b0389cbfb1aa 100644
@@ -12,7 +12,7 @@ Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.1 or
 any later version published by the Free Software Foundation. A copy of
 the license is included in the chapter entitled "GNU Free Documentation
-License"
+License".
 
 
 ============

@@ -21,8 +21,8 @@ Introduction
 
 This document covers the Linux Kernel to Userspace API's used by video
 and radio streaming devices, including video cameras, analog and digital
-TV receiver cards, AM/FM receiver cards, streaming capture and output
-devices, codec devices and remote controllers.
+TV receiver cards, AM/FM receiver cards, Software Defined Radio (SDR),
+streaming capture and output devices, codec devices and remote controllers.
 
 A typical media device hardware is shown at
 :ref:`typical_media_device`.

@@ -36,21 +36,17 @@ A typical media device hardware is shown at
 
     Typical Media Device
 
-    Typical Media Device Block Diagram
-
-
-
 The media infrastructure API was designed to control such devices. It is
 divided into four parts.
 
-The first part covers radio, video capture and output, cameras, analog
-TV devices and codecs.
+The first part covers radio, video capture and output,
+cameras, analog TV devices and codecs.
 
 The second part covers the API used for digital TV and Internet
 reception via one of the several digital tv standards. While it is
 called as DVB API, in fact it covers several different video standards
-including DVB-T/T2, DVB-S/S2, DVB-C, ATSC, ISDB-T, ISDB-S,etc. The
-complete list of supported standards can be found at
+including DVB-T/T2, DVB-S/S2, DVB-C, ATSC, ISDB-T, ISDB-S, DTMB, etc.
+The complete list of supported standards can be found at
 :ref:`fe-delivery-system-t`.
 
 The third part covers the Remote Controller API.

@@ -97,6 +93,3 @@ etc, please mail to:
   =========
 
   * :ref:`genindex`
-
-.. todolist::
-

index cf636b665d95..1ddbd67ec466 100644
@@ -1,12 +1,13 @@
 .. -*- coding: utf-8; mode: rst -*-
 
+.. include:: <isonum.txt>
 .. _v4l2spec:
 
 #####################################
 Video for Linux Two API Specification
 #####################################
 
-**Revision 4.4**
+**Revision 4.5**
 
 .. toctree::
     :maxdepth: 1

@@ -30,49 +31,56 @@ Video for Linux Two API Specification
 Revision and Copyright
 **********************
 
+Authors, in alphabetical order:
 
-:author:    Schimek Michael (*H*)
-:address:   [email protected]
+- Ailus, Sakari <[email protected]>
 
-:author:    Dirks Bill
-:contrib:   Original author of the V4L2 API and documentation.
+  - Subdev selections API.
 
-:author:    Verkuil Hans
-:address:   [email protected]
-:contrib:   Designed and documented the VIDIOC_LOG_STATUS ioctl, the extended control ioctls, major parts of the sliced VBI API, the MPEG encoder and decoder APIs and the DV Timings API.
+- Carvalho Chehab, Mauro <[email protected]>
 
-:author:    Rubli Martin
-:contrib:   Designed and documented the VIDIOC_ENUM_FRAMESIZES and VIDIOC_ENUM_FRAMEINTERVALS ioctls.
+  - Documented libv4l, designed and added v4l2grab example, Remote Controller chapter.
 
-:author:    Walls Andy
-:address:   [email protected]
-:contrib:   Documented the fielded V4L2_MPEG_STREAM_VBI_FMT_IVTV MPEG stream embedded, sliced VBI data format in this specification.
+- Dirks, Bill
 
-:author:    Carvalho Chehab Mauro
-:address:   [email protected]
-:contrib:   Documented libv4l, designed and added v4l2grab example, Remote Controller chapter.
+  - Original author of the V4L2 API and documentation.
 
-:author:    Karicheri Muralidharan
-:address:   [email protected]
-:contrib:   Documented the Digital Video timings API.
+- H Schimek, Michael <[email protected]>
 
-:author:    Osciak Pawel
-:address:   pawel AT osciak.com
-:contrib:   Designed and documented the multi-planar API.
+  - Original author of the V4L2 API and documentation.
 
-:author:    Ailus Sakari
-:address:   [email protected]
-:contrib:   Subdev selections API.
+- Karicheri, Muralidharan <[email protected]>
 
-:author:    Palosaari Antti
-:address:   [email protected]
-:contrib:   SDR API.
+  - Documented the Digital Video timings API.
 
-**Copyright** 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015 : Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab, Pawel Osciak
+- Osciak, Pawel <[email protected]>
+
+  - Designed and documented the multi-planar API.
+
+- Palosaari, Antti <[email protected]>
+
+  - SDR API.
+
+- Rubli, Martin
+
+  - Designed and documented the VIDIOC_ENUM_FRAMESIZES and VIDIOC_ENUM_FRAMEINTERVALS ioctls.
+
+- Walls, Andy <[email protected]>
+
+  - Documented the fielded V4L2_MPEG_STREAM_VBI_FMT_IVTV MPEG stream embedded, sliced VBI data format in this specification.
+
+- Verkuil, Hans <[email protected]>
+
+  - Designed and documented the VIDIOC_LOG_STATUS ioctl, the extended control ioctls, major parts of the sliced VBI API, the MPEG encoder and decoder APIs and the DV Timings API.
+
+**Copyright** |copy| 1999-2016: Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab, Pawel Osciak, Sakari Ailus & Antti Palosaari.
 
 Except when explicitly stated as GPL, programming examples within this
 part can be used and distributed without restrictions.
 
+****************
+Revision History
+****************
 
 :revision: 4.5 / 2015-10-29 (*rr*)
 

@@ -254,7 +262,7 @@ packed pixel formats.
 
 Added the Video Output Overlay interface, new MPEG controls,
 V4L2_FIELD_INTERLACED_TB and V4L2_FIELD_INTERLACED_BT,
-VIDIOC_DBG_G/S_REGISTER, VIDIOC_(TRY_)ENCODER_CMD,
+VIDIOC_DBG_G/S_REGISTER, VIDIOC\_(TRY\_)ENCODER_CMD,
 VIDIOC_G_CHIP_IDENT, VIDIOC_G_ENC_INDEX, new pixel formats.
 Clarifications in the cropping chapter, about RGB pixel formats, the
 mmap(), poll(), select(), read() and write() functions. Typographical

@@ -311,7 +319,7 @@ for frame format enumeration of digital devices.
 
 :revision: 0.13 / 2006-04-07 (*mhs*)
 
-Corrected the description of struct v4l2_window clips. New V4L2_STD_
+Corrected the description of struct v4l2_window clips. New V4L2_STD\_
 and V4L2_TUNER_MODE_LANG1_LANG2 defines.
 
 

index 2568820a3954..ce0c0e3f9b53 100644
@@ -16,9 +16,9 @@ check if the kernel device is compatible with this specification, and to
 query the :ref:`functions <devices>` and :ref:`I/O methods <io>`
 supported by the device.
 
-Starting with kernel version 3.1, VIDIOC-QUERYCAP will return the V4L2
-API version used by the driver, with generally matches the Kernel
-version. There's no need of using
+Starting with kernel version 3.1, :ref:`VIDIOC_QUERYCAP <vidioc-querycap>`
+will return the V4L2 API version used by the driver, with generally
+matches the Kernel version. There's no need of using
 :ref:`VIDIOC_QUERYCAP <vidioc-querycap>` to check if a specific ioctl
 is supported, the V4L2 core now returns ENOTTY if a driver doesn't
 provide support for an ioctl.

@@ -30,8 +30,8 @@ abstraction is a major objective of this API, the
 :ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl also allows driver
 specific applications to reliably identify the driver.
 
-All V4L2 drivers must support ``VIDIOC_QUERYCAP``. Applications should
-always call this ioctl after opening the device.
+All V4L2 drivers must support :ref:`VIDIOC_QUERYCAP <vidioc-querycap>`.
+Applications should always call this ioctl after opening the device.
 
 
 .. ------------------------------------------------------------------------------

index b0389cbfb1aa..edb7d56e9b8f 100644
@@ -39,19 +39,19 @@ A typical media device hardware is shown at
 The media infrastructure API was designed to control such devices. It is
 divided into four parts.
 
-The first part covers radio, video capture and output,
+The :Ref:`first part <v4l2spec>` covers radio, video capture and output,
 cameras, analog TV devices and codecs.
 
-The second part covers the API used for digital TV and Internet
-reception via one of the several digital tv standards. While it is
-called as DVB API, in fact it covers several different video standards
-including DVB-T/T2, DVB-S/S2, DVB-C, ATSC, ISDB-T, ISDB-S, DTMB, etc.
-The complete list of supported standards can be found at
+The :Ref:`second part <dvbapi>` covers the API used for digital TV and
+Internet reception via one of the several digital tv standards. While it
+is called as DVB API, in fact it covers several different video
+standards including DVB-T/T2, DVB-S/S2, DVB-C, ATSC, ISDB-T, ISDB-S,
+DTMB, etc. The complete list of supported standards can be found at
 :ref:`fe-delivery-system-t`.
 
-The third part covers the Remote Controller API.
+The :Ref:`third part <remote_controllers>` covers the Remote Controller API.
 
-The fourth part covers the Media Controller API.
+The :Ref:`fourth part <media_controller>` covers the Media Controller API.
 
 It should also be noted that a media device may also have audio
 components, like mixers, PCM capture, PCM playback, etc, which are

index 9716437ae14d..7f034852ae1f 100644
@@ -21,8 +21,8 @@ defines the :ref:`VIDIOC_G_PRIORITY <vidioc-g-priority>` and
 query the access priority associate with a file descriptor. Opening a
 device assigns a medium priority, compatible with earlier versions of
 V4L2 and drivers not supporting these ioctls. Applications requiring a
-different priority will usually call ``VIDIOC_S_PRIORITY`` after
-verifying the device with the
+different priority will usually call :ref:`VIDIOC_S_PRIORITY
+<vidioc-g-priority>` after verifying the device with the
 :ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl.
 
 Ioctls changing driver properties, such as

index 803bb37f4be8..f214bd835622 100644
@@ -17,8 +17,8 @@ outputs applications can enumerate them with the
 :ref:`VIDIOC_ENUMINPUT <vidioc-enuminput>` and
 :ref:`VIDIOC_ENUMOUTPUT <vidioc-enumoutput>` ioctl, respectively. The
 struct :ref:`v4l2_input <v4l2-input>` returned by the
-``VIDIOC_ENUMINPUT`` ioctl also contains signal status information
-applicable when the current video input is queried.
+:ref:`VIDIOC_ENUMINPUT <vidioc-enuminput>` ioctl also contains signal
+:status information applicable when the current video input is queried.
 
 The :ref:`VIDIOC_G_INPUT <vidioc-g-input>` and
 :ref:`VIDIOC_G_OUTPUT <vidioc-g-output>` ioctls return the index of

index 1ddbd67ec466..44605ec92a50 100644
@@ -10,7 +10,9 @@ Video for Linux Two API Specification
 **Revision 4.5**
 
 .. toctree::
+    :numbered:
     :maxdepth: 1
+    :caption: Table of Contents
 
     common
     pixfmt

index f214bd835622..fc220be52c2b 100644
@@ -28,8 +28,8 @@ applications call the :ref:`VIDIOC_S_INPUT <vidioc-g-input>` and
 implement all the input ioctls when the device has one or more inputs,
 all the output ioctls when the device has one or more outputs.
 
-
 .. code-block:: c
+    :caption: Example 1: Information about the current video input
 
     struct v4l2_input input;
     int index;

@@ -51,6 +51,7 @@ all the output ioctls when the device has one or more outputs.
 
 
 .. code-block:: c
+    :caption: Example 2: Switching to the first video input
 
     int index;
 

index 5e37adfbb49c..95622902e86e 100644
@@ -30,16 +30,16 @@ outputs applications can enumerate them with the
 :ref:`VIDIOC_ENUMAUDIO <vidioc-enumaudio>` and
 :ref:`VIDIOC_ENUMAUDOUT <vidioc-enumaudioout>` ioctl, respectively.
 The struct :ref:`v4l2_audio <v4l2-audio>` returned by the
-``VIDIOC_ENUMAUDIO`` ioctl also contains signal status information
-applicable when the current audio input is queried.
+:ref:`VIDIOC_ENUMAUDIO <vidioc-enumaudio>` ioctl also contains signal
+:status information applicable when the current audio input is queried.
 
 The :ref:`VIDIOC_G_AUDIO <vidioc-g-audio>` and
 :ref:`VIDIOC_G_AUDOUT <vidioc-g-audioout>` ioctls report the current
 audio input and output, respectively. Note that, unlike
 :ref:`VIDIOC_G_INPUT <vidioc-g-input>` and
 :ref:`VIDIOC_G_OUTPUT <vidioc-g-output>` these ioctls return a
-structure as ``VIDIOC_ENUMAUDIO`` and ``VIDIOC_ENUMAUDOUT`` do, not just
-an index.
+structure as :ref:`VIDIOC_ENUMAUDIO <vidioc-enumaudio>` and
+:ref:`VIDIOC_ENUMAUDOUT <vidioc-enumaudioout>` do, not just an index.
 
 To select an audio input and change its properties applications call the
 :ref:`VIDIOC_S_AUDIO <vidioc-g-audio>` ioctl. To select an audio

index 41a5757ffd72..d1a5b5970b71 100644
@@ -456,7 +456,7 @@ AUDIO_SET_MUTE
 DESCRIPTION
 
 This ioctl is for DVB devices only. To control a V4L2 decoder use the
-V4L2 :ref:`VIDIOC_DECODER_CMD <vidioc-decoder-cmd>` with the
+V4L2 :ref:`VIDIOC_DECODER_CMD <VIDIOC_DECODER_CMD>` with the
 ``V4L2_DEC_CMD_START_MUTE_AUDIO`` flag instead.
 
 This ioctl call asks the audio device to mute the stream that is

index 3add2b85450d..98c90dcdb587 100644
@@ -239,7 +239,7 @@ VIDEO_STOP
 DESCRIPTION
 
 This ioctl is for DVB devices only. To control a V4L2 decoder use the
-V4L2 :ref:`VIDIOC_DECODER_CMD <vidioc-decoder-cmd>` instead.
+V4L2 :ref:`VIDIOC_DECODER_CMD <VIDIOC_DECODER_CMD>` instead.
 
 This ioctl call asks the Video Device to stop playing the current
 stream. Depending on the input parameter, the screen can be blanked out

@@ -302,7 +302,7 @@ VIDEO_PLAY
 DESCRIPTION
 
 This ioctl is for DVB devices only. To control a V4L2 decoder use the
-V4L2 :ref:`VIDIOC_DECODER_CMD <vidioc-decoder-cmd>` instead.
+V4L2 :ref:`VIDIOC_DECODER_CMD <VIDIOC_DECODER_CMD>` instead.
 
 This ioctl call asks the Video Device to start playing a video stream
 from the selected source.

@@ -348,7 +348,7 @@ VIDEO_FREEZE
 DESCRIPTION
 
 This ioctl is for DVB devices only. To control a V4L2 decoder use the
-V4L2 :ref:`VIDIOC_DECODER_CMD <vidioc-decoder-cmd>` instead.
+V4L2 :ref:`VIDIOC_DECODER_CMD <VIDIOC_DECODER_CMD>` instead.
 
 This ioctl call suspends the live video stream being played. Decoding
 and playing are frozen. It is then possible to restart the decoding and

@@ -398,7 +398,7 @@ VIDEO_CONTINUE
 DESCRIPTION
 
 This ioctl is for DVB devices only. To control a V4L2 decoder use the
-V4L2 :ref:`VIDIOC_DECODER_CMD <vidioc-decoder-cmd>` instead.
+V4L2 :ref:`VIDIOC_DECODER_CMD <VIDIOC_DECODER_CMD>` instead.
 
 This ioctl call restarts decoding and playing processes of the video
 stream which was played before a call to VIDEO_FREEZE was made.

@@ -763,7 +763,7 @@ VIDEO_GET_EVENT
 DESCRIPTION
 
 This ioctl is for DVB devices only. To get events from a V4L2 decoder
-use the V4L2 :ref:`VIDIOC_DQEVENT <vidioc-dqevent>` ioctl instead.
+use the V4L2 :ref:`VIDIOC_DQEVENT <VIDIOC_DQEVENT>` ioctl instead.
 
 This ioctl call returns an event of type video_event if available. If
 an event is not available, the behavior depends on whether the device is

@@ -844,11 +844,11 @@ DESCRIPTION
 
 This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders
 this ioctl has been replaced by the
-:ref:`VIDIOC_DECODER_CMD <vidioc-decoder-cmd>` ioctl.
+:ref:`VIDIOC_DECODER_CMD <VIDIOC_DECODER_CMD>` ioctl.
 
 This ioctl commands the decoder. The ``video_command`` struct is a
 subset of the ``v4l2_decoder_cmd`` struct, so refer to the
-:ref:`VIDIOC_DECODER_CMD <vidioc-decoder-cmd>` documentation for
+:ref:`VIDIOC_DECODER_CMD <VIDIOC_DECODER_CMD>` documentation for
 more information.
 
 SYNOPSIS

@@ -900,11 +900,11 @@ DESCRIPTION
 
 This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders
 this ioctl has been replaced by the
-:ref:`VIDIOC_TRY_DECODER_CMD <vidioc-decoder-cmd>` ioctl.
+:ref:`VIDIOC_TRY_DECODER_CMD <VIDIOC_DECODER_CMD>` ioctl.
 
 This ioctl tries a decoder command. The ``video_command`` struct is a
 subset of the ``v4l2_decoder_cmd`` struct, so refer to the
-:ref:`VIDIOC_TRY_DECODER_CMD <vidioc-decoder-cmd>` documentation
+:ref:`VIDIOC_TRY_DECODER_CMD <VIDIOC_DECODER_CMD>` documentation
 for more information.
 
 SYNOPSIS

index 7f034852ae1f..bc50afca95fc 100644
@@ -16,17 +16,17 @@ applications and automatically regain control of the device at a later
 time.
 
 Since these features cannot be implemented entirely in user space V4L2
-defines the :ref:`VIDIOC_G_PRIORITY <vidioc-g-priority>` and
-:ref:`VIDIOC_S_PRIORITY <vidioc-g-priority>` ioctls to request and
+defines the :ref:`VIDIOC_G_PRIORITY <VIDIOC_G_PRIORITY>` and
+:ref:`VIDIOC_S_PRIORITY <VIDIOC_G_PRIORITY>` ioctls to request and
 query the access priority associate with a file descriptor. Opening a
 device assigns a medium priority, compatible with earlier versions of
 V4L2 and drivers not supporting these ioctls. Applications requiring a
 different priority will usually call :ref:`VIDIOC_S_PRIORITY
-<vidioc-g-priority>` after verifying the device with the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl.
+<VIDIOC_G_PRIORITY>` after verifying the device with the
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl.
 
 Ioctls changing driver properties, such as
-:ref:`VIDIOC_S_INPUT <vidioc-g-input>`, return an EBUSY error code
+:ref:`VIDIOC_S_INPUT <VIDIOC_G_INPUT>`, return an EBUSY error code
 after another application obtained higher priority.
 
 

index 95622902e86e..fa6bf5ad8d32 100644
@@ -27,31 +27,31 @@ number, starting at zero, of one audio input or output.
 
 To learn about the number and attributes of the available inputs and
 outputs applications can enumerate them with the
-:ref:`VIDIOC_ENUMAUDIO <vidioc-enumaudio>` and
-:ref:`VIDIOC_ENUMAUDOUT <vidioc-enumaudioout>` ioctl, respectively.
+:ref:`VIDIOC_ENUMAUDIO <VIDIOC_ENUMAUDIO>` and
+:ref:`VIDIOC_ENUMAUDOUT <VIDIOC_ENUMAUDIOout>` ioctl, respectively.
 The struct :ref:`v4l2_audio <v4l2-audio>` returned by the
-:ref:`VIDIOC_ENUMAUDIO <vidioc-enumaudio>` ioctl also contains signal
+:ref:`VIDIOC_ENUMAUDIO <VIDIOC_ENUMAUDIO>` ioctl also contains signal
 :status information applicable when the current audio input is queried.
 
-The :ref:`VIDIOC_G_AUDIO <vidioc-g-audio>` and
-:ref:`VIDIOC_G_AUDOUT <vidioc-g-audioout>` ioctls report the current
+The :ref:`VIDIOC_G_AUDIO <VIDIOC_G_AUDIO>` and
+:ref:`VIDIOC_G_AUDOUT <VIDIOC_G_AUDIOout>` ioctls report the current
 audio input and output, respectively. Note that, unlike
-:ref:`VIDIOC_G_INPUT <vidioc-g-input>` and
-:ref:`VIDIOC_G_OUTPUT <vidioc-g-output>` these ioctls return a
-structure as :ref:`VIDIOC_ENUMAUDIO <vidioc-enumaudio>` and
-:ref:`VIDIOC_ENUMAUDOUT <vidioc-enumaudioout>` do, not just an index.
+:ref:`VIDIOC_G_INPUT <VIDIOC_G_INPUT>` and
+:ref:`VIDIOC_G_OUTPUT <VIDIOC_G_OUTPUT>` these ioctls return a
+structure as :ref:`VIDIOC_ENUMAUDIO <VIDIOC_ENUMAUDIO>` and
+:ref:`VIDIOC_ENUMAUDOUT <VIDIOC_ENUMAUDIOout>` do, not just an index.
 
 To select an audio input and change its properties applications call the
-:ref:`VIDIOC_S_AUDIO <vidioc-g-audio>` ioctl. To select an audio
+:ref:`VIDIOC_S_AUDIO <VIDIOC_G_AUDIO>` ioctl. To select an audio
 output (which presently has no changeable properties) applications call
-the :ref:`VIDIOC_S_AUDOUT <vidioc-g-audioout>` ioctl.
+the :ref:`VIDIOC_S_AUDOUT <VIDIOC_G_AUDIOout>` ioctl.
 
 Drivers must implement all audio input ioctls when the device has
 multiple selectable audio inputs, all audio output ioctls when the
 device has multiple selectable audio outputs. When the device has any
 audio inputs or outputs the driver must set the ``V4L2_CAP_AUDIO`` flag
 in the struct :ref:`v4l2_capability <v4l2-capability>` returned by
-the :ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl.
+the :ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl.
 
 
 .. code-block:: c

98 lines not on this page · raw message

index 16eb34472892..3e5c650707ae 100644
@@ -47,7 +47,7 @@ changed or generally never without application request.
 
 V4L2 specifies an event mechanism to notify applications when controls
 change value (see
-:ref:`VIDIOC_SUBSCRIBE_EVENT <vidioc-subscribe-event>`, event
+:ref:`VIDIOC_SUBSCRIBE_EVENT <VIDIOC_SUBSCRIBE_EVENT>`, event
 ``V4L2_EVENT_CTRL``), panel applications might want to make use of that
 in order to always reflect the correct control value.
 

@@ -311,7 +311,7 @@ Control IDs
     180. Rotating the image to 90 and 270 will reverse the height and
     width of the display window. It is necessary to set the new height
     and width of the picture using the
-    :ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl according to the
+    :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl according to the
     rotation angle selected.
 
 ``V4L2_CID_BG_COLOR`` ``(integer)``

@@ -362,10 +362,10 @@ Control IDs
     and version, see :ref:`querycap`.
 
 Applications can enumerate the available controls with the
-:ref:`VIDIOC_QUERYCTRL <vidioc-queryctrl>` and
-:ref:`VIDIOC_QUERYMENU <vidioc-queryctrl>` ioctls, get and set a
-control value with the :ref:`VIDIOC_G_CTRL <vidioc-g-ctrl>` and
-:ref:`VIDIOC_S_CTRL <vidioc-g-ctrl>` ioctls. Drivers must implement
+:ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` and
+:ref:`VIDIOC_QUERYMENU <VIDIOC_QUERYCTRL>` ioctls, get and set a
+control value with the :ref:`VIDIOC_G_CTRL <VIDIOC_G_CTRL>` and
+:ref:`VIDIOC_S_CTRL <VIDIOC_G_CTRL>` ioctls. Drivers must implement
 ``VIDIOC_QUERYCTRL``, ``VIDIOC_G_CTRL`` and ``VIDIOC_S_CTRL`` when the
 device has one or more controls, ``VIDIOC_QUERYMENU`` when it has one or
 more menu type controls.

@@ -522,7 +522,7 @@ more menu type controls.
    the real IDs.
 
    Many applications today still use the ``V4L2_CID_PRIVATE_BASE`` IDs
-   instead of using :ref:`VIDIOC_QUERYCTRL <vidioc-queryctrl>` with
+   instead of using :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` with
    the ``V4L2_CTRL_FLAG_NEXT_CTRL`` flag to enumerate all IDs, so
    support for ``V4L2_CID_PRIVATE_BASE`` is still around.
 

index b9014d03865f..94f2d0e77ed8 100644
@@ -14,17 +14,17 @@ offset into a video signal.
 
 Applications can use the following API to select an area in the video
 signal, query the default area and the hardware limits. *Despite their
-name, the :ref:`VIDIOC_CROPCAP <vidioc-cropcap>`,
-:ref:`VIDIOC_G_CROP <vidioc-g-crop>` and
-:ref:`VIDIOC_S_CROP <vidioc-g-crop>` ioctls apply to input as well
+name, the :ref:`VIDIOC_CROPCAP <VIDIOC_CROPCAP>`,
+:ref:`VIDIOC_G_CROP <VIDIOC_G_CROP>` and
+:ref:`VIDIOC_S_CROP <VIDIOC_G_CROP>` ioctls apply to input as well
 as output devices.*
 
 Scaling requires a source and a target. On a video capture or overlay
 device the source is the video signal, and the cropping ioctls determine
 the area actually sampled. The target are images read by the application
 or overlaid onto the graphics screen. Their size (and position for an
-overlay) is negotiated with the :ref:`VIDIOC_G_FMT <vidioc-g-fmt>`
-and :ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctls.
+overlay) is negotiated with the :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`
+and :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctls.
 
 On a video output device the source are the images passed in by the
 application, and their size is again negotiated with the

@@ -108,7 +108,7 @@ they may prefer a particular image size or a certain area in the video
 signal. If the driver has to adjust both to satisfy hardware
 limitations, the last requested rectangle shall take priority, and the
 driver should preferably adjust the opposite one. The
-:ref:`VIDIOC_TRY_FMT <vidioc-g-fmt>` ioctl however shall not change
+:ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl however shall not change
 the driver state and therefore only adjust the requested rectangle.
 
 Suppose scaling on a video capture device is restricted to a factor 1:1

index 21207ab2e604..fd6357c995aa 100644
@@ -25,7 +25,7 @@ Devices supporting the video capture interface set the
 ``V4L2_CAP_VIDEO_CAPTURE`` or ``V4L2_CAP_VIDEO_CAPTURE_MPLANE`` flag in
 the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl. As secondary device
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. As secondary device
 functions they may also support the :ref:`video overlay <overlay>`
 (``V4L2_CAP_VIDEO_OVERLAY``) and the :ref:`raw VBI capture <raw-vbi>`
 (``V4L2_CAP_VBI_CAPTURE``) interface. At least one of the read/write or

@@ -65,7 +65,7 @@ To query the current image format applications set the ``type`` field of
 a struct :ref:`v4l2_format <v4l2-format>` to
 ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` or
 ``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE`` and call the
-:ref:`VIDIOC_G_FMT <vidioc-g-fmt>` ioctl with a pointer to this
+:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` ioctl with a pointer to this
 structure. Drivers fill the struct
 :ref:`v4l2_pix_format <v4l2-pix-format>` ``pix`` or the struct
 :ref:`v4l2_pix_format_mplane <v4l2-pix-format-mplane>` ``pix_mp``

@@ -75,12 +75,12 @@ To request different parameters applications set the ``type`` field of a
 struct :ref:`v4l2_format <v4l2-format>` as above and initialize all
 fields of the struct :ref:`v4l2_pix_format <v4l2-pix-format>`
 ``vbi`` member of the ``fmt`` union, or better just modify the results
-of ``VIDIOC_G_FMT``, and call the :ref:`VIDIOC_S_FMT <vidioc-g-fmt>`
+of ``VIDIOC_G_FMT``, and call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
 ioctl with a pointer to this structure. Drivers may adjust the
 parameters and finally return the actual parameters as ``VIDIOC_G_FMT``
 does.
 
-Like ``VIDIOC_S_FMT`` the :ref:`VIDIOC_TRY_FMT <vidioc-g-fmt>` ioctl
+Like ``VIDIOC_S_FMT`` the :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl
 can be used to learn about hardware limitations without disabling I/O or
 possibly time consuming hardware preparations.
 

index f0b54c2b95c3..1540755b1735 100644
@@ -15,7 +15,7 @@ A memory-to-memory video node acts just like a normal video node, but it
 supports both output (sending frames from memory to the codec hardware)
 and capture (receiving the processed frames from the codec hardware into
 memory) stream I/O. An application will have to setup the stream I/O for
-both sides and finally call :ref:`VIDIOC_STREAMON <vidioc-streamon>`
+both sides and finally call :ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>`
 for both capture and output to start the codec.
 
 Video compression codecs use the MPEG controls to setup their codec

index afe24a72d8ea..5d21c6873b1a 100644
@@ -14,9 +14,9 @@ events.
 
 To receive events, the events the user is interested in first must be
 subscribed using the
-:ref:`VIDIOC_SUBSCRIBE_EVENT <vidioc-subscribe-event>` ioctl. Once
+:ref:`VIDIOC_SUBSCRIBE_EVENT <VIDIOC_SUBSCRIBE_EVENT>` ioctl. Once
 an event is subscribed, the events of subscribed types are dequeueable
-using the :ref:`VIDIOC_DQEVENT <vidioc-dqevent>` ioctl. Events may be
+using the :ref:`VIDIOC_DQEVENT <VIDIOC_DQEVENT>` ioctl. Events may be
 unsubscribed using VIDIOC_UNSUBSCRIBE_EVENT ioctl. The special event
 type V4L2_EVENT_ALL may be used to unsubscribe all the events the
 driver supports.

index 077e2cdc598d..93fb8f309091 100644
@@ -17,7 +17,7 @@ The OSD function is accessible through the same character special file
 as the :ref:`Video Output <capture>` function. Note the default
 function of such a ``/dev/video`` device is video capturing or output.
 The OSD function is only available after calling the
-:ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl.
+:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl.
 
 
 Querying Capabilities

@@ -26,7 +26,7 @@ Querying Capabilities
 Devices supporting the *Video Output Overlay* interface set the
 ``V4L2_CAP_VIDEO_OUTPUT_OVERLAY`` flag in the ``capabilities`` field of
 struct :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl.
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl.
 
 
 Framebuffer

@@ -36,7 +36,7 @@ Contrary to the *Video Overlay* interface the framebuffer is normally
 implemented on the TV card and not the graphics card. On Linux it is
 accessible as a framebuffer device (``/dev/fbN``). Given a V4L2 device,
 applications can find the corresponding framebuffer device by calling
-the :ref:`VIDIOC_G_FBUF <vidioc-g-fbuf>` ioctl. It returns, amongst
+the :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` ioctl. It returns, amongst
 other information, the physical address of the framebuffer in the
 ``base`` field of struct :ref:`v4l2_framebuffer <v4l2-framebuffer>`.
 The framebuffer device ioctl ``FBIOGET_FSCREENINFO`` returns the same

@@ -115,17 +115,17 @@ clipping/blending method to be used for the overlay. To get the current
 parameters applications set the ``type`` field of a struct
 :ref:`v4l2_format <v4l2-format>` to
 ``V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY`` and call the
-:ref:`VIDIOC_G_FMT <vidioc-g-fmt>` ioctl. The driver fills the
+:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` ioctl. The driver fills the
 :c:type:`struct v4l2_window` substructure named ``win``. It is not
 possible to retrieve a previously programmed clipping list or bitmap.
 
 To program the source rectangle applications set the ``type`` field of a
 struct :ref:`v4l2_format <v4l2-format>` to
 ``V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY``, initialize the ``win``
-substructure and call the :ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl.
+substructure and call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl.
 The driver adjusts the parameters against hardware limits and returns
 the actual parameters as ``VIDIOC_G_FMT`` does. Like ``VIDIOC_S_FMT``,
-the :ref:`VIDIOC_TRY_FMT <vidioc-g-fmt>` ioctl can be used to learn
+the :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl can be used to learn
 about driver capabilities without actually changing driver state. Unlike
 ``VIDIOC_S_FMT`` this also works after the overlay has been enabled.
 

index 0d46d59304b9..3efbbcc3c093 100644
@@ -24,7 +24,7 @@ Devices supporting the video output interface set the
 ``V4L2_CAP_VIDEO_OUTPUT`` or ``V4L2_CAP_VIDEO_OUTPUT_MPLANE`` flag in
 the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl. As secondary device
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. As secondary device
 functions they may also support the :ref:`raw VBI output <raw-vbi>`
 (``V4L2_CAP_VBI_OUTPUT``) interface. At least one of the read/write or
 streaming I/O methods must be supported. Modulators and audio outputs

@@ -62,7 +62,7 @@ defaults. An example is given in :ref:`crop`.
 To query the current image format applications set the ``type`` field of
 a struct :ref:`v4l2_format <v4l2-format>` to
 ``V4L2_BUF_TYPE_VIDEO_OUTPUT`` or ``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE``
-and call the :ref:`VIDIOC_G_FMT <vidioc-g-fmt>` ioctl with a pointer
+and call the :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` ioctl with a pointer
 to this structure. Drivers fill the struct
 :ref:`v4l2_pix_format <v4l2-pix-format>` ``pix`` or the struct
 :ref:`v4l2_pix_format_mplane <v4l2-pix-format-mplane>` ``pix_mp``

@@ -72,12 +72,12 @@ To request different parameters applications set the ``type`` field of a
 struct :ref:`v4l2_format <v4l2-format>` as above and initialize all
 fields of the struct :ref:`v4l2_pix_format <v4l2-pix-format>`
 ``vbi`` member of the ``fmt`` union, or better just modify the results
-of ``VIDIOC_G_FMT``, and call the :ref:`VIDIOC_S_FMT <vidioc-g-fmt>`
+of ``VIDIOC_G_FMT``, and call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
 ioctl with a pointer to this structure. Drivers may adjust the
 parameters and finally return the actual parameters as ``VIDIOC_G_FMT``
 does.
 
-Like ``VIDIOC_S_FMT`` the :ref:`VIDIOC_TRY_FMT <vidioc-g-fmt>` ioctl
+Like ``VIDIOC_S_FMT`` the :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl
 can be used to learn about hardware limitations without disabling I/O or
 possibly time consuming hardware preparations.
 

index 50aed591284b..8a81e19a5d7c 100644
@@ -20,7 +20,7 @@ Video overlay devices are accessed through the same character special
 files as :ref:`video capture <capture>` devices. Note the default
 function of a ``/dev/video`` device is video capturing. The overlay
 function is only available after calling the
-:ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl.
+:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl.
 
 The driver may support simultaneous overlay and capturing using the
 read/write and streaming I/O methods. If so, operation at the nominal

@@ -41,7 +41,7 @@ Querying Capabilities
 Devices supporting the video overlay interface set the
 ``V4L2_CAP_VIDEO_OVERLAY`` flag in the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl. The overlay I/O
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. The overlay I/O
 method specified below must be supported. Tuners and audio inputs are
 optional.
 

@@ -63,8 +63,8 @@ Setup
 Before overlay can commence applications must program the driver with
 frame buffer parameters, namely the address and size of the frame buffer
 and the image format, for example RGB 5:6:5. The
-:ref:`VIDIOC_G_FBUF <vidioc-g-fbuf>` and
-:ref:`VIDIOC_S_FBUF <vidioc-g-fbuf>` ioctls are available to get and
+:ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` and
+:ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>` ioctls are available to get and
 set these parameters, respectively. The ``VIDIOC_S_FBUF`` ioctl is
 privileged because it allows to set up DMA into physical memory,
 bypassing the memory protection mechanisms of the kernel. Only the

@@ -101,8 +101,8 @@ A driver may support any (or none) of five clipping/blending methods:
 When simultaneous capturing and overlay is supported and the hardware
 prohibits different image and frame buffer formats, the format requested
 first takes precedence. The attempt to capture
-(:ref:`VIDIOC_S_FMT <vidioc-g-fmt>`) or overlay
-(:ref:`VIDIOC_S_FBUF <vidioc-g-fbuf>`) may fail with an EBUSY error
+(:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`) or overlay
+(:ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>`) may fail with an EBUSY error
 code or return accordingly modified parameters..
 
 

@@ -121,17 +121,17 @@ its position over the graphics surface and the clipping to be applied.
 To get the current parameters applications set the ``type`` field of a
 struct :ref:`v4l2_format <v4l2-format>` to
 ``V4L2_BUF_TYPE_VIDEO_OVERLAY`` and call the
-:ref:`VIDIOC_G_FMT <vidioc-g-fmt>` ioctl. The driver fills the
+:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` ioctl. The driver fills the
 :c:type:`struct v4l2_window` substructure named ``win``. It is not
 possible to retrieve a previously programmed clipping list or bitmap.
 
 To program the overlay window applications set the ``type`` field of a
 struct :ref:`v4l2_format <v4l2-format>` to
 ``V4L2_BUF_TYPE_VIDEO_OVERLAY``, initialize the ``win`` substructure and
-call the :ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl. The driver
+call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl. The driver
 adjusts the parameters against hardware limits and returns the actual
 parameters as ``VIDIOC_G_FMT`` does. Like ``VIDIOC_S_FMT``, the
-:ref:`VIDIOC_TRY_FMT <vidioc-g-fmt>` ioctl can be used to learn
+:ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl can be used to learn
 about driver capabilities without actually changing driver state. Unlike
 ``VIDIOC_S_FMT`` this also works after the overlay has been enabled.
 

@@ -142,7 +142,7 @@ of the cropping rectangle. For more information see :ref:`crop`.
 When simultaneous capturing and overlay is supported and the hardware
 prohibits different image and window sizes, the size requested first
 takes precedence. The attempt to capture or overlay as well
-(:ref:`VIDIOC_S_FMT <vidioc-g-fmt>`) may fail with an EBUSY error
+(:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`) may fail with an EBUSY error
 code or return accordingly modified parameters.
 
 

@@ -154,7 +154,7 @@ struct v4l2_window
 ``struct v4l2_rect w``
     Size and position of the window relative to the top, left corner of
     the frame buffer defined with
-    :ref:`VIDIOC_S_FBUF <vidioc-g-fbuf>`. The window can extend the
+    :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>`. The window can extend the
     frame buffer width and height, the ``x`` and ``y`` coordinates can
     be negative, and it can lie completely outside the frame buffer. The
     driver clips the window accordingly, or if that is not possible,

@@ -169,7 +169,7 @@ struct v4l2_window
 
 ``__u32 chromakey``
     When chroma-keying has been negotiated with
-    :ref:`VIDIOC_S_FBUF <vidioc-g-fbuf>` applications set this field
+    :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>` applications set this field
     to the desired pixel value for the chroma key. The format is the
     same as the pixel format of the framebuffer (struct
     :ref:`v4l2_framebuffer <v4l2-framebuffer>` ``fmt.pixelformat``

@@ -179,7 +179,7 @@ struct v4l2_window
 
 ``struct v4l2_clip * clips``
     When chroma-keying has *not* been negotiated and
-    :ref:`VIDIOC_G_FBUF <vidioc-g-fbuf>` indicated this capability,
+    :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` indicated this capability,
     applications can set this field to point to an array of clipping
     rectangles.
 

@@ -192,7 +192,7 @@ applications should merge adjacent rectangles. Whether this must create
 x-y or y-x bands, or the order of rectangles, is not defined. When clip
 lists are not supported the driver ignores this field. Its contents
 after calling
-!ri!:ref:`VIDIOC_S_FMT <vidioc-g-fmt>`
+!ri!:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
 are undefined.
 
 ``__u32 clipcount``

@@ -204,7 +204,7 @@ are undefined.
 
 ``void * bitmap``
     When chroma-keying has *not* been negotiated and
-    :ref:`VIDIOC_G_FBUF <vidioc-g-fbuf>` indicated this capability,
+    :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` indicated this capability,
     applications can set this field to point to a clipping bit mask.
 
 It must be of the same size as the window, ``w.width`` and ``w.height``.

@@ -220,7 +220,7 @@ bits like:
 where ``0`` ≤ x < ``w.width`` and ``0`` ≤ y <``w.height``. [2]_
 
 When a clipping bit mask is not supported the driver ignores this field,
-its contents after calling :ref:`VIDIOC_S_FMT <vidioc-g-fmt>` are
+its contents after calling :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` are
 undefined. When a bit mask is supported but no clipping is desired this
 field must be set to ``NULL``.
 

@@ -234,12 +234,12 @@ exceeded are undefined. [3]_
     The global alpha value used to blend the framebuffer with video
     images, if global alpha blending has been negotiated
     (``V4L2_FBUF_FLAG_GLOBAL_ALPHA``, see
-    :ref:`VIDIOC_S_FBUF <vidioc-g-fbuf>`,
+    :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>`,
     :ref:`framebuffer-flags`).
 
 Note this field was added in Linux 2.6.23, extending the structure.
 However the
-!ri!:ref:`VIDIOC_G/S/TRY_FMT <vidioc-g-fmt>`
+!ri!:ref:`VIDIOC_G/S/TRY_FMT <VIDIOC_G_FMT>`
 ioctls, which take a pointer to a
 !ri!:ref:`v4l2_format <v4l2-format>`
 parent structure with padding bytes at the end, are not affected.

@@ -289,7 +289,7 @@ Enabling Overlay
 ================
 
 To start or stop the frame buffer overlay applications call the
-:ref:`VIDIOC_OVERLAY <vidioc-overlay>` ioctl.
+:ref:`VIDIOC_OVERLAY <VIDIOC_OVERLAY>` ioctl.
 
 .. [1]
    A common application of two file descriptors is the XFree86

index 672540105a66..955173aaf48e 100644
@@ -21,7 +21,7 @@ Devices supporting the radio interface set the ``V4L2_CAP_RADIO`` and
 ``V4L2_CAP_TUNER`` or ``V4L2_CAP_MODULATOR`` flag in the
 ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl. Other combinations of
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. Other combinations of
 capability flags are reserved for future extensions.
 
 

@@ -47,8 +47,8 @@ discussed in :ref:`tuner`) with index number zero to select the radio
 frequency and to determine if a monaural or FM stereo program is
 received/emitted. Drivers switch automatically between AM and FM
 depending on the selected frequency. The
-:ref:`VIDIOC_G_TUNER <vidioc-g-tuner>` or
-:ref:`VIDIOC_G_MODULATOR <vidioc-g-modulator>` ioctl reports the
+:ref:`VIDIOC_G_TUNER <VIDIOC_G_TUNER>` or
+:ref:`VIDIOC_G_MODULATOR <VIDIOC_G_MODULATOR>` ioctl reports the
 supported frequency range.
 
 

index 9ab5c4a4cad7..883ac4fbaeb6 100644
@@ -28,7 +28,7 @@ applies to both input and output devices.
 To address the problems of finding related video and VBI devices VBI
 capturing and output is also available as device function under
 ``/dev/video``. To capture or output raw VBI data with these devices
-applications must call the :ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl.
+applications must call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl.
 Accessed as ``/dev/vbi``, raw VBI capturing or output is the default
 device function.
 

@@ -40,7 +40,7 @@ Devices supporting the raw VBI capturing or output API set the
 ``V4L2_CAP_VBI_CAPTURE`` or ``V4L2_CAP_VBI_OUTPUT`` flags, respectively,
 in the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl. At least one of the
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. At least one of the
 read/write, streaming or asynchronous I/O methods must be supported. VBI
 devices may or may not have a tuner or modulator.
 

@@ -71,7 +71,7 @@ parameters and then checking if the actual parameters are suitable.
 To query the current raw VBI capture parameters applications set the
 ``type`` field of a struct :ref:`v4l2_format <v4l2-format>` to
 ``V4L2_BUF_TYPE_VBI_CAPTURE`` or ``V4L2_BUF_TYPE_VBI_OUTPUT``, and call
-the :ref:`VIDIOC_G_FMT <vidioc-g-fmt>` ioctl with a pointer to this
+the :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` ioctl with a pointer to this
 structure. Drivers fill the struct
 :ref:`v4l2_vbi_format <v4l2-vbi-format>` ``vbi`` member of the
 ``fmt`` union.

@@ -80,7 +80,7 @@ To request different parameters applications set the ``type`` field of a
 struct :ref:`v4l2_format <v4l2-format>` as above and initialize all
 fields of the struct :ref:`v4l2_vbi_format <v4l2-vbi-format>`
 ``vbi`` member of the ``fmt`` union, or better just modify the results
-of ``VIDIOC_G_FMT``, and call the :ref:`VIDIOC_S_FMT <vidioc-g-fmt>`
+of ``VIDIOC_G_FMT``, and call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
 ioctl with a pointer to this structure. Drivers return an EINVAL error
 code only when the given parameters are ambiguous, otherwise they modify
 the parameters according to the hardware capabilities and return the

@@ -91,7 +91,7 @@ happen for instance when the video and VBI areas to capture would
 overlap, or when the driver supports multiple opens and another process
 already requested VBI capturing or output. Anyway, applications must
 expect other resource allocation points which may return EBUSY, at the
-:ref:`VIDIOC_STREAMON <vidioc-streamon>` ioctl and the first read(),
+:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` ioctl and the first read(),
 write() and select() call.
 
 VBI devices must implement both the ``VIDIOC_G_FMT`` and

@@ -339,7 +339,7 @@ A VBI device may support :ref:`read/write <rw>` and/or streaming
 The latter bears the possibility of synchronizing video and VBI data by
 using buffer timestamps.
 
-Remember the :ref:`VIDIOC_STREAMON <vidioc-streamon>` ioctl and the
+Remember the :ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` ioctl and the
 first read(), write() and select() call can be resource allocation
 points returning an EBUSY error code if the required hardware resources
 are temporarily unavailable, for example the device is already in use by

index 498752aa5eaf..af20f8fa1cdf 100644
@@ -33,7 +33,7 @@ Querying Capabilities
 Devices supporting the RDS capturing API set the
 ``V4L2_CAP_RDS_CAPTURE`` flag in the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl. Any tuner that
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. Any tuner that
 supports RDS will set the ``V4L2_TUNER_CAP_RDS`` flag in the
 ``capability`` field of struct :ref:`v4l2_tuner <v4l2-tuner>`. If the
 driver only passes RDS blocks without interpreting the data the

@@ -52,7 +52,7 @@ Whether an RDS signal is present can be detected by looking at the
 Devices supporting the RDS output API set the ``V4L2_CAP_RDS_OUTPUT``
 flag in the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl. Any modulator that
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. Any modulator that
 supports RDS will set the ``V4L2_TUNER_CAP_RDS`` flag in the
 ``capability`` field of struct
 :ref:`v4l2_modulator <v4l2-modulator>`. In order to enable the RDS

index 8e9e34b8d53a..5e4f7030f644 100644
@@ -22,7 +22,7 @@ Devices supporting the SDR receiver interface set the
 ``V4L2_CAP_SDR_CAPTURE`` and ``V4L2_CAP_TUNER`` flag in the
 ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl. That flag means the
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. That flag means the
 device has an Analog to Digital Converter (ADC), which is a mandatory
 element for the SDR receiver.
 

@@ -30,7 +30,7 @@ Devices supporting the SDR transmitter interface set the
 ``V4L2_CAP_SDR_OUTPUT`` and ``V4L2_CAP_MODULATOR`` flag in the
 ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl. That flag means the
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. That flag means the
 device has an Digital to Analog Converter (DAC), which is a mandatory
 element for the SDR transmitter.
 

@@ -52,7 +52,7 @@ radio frequency. The tuner index of the RF tuner (if any) must always
 follow the SDR tuner index. Normally the SDR tuner is #0 and the RF
 tuner is #1.
 
-The :ref:`VIDIOC_S_HW_FREQ_SEEK <vidioc-s-hw-freq-seek>` ioctl is
+The :ref:`VIDIOC_S_HW_FREQ_SEEK <VIDIOC_S_HW_FREQ_SEEK>` ioctl is
 not supported.
 
 

@@ -63,7 +63,7 @@ The SDR device uses the :ref:`format <format>` ioctls to select the
 capture and output format. Both the sampling resolution and the data
 streaming format are bound to that selectable format. In addition to the
 basic :ref:`format <format>` ioctls, the
-:ref:`VIDIOC_ENUM_FMT <vidioc-enum-fmt>` ioctl must be supported as
+:ref:`VIDIOC_ENUM_FMT <VIDIOC_ENUM_FMT>` ioctl must be supported as
 well.
 
 To use the :ref:`format <format>` ioctls applications set the ``type``

index 90d879964f52..0faf178168e4 100644
@@ -21,7 +21,7 @@ Sliced VBI capture and output devices are accessed through the same
 character special files as raw VBI devices. When a driver supports both
 interfaces, the default function of a ``/dev/vbi`` device is *raw* VBI
 capturing or output, and the sliced VBI function is only available after
-calling the :ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl as defined
+calling the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl as defined
 below. Likewise a ``/dev/video`` device may support the sliced VBI API,
 however the default function here is video capturing or output.
 Different file descriptors must be used to pass raw and sliced VBI data

@@ -35,7 +35,7 @@ Devices supporting the sliced VBI capturing or output API set the
 ``V4L2_CAP_SLICED_VBI_CAPTURE`` or ``V4L2_CAP_SLICED_VBI_OUTPUT`` flag
 respectively, in the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl. At least one of the
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. At least one of the
 read/write, streaming or asynchronous :ref:`I/O methods <io>` must be
 supported. Sliced VBI devices may have a tuner or modulator.
 

@@ -57,10 +57,10 @@ Sliced VBI Format Negotiation
 
 To find out which data services are supported by the hardware
 applications can call the
-:ref:`VIDIOC_G_SLICED_VBI_CAP <vidioc-g-sliced-vbi-cap>` ioctl.
+:ref:`VIDIOC_G_SLICED_VBI_CAP <VIDIOC_G_SLICED_VBI_CAP>` ioctl.
 All drivers implementing the sliced VBI interface must support this
 ioctl. The results may differ from those of the
-:ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl when the number of VBI
+:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl when the number of VBI
 lines the hardware can capture or output per frame, or the number of
 services it can identify on a given line are limited. For example on PAL
 line 16 the hardware may be able to look for a VPS or Teletext signal,

@@ -70,13 +70,13 @@ To determine the currently selected services applications set the
 ``type`` field of struct :ref:`v4l2_format <v4l2-format>` to
 ``V4L2_BUF_TYPE_SLICED_VBI_CAPTURE`` or
 ``V4L2_BUF_TYPE_SLICED_VBI_OUTPUT``, and the
-:ref:`VIDIOC_G_FMT <vidioc-g-fmt>` ioctl fills the ``fmt.sliced``
+:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` ioctl fills the ``fmt.sliced``
 member, a struct
 :ref:`v4l2_sliced_vbi_format <v4l2-sliced-vbi-format>`.
 
 Applications can request different parameters by initializing or
 modifying the ``fmt.sliced`` member and calling the
-:ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl with a pointer to the
+:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl with a pointer to the
 :c:type:`struct v4l2_format` structure.
 
 The sliced VBI API is more complicated than the raw VBI API because the

@@ -90,12 +90,12 @@ array according to hardware capabilities. Only if more precise control
 is needed should the programmer set the ``service_lines`` array
 explicitly.
 
-The :ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl modifies the parameters
+The :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl modifies the parameters
 according to hardware capabilities. When the driver allocates resources
 at this point, it may return an EBUSY error code if the required
 resources are temporarily unavailable. Other resource allocation points
 which may return EBUSY can be the
-:ref:`VIDIOC_STREAMON <vidioc-streamon>` ioctl and the first
+:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` ioctl and the first
 :ref:`read() <func-read>`, :ref:`write() <func-write>` and
 :ref:`select() <func-select>` call.
 

@@ -117,8 +117,8 @@ which may return EBUSY can be the
        -  :cspan:`2`
 
           If ``service_set`` is non-zero when passed with
-          :ref:`VIDIOC_S_FMT <vidioc-g-fmt>` or
-          :ref:`VIDIOC_TRY_FMT <vidioc-g-fmt>`, the ``service_lines``
+          :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` or
+          :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>`, the ``service_lines``
           array will be filled by the driver according to the services
           specified in this field. For example, if ``service_set`` is
           initialized with ``V4L2_SLICED_TELETEXT_B | V4L2_SLICED_WSS_625``,

@@ -224,8 +224,8 @@ which may return EBUSY can be the
        -  :cspan:`2` Maximum number of bytes passed by one
           :ref:`read() <func-read>` or :ref:`write() <func-write>` call,
           and the buffer size in bytes for the
-          :ref:`VIDIOC_QBUF <vidioc-qbuf>` and
-          :ref:`VIDIOC_DQBUF <vidioc-qbuf>` ioctl. Drivers set this field
+          :ref:`VIDIOC_QBUF <VIDIOC_QBUF>` and
+          :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. Drivers set this field
           to the size of struct
           :ref:`v4l2_sliced_vbi_data <v4l2-sliced-vbi-data>` times the
           number of non-zero elements in the returned ``service_lines``

@@ -340,11 +340,11 @@ Drivers may return an EINVAL error code when applications attempt to
 read or write data without prior format negotiation, after switching the
 video standard (which may invalidate the negotiated VBI parameters) and
 after switching the video input (which may change the video standard as
-a side effect). The :ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl may
+a side effect). The :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl may
 return an EBUSY error code when applications attempt to change the
 format while i/o is in progress (between a
-:ref:`VIDIOC_STREAMON <vidioc-streamon>` and
-:ref:`VIDIOC_STREAMOFF <vidioc-streamon>` call, and after the first
+:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` and
+:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` call, and after the first
 :ref:`read() <func-read>` or :ref:`write() <func-write>` call).
 
 

@@ -428,12 +428,12 @@ of one video frame. The ``id`` of unused
 
 Packets are always passed in ascending line number order, without
 duplicate line numbers. The :ref:`write() <func-write>` function and
-the :ref:`VIDIOC_QBUF <vidioc-qbuf>` ioctl must return an EINVAL
+the :ref:`VIDIOC_QBUF <VIDIOC_QBUF>` ioctl must return an EINVAL
 error code when applications violate this rule. They must also return an
 EINVAL error code when applications pass an incorrect field or line
 number, or a combination of ``field``, ``line`` and ``id`` which has not
-been negotiated with the :ref:`VIDIOC_G_FMT <vidioc-g-fmt>` or
-:ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl. When the line numbers are
+been negotiated with the :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` or
+:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl. When the line numbers are
 unknown the driver must pass the packets in transmitted order. The
 driver can insert empty packets with ``id`` set to zero anywhere in the
 packet array.

index 66274eafd437..1fe594c0026f 100644
@@ -86,7 +86,7 @@ Pad-level Formats
 
 Image formats are typically negotiated on video capture and output
 devices using the format and
-:ref:`selection <vidioc-subdev-g-selection>` ioctls. The driver is
+:ref:`selection <VIDIOC_SUBDEV_G_SELECTION>` ioctls. The driver is
 responsible for configuring every block in the video pipeline according
 to the requested format at the pipeline input and/or output.
 

@@ -118,18 +118,18 @@ every point in the pipeline explicitly.
 Drivers that implement the :ref:`media API <media-controller-intro>`
 can expose pad-level image format configuration to applications. When
 they do, applications can use the
-:ref:`VIDIOC_SUBDEV_G_FMT <vidioc-subdev-g-fmt>` and
-:ref:`VIDIOC_SUBDEV_S_FMT <vidioc-subdev-g-fmt>` ioctls. to
+:ref:`VIDIOC_SUBDEV_G_FMT <VIDIOC_SUBDEV_G_FMT>` and
+:ref:`VIDIOC_SUBDEV_S_FMT <VIDIOC_SUBDEV_G_FMT>` ioctls. to
 negotiate formats on a per-pad basis.
 
 Applications are responsible for configuring coherent parameters on the
 whole pipeline and making sure that connected pads have compatible
 formats. The pipeline is checked for formats mismatch at
-:ref:`VIDIOC_STREAMON <vidioc-streamon>` time, and an EPIPE error
+:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` time, and an EPIPE error
 code is then returned if the configuration is invalid.
 
 Pad-level image format configuration support can be tested by calling
-the :ref:`VIDIOC_SUBDEV_G_FMT <vidioc-subdev-g-fmt>` ioctl on pad
+the :ref:`VIDIOC_SUBDEV_G_FMT <VIDIOC_SUBDEV_G_FMT>` ioctl on pad
 0. If the driver returns an EINVAL error code pad-level format
 configuration is not supported by the sub-device.
 

@@ -146,8 +146,8 @@ formats enumeration only. A format negotiation mechanism is required.
 Central to the format negotiation mechanism are the get/set format
 operations. When called with the ``which`` argument set to
 ``V4L2_SUBDEV_FORMAT_TRY``, the
-:ref:`VIDIOC_SUBDEV_G_FMT <vidioc-subdev-g-fmt>` and
-:ref:`VIDIOC_SUBDEV_S_FMT <vidioc-subdev-g-fmt>` ioctls operate on
+:ref:`VIDIOC_SUBDEV_G_FMT <VIDIOC_SUBDEV_G_FMT>` and
+:ref:`VIDIOC_SUBDEV_S_FMT <VIDIOC_SUBDEV_G_FMT>` ioctls operate on
 a set of formats parameters that are not connected to the hardware
 configuration. Modifying those 'try' formats leaves the device state
 untouched (this applies to both the software state stored in the driver

@@ -155,14 +155,14 @@ and the hardware state stored in the device itself).
 
 While not kept as part of the device state, try formats are stored in
 the sub-device file handles. A
-:ref:`VIDIOC_SUBDEV_G_FMT <vidioc-subdev-g-fmt>` call will return
+:ref:`VIDIOC_SUBDEV_G_FMT <VIDIOC_SUBDEV_G_FMT>` call will return
 the last try format set *on the same sub-device file handle*. Several
 applications querying the same sub-device at the same time will thus not
 interact with each other.
 
 To find out whether a particular format is supported by the device,
 applications use the
-:ref:`VIDIOC_SUBDEV_S_FMT <vidioc-subdev-g-fmt>` ioctl. Drivers
+:ref:`VIDIOC_SUBDEV_S_FMT <VIDIOC_SUBDEV_G_FMT>` ioctl. Drivers
 verify and, if needed, change the requested ``format`` based on device
 requirements and return the possibly modified value. Applications can
 then choose to try a different format or accept the returned value and

@@ -171,7 +171,7 @@ continue.
 Formats returned by the driver during a negotiation iteration are
 guaranteed to be supported by the device. In particular, drivers
 guarantee that a returned format will not be further changed if passed
-to an :ref:`VIDIOC_SUBDEV_S_FMT <vidioc-subdev-g-fmt>` call as-is
+to an :ref:`VIDIOC_SUBDEV_S_FMT <VIDIOC_SUBDEV_G_FMT>` call as-is
 (as long as external parameters, such as formats on other pads or links'
 configuration are not changed).
 

@@ -353,7 +353,7 @@ struct :ref:`v4l2_rect <v4l2-rect>`.
 Scaling support is optional. When supported by a subdev, the crop
 rectangle on the subdev's sink pad is scaled to the size configured
 using the
-:ref:`VIDIOC_SUBDEV_S_SELECTION <vidioc-subdev-g-selection>` IOCTL
+:ref:`VIDIOC_SUBDEV_S_SELECTION <VIDIOC_SUBDEV_G_SELECTION>` IOCTL
 using ``V4L2_SEL_TGT_COMPOSE`` selection target on the same pad. If the
 subdev supports scaling but not composing, the top and left values are
 not used and must always be set to zero.

269 lines not on this page · raw message

index ac14cf89fa38..bc2944c27e70 100644
@@ -14,15 +14,15 @@ previously exported for a different or the same device (known as the
 importer role), or both. This section describes the DMABUF importer role
 API in V4L2.
 
-Refer to :ref:`DMABUF exporting <vidioc-expbuf>` for details about
+Refer to :ref:`DMABUF exporting <VIDIOC_EXPBUF>` for details about
 exporting V4L2 buffers as DMABUF file descriptors.
 
 Input and output devices support the streaming I/O method when the
 ``V4L2_CAP_STREAMING`` flag in the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl is set. Whether
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl is set. Whether
 importing DMA buffers through DMABUF file descriptors is supported is
-determined by calling the :ref:`VIDIOC_REQBUFS <vidioc-reqbufs>`
+determined by calling the :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>`
 ioctl with the memory type set to ``V4L2_MEMORY_DMABUF``.
 
 This I/O method is dedicated to sharing DMA buffers between different

@@ -34,7 +34,7 @@ such file descriptor are exchanged. The descriptors and meta-information
 are passed in struct :ref:`v4l2_buffer <v4l2-buffer>` (or in struct
 :ref:`v4l2_plane <v4l2-plane>` in the multi-planar API case). The
 driver must be switched into DMABUF I/O mode by calling the
-:ref:`VIDIOC_REQBUFS <vidioc-reqbufs>` with the desired buffer type.
+:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` with the desired buffer type.
 
 
 .. code-block:: c

@@ -56,7 +56,7 @@ driver must be switched into DMABUF I/O mode by calling the
     }
 
 The buffer (plane) file descriptor is passed on the fly with the
-:ref:`VIDIOC_QBUF <vidioc-qbuf>` ioctl. In case of multiplanar
+:ref:`VIDIOC_QBUF <VIDIOC_QBUF>` ioctl. In case of multiplanar
 buffers, every plane can be associated with a different DMABUF
 descriptor. Although buffers are commonly cycled, applications can pass
 a different DMABUF descriptor at each ``VIDIOC_QBUF`` call.

@@ -112,11 +112,11 @@ a different DMABUF descriptor at each ``VIDIOC_QBUF`` call.
     }
 
 Captured or displayed buffers are dequeued with the
-:ref:`VIDIOC_DQBUF <vidioc-qbuf>` ioctl. The driver can unlock the
+:ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. The driver can unlock the
 buffer at any time between the completion of the DMA and this ioctl. The
 memory is also unlocked when
-:ref:`VIDIOC_STREAMOFF <vidioc-streamon>` is called,
-:ref:`VIDIOC_REQBUFS <vidioc-reqbufs>`, or when the device is closed.
+:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` is called,
+:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>`, or when the device is closed.
 
 For capturing applications it is customary to enqueue a number of empty
 buffers, to start capturing and enter the read loop. Here the

@@ -134,8 +134,8 @@ immediately with an EAGAIN error code when no buffer is available. The
 functions are always available.
 
 To start and stop capturing or displaying applications call the
-:ref:`VIDIOC_STREAMON <vidioc-streamon>` and
-:ref:`VIDIOC_STREAMOFF <vidioc-streamon>` ioctls. Note that
+:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` and
+:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` ioctls. Note that
 ``VIDIOC_STREAMOFF`` removes all buffers from both queues and unlocks
 all buffers as a side effect. Since there is no notion of doing anything
 "now" on a multitasking system, if an application needs to synchronize

index a347ce7cb504..d51c36ec604c 100644
@@ -24,14 +24,14 @@ standards.
 
 To enumerate and query the attributes of the DV timings supported by a
 device applications use the
-:ref:`VIDIOC_ENUM_DV_TIMINGS <vidioc-enum-dv-timings>` and
-:ref:`VIDIOC_DV_TIMINGS_CAP <vidioc-dv-timings-cap>` ioctls. To set
+:ref:`VIDIOC_ENUM_DV_TIMINGS <VIDIOC_ENUM_DV_TIMINGS>` and
+:ref:`VIDIOC_DV_TIMINGS_CAP <VIDIOC_DV_TIMINGS_CAP>` ioctls. To set
 DV timings for the device applications use the
-:ref:`VIDIOC_S_DV_TIMINGS <vidioc-g-dv-timings>` ioctl and to get
+:ref:`VIDIOC_S_DV_TIMINGS <VIDIOC_G_DV_TIMINGS>` ioctl and to get
 current DV timings they use the
-:ref:`VIDIOC_G_DV_TIMINGS <vidioc-g-dv-timings>` ioctl. To detect
+:ref:`VIDIOC_G_DV_TIMINGS <VIDIOC_G_DV_TIMINGS>` ioctl. To detect
 the DV timings as seen by the video receiver applications use the
-:ref:`VIDIOC_QUERY_DV_TIMINGS <vidioc-query-dv-timings>` ioctl.
+:ref:`VIDIOC_QUERY_DV_TIMINGS <VIDIOC_QUERY_DV_TIMINGS>` ioctl.
 
 Applications can make use of the :ref:`input-capabilities` and
 :ref:`output-capabilities` flags to determine whether the digital

index 5f9779e94cde..66333b9f60fd 100644
@@ -39,12 +39,12 @@ 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
+: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
+: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.
 

@@ -79,17 +79,17 @@ 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
+: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.
 
 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
-the :ref:`VIDIOC_QUERYCTRL <vidioc-queryctrl>` (or
-:ref:`VIDIOC_QUERY_EXT_CTRL <vidioc-queryctrl>`) and
-:ref:`VIDIOC_QUERYMENU <vidioc-queryctrl>` ioctls to check this. Also
+the :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` (or
+:ref:`VIDIOC_QUERY_EXT_CTRL <VIDIOC_QUERYCTRL>`) and
+:ref:`VIDIOC_QUERYMENU <VIDIOC_QUERYCTRL>` ioctls to check this. Also
 note that 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

@@ -103,7 +103,7 @@ Enumerating Extended Controls
 =============================
 
 The recommended way to enumerate over the extended controls is by using
-:ref:`VIDIOC_QUERYCTRL <vidioc-queryctrl>` in combination with the
+:ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` in combination with the
 ``V4L2_CTRL_FLAG_NEXT_CTRL`` flag:
 
 

@@ -169,7 +169,7 @@ 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 <vidioc-queryctrl>` documentation for more
+:ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` documentation for more
 details.
 
 

@@ -198,7 +198,7 @@ Codec Control IDs
 
 ``V4L2_CID_MPEG_CLASS (class)``
     The Codec class descriptor. Calling
-    :ref:`VIDIOC_QUERYCTRL <vidioc-queryctrl>` for this control will
+    :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` for this control will
     return a description of this control class. This description can be
     used as the caption of a Tab page in a GUI, for example.
 

@@ -1168,7 +1168,7 @@ Codec Control IDs
     This read-only control returns the 33-bit video Presentation Time
     Stamp as defined in ITU T-REC-H.222.0 and ISO/IEC 13818-1 of the
     currently displayed frame. This is the same PTS as is used in
-    :ref:`VIDIOC_DECODER_CMD <vidioc-decoder-cmd>`.
+    :ref:`VIDIOC_DECODER_CMD <VIDIOC_DECODER_CMD>`.
 
 .. _`v4l2-mpeg-video-dec-frame`:
 

@@ -2781,7 +2781,7 @@ Camera Control IDs
 
 ``V4L2_CID_CAMERA_CLASS (class)``
     The Camera class descriptor. Calling
-    :ref:`VIDIOC_QUERYCTRL <vidioc-queryctrl>` for this control will
+    :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` for this control will
     return a description of this control class.
 
 .. _`v4l2-exposure-auto-type`:

@@ -3441,7 +3441,7 @@ FM_TX Control IDs
 
 ``V4L2_CID_FM_TX_CLASS (class)``
     The FM_TX class descriptor. Calling
-    :ref:`VIDIOC_QUERYCTRL <vidioc-queryctrl>` for this control will
+    :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` for this control will
     return a description of this control class.
 
 ``V4L2_CID_RDS_TX_DEVIATION (integer)``

@@ -3870,7 +3870,7 @@ JPEG Control IDs
 
 ``V4L2_CID_JPEG_CLASS (class)``
     The JPEG class descriptor. Calling
-    :ref:`VIDIOC_QUERYCTRL <vidioc-queryctrl>` for this control will
+    :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` for this control will
     return a description of this control class.
 
 ``V4L2_CID_JPEG_CHROMA_SUBSAMPLING (menu)``

@@ -4271,7 +4271,7 @@ FM_RX Control IDs
 
 ``V4L2_CID_FM_RX_CLASS (class)``
     The FM_RX class descriptor. Calling
-    :ref:`VIDIOC_QUERYCTRL <vidioc-queryctrl>` for this control will
+    :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` for this control will
     return a description of this control class.
 
 ``V4L2_CID_RDS_RECEPTION (boolean)``

@@ -4369,7 +4369,7 @@ Detect Control IDs
 
 ``V4L2_CID_DETECT_CLASS (class)``
     The Detect class descriptor. Calling
-    :ref:`VIDIOC_QUERYCTRL <vidioc-queryctrl>` for this control will
+    :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` for this control will
     return a description of this control class.
 
 ``V4L2_CID_DETECT_MD_MODE (menu)``

@@ -4463,7 +4463,7 @@ RF_TUNER Control IDs
 
 ``V4L2_CID_RF_TUNER_CLASS (class)``
     The RF_TUNER class descriptor. Calling
-    :ref:`VIDIOC_QUERYCTRL <vidioc-queryctrl>` for this control will
+    :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` for this control will
     return a description of this control class.
 
 ``V4L2_CID_RF_TUNER_BANDWIDTH_AUTO (boolean)``

index 295ec0430183..0ab52df521a8 100644
@@ -48,7 +48,7 @@ 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
 :ref:`v4l2_pix_format <v4l2-pix-format>` before calling the
-:ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl. If this is not desired it
+:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl. If this is not desired it
 should have the value ``V4L2_FIELD_ANY`` (0).
 
 

@@ -73,8 +73,8 @@ should have the value ``V4L2_FIELD_ANY`` (0).
           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
+          :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` or
+          :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>`. struct
           :ref:`v4l2_buffer <v4l2-buffer>` ``field`` can never be
           ``V4L2_FIELD_ANY``.
 

index c1e30a64c833..a754fa81f707 100644
@@ -23,9 +23,9 @@ current selection.
 
 A single mechanism exists to negotiate all data formats using the
 aggregate struct :ref:`v4l2_format <v4l2-format>` and the
-:ref:`VIDIOC_G_FMT <vidioc-g-fmt>` and
-:ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctls. Additionally the
-:ref:`VIDIOC_TRY_FMT <vidioc-g-fmt>` ioctl can be used to examine
+:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` and
+:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctls. Additionally the
+:ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl can be used to examine
 what the hardware *could* do, without actually selecting a new data
 format. The data formats supported by the V4L2 API are covered in the
 respective device section in :ref:`devices`. For a closer look at

@@ -52,7 +52,7 @@ image size.
 
 When applications omit the ``VIDIOC_S_FMT`` ioctl its locking side
 effects are implied by the next step, the selection of an I/O method
-with the :ref:`VIDIOC_REQBUFS <vidioc-reqbufs>` ioctl or implicit
+with the :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl or implicit
 with the first :ref:`read() <func-read>` or
 :ref:`write() <func-write>` call.
 

@@ -75,7 +75,7 @@ Apart of the generic format negotiation functions a special ioctl to
 enumerate all image formats supported by video capture, overlay or
 output devices is available. [1]_
 
-The :ref:`VIDIOC_ENUM_FMT <vidioc-enum-fmt>` ioctl must be supported
+The :ref:`VIDIOC_ENUM_FMT <VIDIOC_ENUM_FMT>` ioctl must be supported
 by all drivers exchanging image data with applications.
 
     **Important**

index fb6e4cd52e24..7243142384bb 100644
@@ -98,8 +98,8 @@ application address space, preferably at address ``start``. This latter
 address is a hint only, and is usually specified as 0.
 
 Suitable length and offset parameters are queried with the
-:ref:`VIDIOC_QUERYBUF <vidioc-querybuf>` ioctl. Buffers must be
-allocated with the :ref:`VIDIOC_REQBUFS <vidioc-reqbufs>` ioctl
+:ref:`VIDIOC_QUERYBUF <VIDIOC_QUERYBUF>` ioctl. Buffers must be
+allocated with the :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl
 before they can be queried.
 
 To unmap buffers the :ref:`munmap() <func-munmap>` function is used.

@@ -125,7 +125,7 @@ EINVAL
     The ``flags`` or ``prot`` value is not supported.
 
     No buffers have been allocated with the
-    :ref:`VIDIOC_REQBUFS <vidioc-reqbufs>` ioctl.
+    :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl.
 
 ENOMEM
     Not enough physical or virtual memory was available to complete the

index 21b1dfddc118..370a6858d65d 100644
@@ -33,7 +33,7 @@ Arguments
     devices only writing.
 
     When the ``O_NONBLOCK`` flag is given, the read() function and the
-    :ref:`VIDIOC_DQBUF <vidioc-qbuf>` ioctl will return the EAGAIN
+    :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl will return the EAGAIN
     error code when no data is available or no buffer is in the driver
     outgoing queue, otherwise these functions block until data becomes
     available. All V4L2 drivers exchanging data with applications must

index d3ad7b8d1a90..28a769af9309 100644
@@ -30,9 +30,9 @@ output.
 
 When streaming I/O has been negotiated this function waits until a
 buffer has been filled by the capture device and can be dequeued with
-the :ref:`VIDIOC_DQBUF <vidioc-qbuf>` ioctl. For output devices this
+the :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. For output devices this
 function waits until the device is ready to accept a new buffer to be
-queued up with the :ref:`VIDIOC_QBUF <vidioc-qbuf>` ioctl for
+queued up with the :ref:`VIDIOC_QBUF <VIDIOC_QBUF>` ioctl for
 display. When buffers are already in the outgoing queue of the driver
 (capture) or the incoming queue isn't full (display) the function
 returns immediately.

@@ -45,17 +45,17 @@ flags in the ``revents`` field, output devices the ``POLLOUT`` and
 ``POLLWRNORM`` flags. When the function timed out it returns a value of
 zero, on failure it returns -1 and the ``errno`` variable is set
 appropriately. When the application did not call
-:ref:`VIDIOC_STREAMON <vidioc-streamon>` the :c:func:`poll()`
+:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` the :c:func:`poll()`
 function succeeds, but sets the ``POLLERR`` flag in the ``revents``
 field. When the application has called
-:ref:`VIDIOC_STREAMON <vidioc-streamon>` for a capture device but
-hasn't yet called :ref:`VIDIOC_QBUF <vidioc-qbuf>`, the
+:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` for a capture device but
+hasn't yet called :ref:`VIDIOC_QBUF <VIDIOC_QBUF>`, the
 :c:func:`poll()` function succeeds and sets the ``POLLERR`` flag in
 the ``revents`` field. For output devices this same situation will cause
 :c:func:`poll()` to succeed as well, but it sets the ``POLLOUT`` and
 ``POLLWRNORM`` flags in the ``revents`` field.
 
-If an event occurred (see :ref:`VIDIOC_DQEVENT <vidioc-dqevent>`)
+If an event occurred (see :ref:`VIDIOC_DQEVENT <VIDIOC_DQEVENT>`)
 then ``POLLPRI`` will be set in the ``revents`` field and
 :c:func:`poll()` will return.
 

index b46cbbdeeab7..497bc9a9dd5a 100644
@@ -85,8 +85,8 @@ enough. Again, the behavior when the driver runs out of free buffers
 depends on the discarding policy.
 
 Applications can get and set the number of buffers used internally by
-the driver with the :ref:`VIDIOC_G_PARM <vidioc-g-parm>` and
-:ref:`VIDIOC_S_PARM <vidioc-g-parm>` ioctls. They are optional,
+the driver with the :ref:`VIDIOC_G_PARM <VIDIOC_G_PARM>` and
+:ref:`VIDIOC_S_PARM <VIDIOC_G_PARM>` ioctls. They are optional,
 however. The discarding policy is not reported and cannot be changed.
 For minimum requirements see :ref:`devices`.
 

index 7c9706838cb3..77fdf33648b3 100644
@@ -32,17 +32,17 @@ for output.
 
 When streaming I/O has been negotiated this function waits until a
 buffer has been filled or displayed and can be dequeued with the
-:ref:`VIDIOC_DQBUF <vidioc-qbuf>` ioctl. When buffers are already in
+:ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. When buffers are already in
 the outgoing queue of the driver the function returns immediately.
 
 On success :c:func:`select()` returns the total number of bits set in
 the :c:type:`struct fd_set`s. When the function timed out it returns
 a value of zero. On failure it returns -1 and the ``errno`` variable is
 set appropriately. When the application did not call
-:ref:`VIDIOC_QBUF <vidioc-qbuf>` or
-:ref:`VIDIOC_STREAMON <vidioc-streamon>` yet the :c:func:`select()`
+:ref:`VIDIOC_QBUF <VIDIOC_QBUF>` or
+:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` yet the :c:func:`select()`
 function succeeds, setting the bit of the file descriptor in ``readfds``
-or ``writefds``, but subsequent :ref:`VIDIOC_DQBUF <vidioc-qbuf>`
+or ``writefds``, but subsequent :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>`
 calls will fail. [1]_
 
 When use of the :c:func:`read()` function has been negotiated and the

351 lines not on this page · raw message

index a7ca0d5fc5dd..2bc04e597c90 100644
@@ -16,12 +16,12 @@ read or write will fail at any time.
 
 Other methods must be negotiated. To select the streaming I/O method
 with memory mapped or user buffers applications call the
-:ref:`VIDIOC_REQBUFS <vidioc-reqbufs>` ioctl. The asynchronous I/O
+:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl. The asynchronous I/O
 method is not defined yet.
 
 Video overlay can be considered another I/O method, although the
 application does not directly receive the image data. It is selected by
-initiating video overlay with the :ref:`VIDIOC_S_FMT <vidioc-g-fmt>`
+initiating video overlay with the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
 ioctl. For more information see :ref:`overlay`.
 
 Generally exactly one I/O method, including overlay, is associated with

index 533ea4e18770..4fd87ec33260 100644
@@ -91,17 +91,17 @@ and to enhance the image quality.
 
 In most cases, libv4l2 just passes the calls directly through to the
 v4l2 driver, intercepting the calls to
-:ref:`VIDIOC_TRY_FMT <vidioc-g-fmt>`,
-:ref:`VIDIOC_G_FMT <vidioc-g-fmt>`
-:ref:`VIDIOC_S_FMT <vidioc-g-fmt>`
-:ref:`VIDIOC_ENUM_FRAMESIZES <vidioc-enum-framesizes>` and
-:ref:`VIDIOC_ENUM_FRAMEINTERVALS <vidioc-enum-frameintervals>` in
+:ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>`,
+:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`
+:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
+:ref:`VIDIOC_ENUM_FRAMESIZES <VIDIOC_ENUM_FRAMESIZES>` and
+:ref:`VIDIOC_ENUM_FRAMEINTERVALS <VIDIOC_ENUM_FRAMEINTERVALS>` in
 order to emulate the formats
 :ref:`V4L2_PIX_FMT_BGR24 <V4L2-PIX-FMT-BGR24>`,
 :ref:`V4L2_PIX_FMT_RGB24 <V4L2-PIX-FMT-RGB24>`,
 :ref:`V4L2_PIX_FMT_YUV420 <V4L2-PIX-FMT-YUV420>`, and
 :ref:`V4L2_PIX_FMT_YVU420 <V4L2-PIX-FMT-YVU420>`, if they aren't
-available in the driver. :ref:`VIDIOC_ENUM_FMT <vidioc-enum-fmt>`
+available in the driver. :ref:`VIDIOC_ENUM_FMT <VIDIOC_ENUM_FMT>`
 keeps enumerating the hardware supported formats, plus the emulated
 formats offered by libv4l at the end.
 

index 54eb3b607587..de144028ec56 100644
@@ -9,10 +9,10 @@ Streaming I/O (Memory Mapping)
 Input and output devices support this I/O method when the
 ``V4L2_CAP_STREAMING`` flag in the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl is set. There are two
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl is set. There are two
 streaming methods, to determine if the memory mapping flavor is
 supported applications must call the
-:ref:`VIDIOC_REQBUFS <vidioc-reqbufs>` ioctl.
+:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl.
 
 Streaming is an I/O method where only pointers to buffers are exchanged
 between application and driver, the data itself is not copied. Memory

@@ -29,7 +29,7 @@ a different type of data. To access different sets at the same time
 different file descriptors must be used. [1]_
 
 To allocate device buffers applications call the
-:ref:`VIDIOC_REQBUFS <vidioc-reqbufs>` ioctl with the desired number
+:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl with the desired number
 of buffers and buffer type, for example ``V4L2_BUF_TYPE_VIDEO_CAPTURE``.
 This ioctl can also be used to change the number of buffers or to free
 the allocated memory, provided none of the buffers are still mapped.

@@ -37,7 +37,7 @@ the allocated memory, provided none of the buffers are still mapped.
 Before applications can access the buffers they must map them into their
 address space with the :ref:`mmap() <func-mmap>` function. The
 location of the buffers in device memory can be determined with the
-:ref:`VIDIOC_QUERYBUF <vidioc-querybuf>` ioctl. In the single-planar
+:ref:`VIDIOC_QUERYBUF <VIDIOC_QUERYBUF>` ioctl. In the single-planar
 API case, the ``m.offset`` and ``length`` returned in a struct
 :ref:`v4l2_buffer <v4l2-buffer>` are passed as sixth and second
 parameter to the :c:func:`mmap()` function. When using the

@@ -227,10 +227,10 @@ when the application runs out of free buffers, it must wait until an
 empty buffer can be dequeued and reused.
 
 To enqueue and dequeue a buffer applications use the
-:ref:`VIDIOC_QBUF <vidioc-qbuf>` and
-:ref:`VIDIOC_DQBUF <vidioc-qbuf>` ioctl. The status of a buffer being
+:ref:`VIDIOC_QBUF <VIDIOC_QBUF>` and
+:ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. The status of a buffer being
 mapped, enqueued, full or empty can be determined at any time using the
-:ref:`VIDIOC_QUERYBUF <vidioc-querybuf>` ioctl. Two methods exist to
+:ref:`VIDIOC_QUERYBUF <VIDIOC_QUERYBUF>` ioctl. Two methods exist to
 suspend execution of the application until one or more buffers can be
 dequeued. By default ``VIDIOC_DQBUF`` blocks when no buffer is in the
 outgoing queue. When the ``O_NONBLOCK`` flag was given to the

@@ -240,8 +240,8 @@ immediately with an EAGAIN error code when no buffer is available. The
 are always available.
 
 To start and stop capturing or output applications call the
-:ref:`VIDIOC_STREAMON <vidioc-streamon>` and
-:ref:`VIDIOC_STREAMOFF <vidioc-streamon>` ioctl. Note
+:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` and
+:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` ioctl. Note
 ``VIDIOC_STREAMOFF`` removes all buffers from both queues as a side
 effect. Since there is no notion of doing anything "now" on a
 multitasking system, if an application needs to synchronize with another

@@ -258,7 +258,7 @@ the :c:func:`mmap()`, :c:func:`munmap()`, :c:func:`select()` and
 
 .. [1]
    One could use one file descriptor and set the buffer type field
-   accordingly when calling :ref:`VIDIOC_QBUF <vidioc-qbuf>` etc.,
+   accordingly when calling :ref:`VIDIOC_QBUF <VIDIOC_QBUF>` etc.,
    but it makes the :c:func:`select()` function ambiguous. We also
    like the clean approach of one file descriptor per logical stream.
    Video overlay for example is also a logical stream, although the CPU

index 7df540fae201..4c34d61a5253 100644
@@ -108,13 +108,13 @@ are comparable to an ALSA audio mixer application. Just opening a V4L2
 device should not change the state of the device. [2]_
 
 Once an application has allocated the memory buffers needed for
-streaming data (by calling the :ref:`VIDIOC_REQBUFS <vidioc-reqbufs>`
-or :ref:`VIDIOC_CREATE_BUFS <vidioc-create-bufs>` ioctls, or
+streaming data (by calling the :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>`
+or :ref:`VIDIOC_CREATE_BUFS <VIDIOC_CREATE_BUFS>` ioctls, or
 implicitly by calling the :ref:`read() <func-read>` or
 :ref:`write() <func-write>` functions) that application (filehandle)
 becomes the owner of the device. It is no longer allowed to make changes
 that would affect the buffer sizes (e.g. by calling the
-:ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl) and other applications are
+:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl) and other applications are
 no longer allowed to allocate buffers or start or stop streaming. The
 EBUSY error code will be returned instead.
 

index 384876e377b2..b3cb7c48eb74 100644
@@ -27,8 +27,8 @@ Compressed Formats
 
        -  'JPEG'
 
-       -  TBD. See also :ref:`VIDIOC_G_JPEGCOMP <vidioc-g-jpegcomp>`,
-          :ref:`VIDIOC_S_JPEGCOMP <vidioc-g-jpegcomp>`.
+       -  TBD. See also :ref:`VIDIOC_G_JPEGCOMP <VIDIOC_G_JPEGCOMP>`,
+          :ref:`VIDIOC_S_JPEGCOMP <VIDIOC_G_JPEGCOMP>`.
 
     -  .. _`V4L2-PIX-FMT-MPEG`:
 

index f5148ac6d781..f2c599aaa502 100644
@@ -11,9 +11,9 @@ with applications. The :c:type:`struct v4l2_pix_format` and
 format and layout of an image in memory. The former is used with the
 single-planar API, while the latter is used with the multi-planar
 version (see :ref:`planar-apis`). Image formats are negotiated with
-the :ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl. (The explanations here
+the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl. (The explanations here
 focus on video capturing and output, for overlay frame buffer formats
-see also :ref:`VIDIOC_G_FBUF <vidioc-g-fbuf>`.)
+see also :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>`.)
 
 
 .. toctree::

index 4c01adcbf525..017f412a6231 100644
@@ -39,29 +39,29 @@ handle multi-planar formats.
 Calls that distinguish between single and multi-planar APIs
 ===========================================================
 
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>`
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>`
     Two additional multi-planar capabilities are added. They can be set
     together with non-multi-planar ones for devices that handle both
     single- and multi-planar formats.
 
-:ref:`VIDIOC_G_FMT <vidioc-g-fmt>`,
-:ref:`VIDIOC_S_FMT <vidioc-g-fmt>`,
-:ref:`VIDIOC_TRY_FMT <vidioc-g-fmt>`
+:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`,
+:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`,
+:ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>`
     New structures for describing multi-planar formats are added: struct
     :ref:`v4l2_pix_format_mplane <v4l2-pix-format-mplane>` and
     struct :ref:`v4l2_plane_pix_format <v4l2-plane-pix-format>`.
     Drivers may define new multi-planar formats, which have distinct
     FourCC codes from the existing single-planar ones.
 
-:ref:`VIDIOC_QBUF <vidioc-qbuf>`,
-:ref:`VIDIOC_DQBUF <vidioc-qbuf>`,
-:ref:`VIDIOC_QUERYBUF <vidioc-querybuf>`
+:ref:`VIDIOC_QBUF <VIDIOC_QBUF>`,
+:ref:`VIDIOC_DQBUF <VIDIOC_QBUF>`,
+:ref:`VIDIOC_QUERYBUF <VIDIOC_QUERYBUF>`
     A new struct :ref:`v4l2_plane <v4l2-plane>` structure for
     describing planes is added. Arrays of this structure are passed in
     the new ``m.planes`` field of struct
     :ref:`v4l2_buffer <v4l2-buffer>`.
 
-:ref:`VIDIOC_REQBUFS <vidioc-reqbufs>`
+:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>`
     Will allocate multi-planar buffers as requested.
 
 

index ce0c0e3f9b53..d8f080a68195 100644
@@ -11,26 +11,26 @@ are equally applicable to all types of devices. Furthermore devices of
 the same type have different capabilities and this specification permits
 the omission of a few complicated and less important parts of the API.
 
-The :ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl is available to
+The :ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl is available to
 check if the kernel device is compatible with this specification, and to
 query the :ref:`functions <devices>` and :ref:`I/O methods <io>`
 supported by the device.
 
-Starting with kernel version 3.1, :ref:`VIDIOC_QUERYCAP <vidioc-querycap>`
+Starting with kernel version 3.1, :ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>`
 will return the V4L2 API version used by the driver, with generally
 matches the Kernel version. There's no need of using
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` to check if a specific ioctl
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` to check if a specific ioctl
 is supported, the V4L2 core now returns ENOTTY if a driver doesn't
 provide support for an ioctl.
 
 Other features can be queried by calling the respective ioctl, for
-example :ref:`VIDIOC_ENUMINPUT <vidioc-enuminput>` to learn about the
+example :ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>` to learn about the
 number, types and names of video connectors on the device. Although
 abstraction is a major objective of this API, the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl also allows driver
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl also allows driver
 specific applications to reliably identify the driver.
 
-All V4L2 drivers must support :ref:`VIDIOC_QUERYCAP <vidioc-querycap>`.
+All V4L2 drivers must support :ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>`.
 Applications should always call this ioctl after opening the device.
 
 

index c123d3a1bfbb..ad365a6e435d 100644
@@ -10,7 +10,7 @@ Input and output devices support the :c:func:`read()` and
 :c:func:`write()` function, respectively, when the
 ``V4L2_CAP_READWRITE`` flag in the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl is set.
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl is set.
 
 Drivers may need the CPU to copy the data, but they may also support DMA
 to or from user memory, so this I/O method is not necessarily less

index d023cd022295..4890815e268e 100644
@@ -4,7 +4,7 @@
 Configuration
 *************
 
-Applications can use the :ref:`selection API <vidioc-g-selection>` to
+Applications can use the :ref:`selection API <VIDIOC_G_SELECTION>` to
 select an area in a video signal or a buffer, and to query for default
 settings and hardware limits.
 

index db80861c1446..da0b8101b6cc 100644
@@ -11,8 +11,8 @@ variations of standards. Each video input and output may support another
 set of standards. This set is reported by the ``std`` field of struct
 :ref:`v4l2_input <v4l2-input>` and struct
 :ref:`v4l2_output <v4l2-output>` returned by the
-:ref:`VIDIOC_ENUMINPUT <vidioc-enuminput>` and
-:ref:`VIDIOC_ENUMOUTPUT <vidioc-enumoutput>` ioctls, respectively.
+:ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>` and
+:ref:`VIDIOC_ENUMOUTPUT <VIDIOC_ENUMOUTPUT>` ioctls, respectively.
 
 V4L2 defines one bit for each analog video standard currently in use
 worldwide, and sets aside bits for driver defined standards, e. g.

@@ -20,7 +20,7 @@ hybrid standards to watch NTSC video tapes on PAL TVs and vice versa.
 Applications can use the predefined bits to select a particular
 standard, although presenting the user a menu of supported standards is
 preferred. To enumerate and query the attributes of the supported
-standards applications use the :ref:`VIDIOC_ENUMSTD <vidioc-enumstd>`
+standards applications use the :ref:`VIDIOC_ENUMSTD <VIDIOC_ENUMSTD>`
 ioctl.
 
 Many of the defined standards are actually just variations of a few

@@ -36,10 +36,10 @@ Composite input may collapse standards, enumerating "PAL-B/G/H/I",
 "NTSC-M" and "SECAM-D/K". [1]_
 
 To query and select the standard used by the current video input or
-output applications call the :ref:`VIDIOC_G_STD <vidioc-g-std>` and
-:ref:`VIDIOC_S_STD <vidioc-g-std>` ioctl, respectively. The
+output applications call the :ref:`VIDIOC_G_STD <VIDIOC_G_STD>` and
+:ref:`VIDIOC_S_STD <VIDIOC_G_STD>` ioctl, respectively. The
 *received* standard can be sensed with the
-:ref:`VIDIOC_QUERYSTD <vidioc-querystd>` ioctl. Note that the
+:ref:`VIDIOC_QUERYSTD <VIDIOC_QUERYSTD>` ioctl. Note that the
 parameter of all these ioctls is a pointer to a
 :ref:`v4l2_std_id <v4l2-std-id>` type (a standard set), *not* an
 index into the standard enumeration. Drivers must implement all video

index 53f4d7c23a8a..bb8100b6ef87 100644
@@ -8,7 +8,7 @@ Streaming Parameters
 
 Streaming parameters are intended to optimize the video capture process
 as well as I/O. Presently applications can request a high quality
-capture mode with the :ref:`VIDIOC_S_PARM <vidioc-g-parm>` ioctl.
+capture mode with the :ref:`VIDIOC_S_PARM <VIDIOC_G_PARM>` ioctl.
 
 The current video standard determines a nominal number of frames per
 second. If less than this number of frames is to be captured or output,

@@ -23,8 +23,8 @@ internally by a driver in read/write mode. For implications see the
 section discussing the :ref:`read() <func-read>` function.
 
 To get and set the streaming parameters applications call the
-:ref:`VIDIOC_G_PARM <vidioc-g-parm>` and
-:ref:`VIDIOC_S_PARM <vidioc-g-parm>` ioctl, respectively. They take
+:ref:`VIDIOC_G_PARM <VIDIOC_G_PARM>` and
+:ref:`VIDIOC_S_PARM <VIDIOC_G_PARM>` ioctl, respectively. They take
 a pointer to a struct :ref:`v4l2_streamparm <v4l2-streamparm>`, which
 contains a union holding separate parameters for input and output
 devices.

index bc22a99579e3..15c2e6c373ab 100644
@@ -14,7 +14,7 @@ Video input devices can have one or more tuners demodulating a RF
 signal. Each tuner is associated with one or more video inputs,
 depending on the number of RF connectors on the tuner. The ``type``
 field of the respective struct :ref:`v4l2_input <v4l2-input>`
-returned by the :ref:`VIDIOC_ENUMINPUT <vidioc-enuminput>` ioctl is
+returned by the :ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>` ioctl is
 set to ``V4L2_INPUT_TYPE_TUNER`` and its ``tuner`` field contains the
 index number of the tuner.
 

@@ -22,8 +22,8 @@ Radio input devices have exactly one tuner with index zero, no video
 inputs.
 
 To query and change tuner properties applications use the
-:ref:`VIDIOC_G_TUNER <vidioc-g-tuner>` and
-:ref:`VIDIOC_S_TUNER <vidioc-g-tuner>` ioctls, respectively. The
+:ref:`VIDIOC_G_TUNER <VIDIOC_G_TUNER>` and
+:ref:`VIDIOC_S_TUNER <VIDIOC_G_TUNER>` ioctls, respectively. The
 struct :ref:`v4l2_tuner <v4l2-tuner>` returned by ``VIDIOC_G_TUNER``
 also contains signal status information applicable when the tuner of the
 current video or radio input is queried. Note that ``VIDIOC_S_TUNER``

@@ -31,7 +31,7 @@ does not switch the current tuner, when there is more than one at all.
 The tuner is solely determined by the current video input. Drivers must
 support both ioctls and set the ``V4L2_CAP_TUNER`` flag in the struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl when the device has
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl when the device has
 one or more tuners.
 
 

@@ -44,7 +44,7 @@ set or video recorder. Each modulator is associated with one or more
 video outputs, depending on the number of RF connectors on the
 modulator. The ``type`` field of the respective struct
 :ref:`v4l2_output <v4l2-output>` returned by the
-:ref:`VIDIOC_ENUMOUTPUT <vidioc-enumoutput>` ioctl is set to
+:ref:`VIDIOC_ENUMOUTPUT <VIDIOC_ENUMOUTPUT>` ioctl is set to
 ``V4L2_OUTPUT_TYPE_MODULATOR`` and its ``modulator`` field contains the
 index number of the modulator.
 

@@ -55,18 +55,18 @@ A video or radio device cannot support both a tuner and a modulator. Two
 separate device nodes will have to be used for such hardware, one that
 supports the tuner functionality and one that supports the modulator
 functionality. The reason is a limitation with the
-:ref:`VIDIOC_S_FREQUENCY <vidioc-g-frequency>` ioctl where you
+:ref:`VIDIOC_S_FREQUENCY <VIDIOC_G_FREQUENCY>` ioctl where you
 cannot specify whether the frequency is for a tuner or a modulator.
 
 To query and change modulator properties applications use the
-:ref:`VIDIOC_G_MODULATOR <vidioc-g-modulator>` and
-:ref:`VIDIOC_S_MODULATOR <vidioc-g-modulator>` ioctl. Note that
+:ref:`VIDIOC_G_MODULATOR <VIDIOC_G_MODULATOR>` and
+:ref:`VIDIOC_S_MODULATOR <VIDIOC_G_MODULATOR>` ioctl. Note that
 ``VIDIOC_S_MODULATOR`` does not switch the current modulator, when there
 is more than one at all. The modulator is solely determined by the
 current video output. Drivers must support both ioctls and set the
 ``V4L2_CAP_MODULATOR`` flag in the struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl when the device has
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl when the device has
 one or more modulators.
 
 

@@ -74,8 +74,8 @@ Radio Frequency
 ===============
 
 To get and set the tuner or modulator radio frequency applications use
-the :ref:`VIDIOC_G_FREQUENCY <vidioc-g-frequency>` and
-:ref:`VIDIOC_S_FREQUENCY <vidioc-g-frequency>` ioctl which both take
+the :ref:`VIDIOC_G_FREQUENCY <VIDIOC_G_FREQUENCY>` and
+:ref:`VIDIOC_S_FREQUENCY <VIDIOC_G_FREQUENCY>` ioctl which both take
 a pointer to a struct :ref:`v4l2_frequency <v4l2-frequency>`. These
 ioctls are used for TV and radio devices alike. Drivers must support
 both ioctls when the tuner or modulator ioctls are supported, or when

index 83558d27bd69..5433025d41d9 100644
@@ -9,10 +9,10 @@ Streaming I/O (User Pointers)
 Input and output devices support this I/O method when the
 ``V4L2_CAP_STREAMING`` flag in the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl is set. If the
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl is set. If the
 particular user pointer method (not only memory mapping) is supported
 must be determined by calling the
-:ref:`VIDIOC_REQBUFS <vidioc-reqbufs>` ioctl.
+:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl.
 
 This I/O method combines advantages of the read/write and memory mapping
 methods. Buffers (planes) are allocated by the application itself, and

@@ -21,7 +21,7 @@ data are exchanged, these pointers and meta-information are passed in
 struct :ref:`v4l2_buffer <v4l2-buffer>` (or in struct
 :ref:`v4l2_plane <v4l2-plane>` in the multi-planar API case). The
 driver must be switched into user pointer I/O mode by calling the
-:ref:`VIDIOC_REQBUFS <vidioc-reqbufs>` with the desired buffer type.
+:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` with the desired buffer type.
 No buffers (planes) are allocated beforehand, consequently they are not
 indexed and cannot be queried like mapped buffers with the
 ``VIDIOC_QUERYBUF`` ioctl.

@@ -45,7 +45,7 @@ indexed and cannot be queried like mapped buffers with the
     }
 
 Buffer (plane) addresses and sizes are passed on the fly with the
-:ref:`VIDIOC_QBUF <vidioc-qbuf>` ioctl. Although buffers are commonly
+:ref:`VIDIOC_QBUF <VIDIOC_QBUF>` ioctl. Although buffers are commonly
 cycled, applications can pass different addresses and sizes at each
 ``VIDIOC_QBUF`` call. If required by the hardware the driver swaps
 memory pages within physical memory to create a continuous area of

@@ -55,11 +55,11 @@ to disk they are brought back and finally locked in physical memory for
 DMA. [1]_
 
 Filled or displayed buffers are dequeued with the
-:ref:`VIDIOC_DQBUF <vidioc-qbuf>` ioctl. The driver can unlock the
+:ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. The driver can unlock the
 memory pages at any time between the completion of the DMA and this
 ioctl. The memory is also unlocked when
-:ref:`VIDIOC_STREAMOFF <vidioc-streamon>` is called,
-:ref:`VIDIOC_REQBUFS <vidioc-reqbufs>`, or when the device is closed.
+:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` is called,
+:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>`, or when the device is closed.
 Applications must take care not to free buffers without dequeuing. For
 once, the buffers remain locked until further, wasting physical memory.
 Second the driver will not be notified when the memory is returned to

@@ -82,8 +82,8 @@ immediately with an EAGAIN error code when no buffer is available. The
 are always available.
 
 To start and stop capturing or output applications call the
-:ref:`VIDIOC_STREAMON <vidioc-streamon>` and
-:ref:`VIDIOC_STREAMOFF <vidioc-streamon>` ioctl. Note
+:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` and
+:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` ioctl. Note
 ``VIDIOC_STREAMOFF`` removes all buffers from both queues and unlocks
 all buffers as a side effect. Since there is no notion of doing anything
 "now" on a multitasking system, if an application needs to synchronize

index 44605ec92a50..c9ba2859ebe5 100644
@@ -86,7 +86,7 @@ Revision History
 
 :revision: 4.5 / 2015-10-29 (*rr*)
 
-Extend vidioc-g-ext-ctrls;. Replace ctrl_class with a new union with
+Extend VIDIOC_G_EXT_CTRLS;. Replace ctrl_class with a new union with
 ctrl_class and which. Which is used to select the current value of the
 control or the default value.
 

index fc220be52c2b..e4e543b56989 100644
@@ -14,17 +14,17 @@ Radio devices have no video inputs or outputs.
 
 To learn about the number and attributes of the available inputs and
 outputs applications can enumerate them with the
-:ref:`VIDIOC_ENUMINPUT <vidioc-enuminput>` and
-:ref:`VIDIOC_ENUMOUTPUT <vidioc-enumoutput>` ioctl, respectively. The
+:ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>` and
+:ref:`VIDIOC_ENUMOUTPUT <VIDIOC_ENUMOUTPUT>` ioctl, respectively. The
 struct :ref:`v4l2_input <v4l2-input>` returned by the
-:ref:`VIDIOC_ENUMINPUT <vidioc-enuminput>` ioctl also contains signal
+:ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>` ioctl also contains signal
 :status information applicable when the current video input is queried.
 
-The :ref:`VIDIOC_G_INPUT <vidioc-g-input>` and
-:ref:`VIDIOC_G_OUTPUT <vidioc-g-output>` ioctls return the index of
+The :ref:`VIDIOC_G_INPUT <VIDIOC_G_INPUT>` and
+:ref:`VIDIOC_G_OUTPUT <VIDIOC_G_OUTPUT>` ioctls return the index of
 the current video input or output. To select a different input or output
-applications call the :ref:`VIDIOC_S_INPUT <vidioc-g-input>` and
-:ref:`VIDIOC_S_OUTPUT <vidioc-g-output>` ioctls. Drivers must
+applications call the :ref:`VIDIOC_S_INPUT <VIDIOC_G_INPUT>` and
+:ref:`VIDIOC_S_OUTPUT <VIDIOC_G_OUTPUT>` ioctls. Drivers must
 implement all the input ioctls when the device has one or more inputs,
 all the output ioctls when the device has one or more outputs.
 

index e512fe26569e..9c2a011f389c 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-create-bufs:
+.. _VIDIOC_CREATE_BUFS:
 
 ************************
 ioctl VIDIOC_CREATE_BUFS

@@ -34,7 +34,7 @@ Description
 This ioctl is used to create buffers for :ref:`memory mapped <mmap>`
 or :ref:`user pointer <userp>` or :ref:`DMA buffer <dmabuf>` I/O. It
 can be used as an alternative or in addition to the
-:ref:`VIDIOC_REQBUFS <vidioc-reqbufs>` ioctl, when a tighter control
+:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl, when a tighter control
 over buffers is required. This ioctl can be called multiple times to
 create buffers of different sizes.
 

@@ -47,8 +47,8 @@ array must be zeroed.
 The ``format`` field specifies the image format that the buffers must be
 able to handle. The application has to fill in this struct
 :ref:`v4l2_format <v4l2-format>`. Usually this will be done using the
-:ref:`VIDIOC_TRY_FMT <vidioc-g-fmt>` or
-:ref:`VIDIOC_G_FMT <vidioc-g-fmt>` ioctls to ensure that the
+:ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` or
+:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` ioctls to ensure that the
 requested format is supported by the driver. Based on the format's
 ``type`` field the requested buffer size (for single-planar) or plane
 sizes (for multi-planar formats) will be used for the allocated buffers.

index 7fa9e2750457..22b5efe1d2e4 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-cropcap:
+.. _VIDIOC_CROPCAP:
 
 ********************
 ioctl VIDIOC_CROPCAP

index 0bb92acd1729..0a92e2550ce0 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-dbg-g-chip-info:
+.. _VIDIOC_DBG_G_CHIP_INFO:
 
 ****************************
 ioctl VIDIOC_DBG_G_CHIP_INFO

index 613fd256d9bc..1b86abcc44c7 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-dbg-g-register:
+.. _VIDIOC_DBG_G_REGISTER:
 
 **************************************************
 ioctl VIDIOC_DBG_G_REGISTER, VIDIOC_DBG_S_REGISTER

@@ -65,14 +65,14 @@ When ``match.type`` is ``V4L2_CHIP_MATCH_BRIDGE``, ``match.addr``
 selects the nth non-sub-device chip on the TV card. The number zero
 always selects the host chip, e. g. the chip connected to the PCI or USB
 bus. You can find out which chips are present with the
-:ref:`VIDIOC_DBG_G_CHIP_INFO <vidioc-dbg-g-chip-info>` ioctl.
+:ref:`VIDIOC_DBG_G_CHIP_INFO <VIDIOC_DBG_G_CHIP_INFO>` ioctl.
 
 When ``match.type`` is ``V4L2_CHIP_MATCH_SUBDEV``, ``match.addr``
 selects the nth sub-device.
 
 These ioctls are optional, not all drivers may support them. However
 when a driver supports these ioctls it must also support
-:ref:`VIDIOC_DBG_G_CHIP_INFO <vidioc-dbg-g-chip-info>`. Conversely
+:ref:`VIDIOC_DBG_G_CHIP_INFO <VIDIOC_DBG_G_CHIP_INFO>`. Conversely
 it may support ``VIDIOC_DBG_G_CHIP_INFO`` but not these ioctls.
 
 ``VIDIOC_DBG_G_REGISTER`` and ``VIDIOC_DBG_S_REGISTER`` were introduced

index 77c7bdfb90df..ec9dfed09f76 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-decoder-cmd:
+.. _VIDIOC_DECODER_CMD:
 
 ************************************************
 ioctl VIDIOC_DECODER_CMD, VIDIOC_TRY_DECODER_CMD

@@ -43,11 +43,11 @@ this structure.
 The ``cmd`` field must contain the command code. Some commands use the
 ``flags`` field for additional information.
 
-A :c:func:`write()`() or :ref:`VIDIOC_STREAMON <vidioc-streamon>`
+A :c:func:`write()`() or :ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>`
 call sends an implicit START command to the decoder if it has not been
 started yet.
 
-A :c:func:`close()`() or :ref:`VIDIOC_STREAMOFF <vidioc-streamon>`
+A :c:func:`close()`() or :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>`
 call of a streaming file descriptor sends an implicit immediate STOP
 command to the decoder, and all buffered data is discarded.
 

@@ -224,7 +224,7 @@ introduced in Linux 3.3.
           new buffers produced to dequeue. This buffer may be empty,
           indicated by the driver setting the ``bytesused`` field to 0. Once
           the ``V4L2_BUF_FLAG_LAST`` flag was set, the
-          :ref:`VIDIOC_DQBUF <vidioc-qbuf>` ioctl will not block anymore,
+          :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl will not block anymore,
           but return an EPIPE error code. If
           ``V4L2_DEC_CMD_STOP_IMMEDIATELY`` is set, then the decoder stops
           immediately (ignoring the ``pts`` value), otherwise it will keep

index 108348e4df29..45320997344d 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-dqevent:
+.. _VIDIOC_DQEVENT:
 
 ********************
 ioctl VIDIOC_DQEVENT

@@ -226,8 +226,8 @@ call.
           :ref:`v4l2_control <v4l2-control>`.
 
           If the event is generated due to a call to
-          :ref:`VIDIOC_S_CTRL <vidioc-g-ctrl>` or
-          :ref:`VIDIOC_S_EXT_CTRLS <vidioc-g-ext-ctrls>`, then the
+          :ref:`VIDIOC_S_CTRL <VIDIOC_G_CTRL>` or
+          :ref:`VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`, then the
           event will *not* be sent to the file handle that called the ioctl
           function. This prevents nasty feedback loops. If you *do* want to
           get the event, then set the ``V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK``

@@ -363,7 +363,7 @@ call.
 
        -  The 32-bit value of the control for 32-bit control types. This is
           0 for string controls since the value of a string cannot be passed
-          using :ref:`VIDIOC_DQEVENT <vidioc-dqevent>`.
+          using :ref:`VIDIOC_DQEVENT <VIDIOC_DQEVENT>`.
 
     -  .. row 5
 

index d8222ad0df52..b5b8e41dc693 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-dv-timings-cap:
+.. _VIDIOC_DV_TIMINGS_CAP:
 
 *********************************************************
 ioctl VIDIOC_DV_TIMINGS_CAP, VIDIOC_SUBDEV_DV_TIMINGS_CAP

index 018f31e38c6d..ffa363eeaa36 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-encoder-cmd:
+.. _VIDIOC_ENCODER_CMD:
 
 ************************************************
 ioctl VIDIOC_ENCODER_CMD, VIDIOC_TRY_ENCODER_CMD

@@ -48,14 +48,14 @@ currently only used by the STOP command and contains one bit: If the
 until the end of the current *Group Of Pictures*, otherwise it will stop
 immediately.
 
-A :c:func:`read()`() or :ref:`VIDIOC_STREAMON <vidioc-streamon>`
+A :c:func:`read()`() or :ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>`
 call sends an implicit START command to the encoder if it has not been
 started yet. After a STOP command, :c:func:`read()`() calls will read
 the remaining data buffered by the driver. When the buffer is empty,
 :c:func:`read()`() will return zero and the next :c:func:`read()`()
 call will restart the encoder.
 
-A :c:func:`close()`() or :ref:`VIDIOC_STREAMOFF <vidioc-streamon>`
+A :c:func:`close()`() or :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>`
 call of a streaming file descriptor sends an implicit immediate STOP to
 the encoder, and all buffered data is discarded.
 

@@ -134,7 +134,7 @@ introduced in Linux 2.6.21.
           produced to dequeue. This buffer may be empty, indicated by the
           driver setting the ``bytesused`` field to 0. Once the
           ``V4L2_BUF_FLAG_LAST`` flag was set, the
-          :ref:`VIDIOC_DQBUF <vidioc-qbuf>` ioctl will not block anymore,
+          :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl will not block anymore,
           but return an EPIPE error code.
 
     -  .. row 3

index b328829cbf76..5b8f17422fdb 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-enum-dv-timings:
+.. _VIDIOC_ENUM_DV_TIMINGS:
 
 ***********************************************************
 ioctl VIDIOC_ENUM_DV_TIMINGS, VIDIOC_SUBDEV_ENUM_DV_TIMINGS

@@ -35,7 +35,7 @@ Description
 While some DV receivers or transmitters support a wide range of timings,
 others support only a limited number of timings. With this ioctl
 applications can enumerate a list of known supported timings. Call
-:ref:`VIDIOC_DV_TIMINGS_CAP <vidioc-dv-timings-cap>` to check if it
+:ref:`VIDIOC_DV_TIMINGS_CAP <VIDIOC_DV_TIMINGS_CAP>` to check if it
 also supports other standards or even custom timings that are not in
 this list.
 

index bcf7eda8bfdf..f4fc2723f01e 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-enum-fmt:
+.. _VIDIOC_ENUM_FMT:
 
 *********************
 ioctl VIDIOC_ENUM_FMT

index 245e01ff2e58..2c69866c8d9e 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-enum-frameintervals:
+.. _VIDIOC_ENUM_FRAMEINTERVALS:
 
 ********************************
 ioctl VIDIOC_ENUM_FRAMEINTERVALS

@@ -38,8 +38,8 @@ This ioctl allows applications to enumerate all frame intervals that the
 device supports for the given pixel format and frame size.
 
 The supported pixel formats and frame sizes can be obtained by using the
-:ref:`VIDIOC_ENUM_FMT <vidioc-enum-fmt>` and
-:ref:`VIDIOC_ENUM_FRAMESIZES <vidioc-enum-framesizes>` functions.
+:ref:`VIDIOC_ENUM_FMT <VIDIOC_ENUM_FMT>` and
+:ref:`VIDIOC_ENUM_FRAMESIZES <VIDIOC_ENUM_FRAMESIZES>` functions.
 
 The return value and the content of the ``v4l2_frmivalenum.type`` field
 depend on the type of frame intervals the device supports. Here are the

index e3d2ad50db74..9b763ca9d0d8 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-enum-framesizes:
+.. _VIDIOC_ENUM_FRAMESIZES:
 
 ****************************
 ioctl VIDIOC_ENUM_FRAMESIZES

@@ -39,7 +39,7 @@ and height in pixels) that the device supports for the given pixel
 format.
 
 The supported pixel formats can be obtained by using the
-:ref:`VIDIOC_ENUM_FMT <vidioc-enum-fmt>` function.
+:ref:`VIDIOC_ENUM_FMT <VIDIOC_ENUM_FMT>` function.
 
 The return value and the content of the ``v4l2_frmsizeenum.type`` field
 depend on the type of frame sizes the device supports. Here are the

index 7bb726d519be..2f5dbe0583b4 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-enum-freq-bands:
+.. _VIDIOC_ENUM_FREQ_BANDS:
 
 ****************************
 ioctl VIDIOC_ENUM_FREQ_BANDS

index c42e13bf0578..dcca0591864e 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-enumaudio:
+.. _VIDIOC_ENUMAUDIO:
 
 **********************
 ioctl VIDIOC_ENUMAUDIO

@@ -39,7 +39,7 @@ structure or return an EINVAL error code when the index is out of
 bounds. To enumerate all audio inputs applications shall begin at index
 zero, incrementing by one until the driver returns EINVAL.
 
-See :ref:`vidioc-g-audio` for a description of struct
+See :ref:`VIDIOC_G_AUDIO` for a description of struct
 :ref:`v4l2_audio <v4l2-audio>`.
 
 

index 54157607d90d..29735eddac5d 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-enumaudioout:
+.. _VIDIOC_ENUMAUDIOOUT:
 
 ***********************
 ioctl VIDIOC_ENUMAUDOUT

@@ -42,7 +42,7 @@ zero, incrementing by one until the driver returns EINVAL.
 Note connectors on a TV card to loop back the received audio signal to a
 sound card are not audio outputs in this sense.
 
-See :ref:`vidioc-g-audioout` for a description of struct
+See :ref:`VIDIOC_G_AUDIOout` for a description of struct
 :ref:`v4l2_audioout <v4l2-audioout>`.
 
 

index 32c8dac7f400..644d50679aa2 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-enuminput:
+.. _VIDIOC_ENUMINPUT:
 
 **********************
 ioctl VIDIOC_ENUMINPUT

index 89cccda0ccaa..6ccb3d094dc8 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-enumoutput:
+.. _VIDIOC_ENUMOUTPUT:
 
 ***********************
 ioctl VIDIOC_ENUMOUTPUT

index d82c49028d83..d16a9494d03b 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-enumstd:
+.. _VIDIOC_ENUMSTD:
 
 ********************
 ioctl VIDIOC_ENUMSTD

index 0de48b945a01..a389cbc75970 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-expbuf:
+.. _VIDIOC_EXPBUF:
 
 *******************
 ioctl VIDIOC_EXPBUF

@@ -35,7 +35,7 @@ This ioctl is an extension to the :ref:`memory mapping <mmap>` I/O
 method, therefore it is available only for ``V4L2_MEMORY_MMAP`` buffers.
 It can be used to export a buffer as a DMABUF file at any time after
 buffers have been allocated with the
-:ref:`VIDIOC_REQBUFS <vidioc-reqbufs>` ioctl.
+:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl.
 
 To export a buffer, applications fill struct
 :ref:`v4l2_exportbuffer <v4l2-exportbuffer>`. The ``type`` field is

@@ -43,7 +43,7 @@ set to the same buffer type as was previously used with struct
 :ref:`v4l2_requestbuffers <v4l2-requestbuffers>` ``type``.
 Applications must also set the ``index`` field. Valid index numbers
 range from zero to the number of buffers allocated with
-:ref:`VIDIOC_REQBUFS <vidioc-reqbufs>` (struct
+:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` (struct
 :ref:`v4l2_requestbuffers <v4l2-requestbuffers>` ``count``) minus
 one. For the multi-planar API, applications set the ``plane`` field to
 the index of the plane to be exported. Valid planes range from zero to

@@ -142,8 +142,8 @@ Examples
        -  Number of the buffer, set by the application. This field is only
           used for :ref:`memory mapping <mmap>` I/O and can range from
           zero to the number of buffers allocated with the
-          :ref:`VIDIOC_REQBUFS <vidioc-reqbufs>` and/or
-          :ref:`VIDIOC_CREATE_BUFS <vidioc-create-bufs>` ioctls.
+          :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` and/or
+          :ref:`VIDIOC_CREATE_BUFS <VIDIOC_CREATE_BUFS>` ioctls.
 
     -  .. row 3
 

index 05df90f084e8..2a81d01a1c00 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-audio:
+.. _VIDIOC_G_AUDIO:
 
 ************************************
 ioctl VIDIOC_G_AUDIO, VIDIOC_S_AUDIO

index ef4dce35992e..1da1e7ad51a6 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-audioout:
+.. _VIDIOC_G_AUDIOOUT:
 
 **************************************
 ioctl VIDIOC_G_AUDOUT, VIDIOC_S_AUDOUT

index 35f70134ac81..457a6cc6b63e 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-crop:
+.. _VIDIOC_G_CROP:
 
 **********************************
 ioctl VIDIOC_G_CROP, VIDIOC_S_CROP

@@ -66,7 +66,7 @@ vertical scaling factor.
 Finally the driver programs the hardware with the actual cropping and
 image parameters. ``VIDIOC_S_CROP`` is a write-only ioctl, it does not
 return the actual parameters. To query them applications must call
-``VIDIOC_G_CROP`` and :ref:`VIDIOC_G_FMT <vidioc-g-fmt>`. When the
+``VIDIOC_G_CROP`` and :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`. When the
 parameters are unsuitable the application may modify the cropping or
 image parameters and repeat the cycle until satisfactory parameters have
 been negotiated.

index 6381d7c13d58..6b2b157ba9c7 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-ctrl:
+.. _VIDIOC_G_CTRL:
 
 **********************************
 ioctl VIDIOC_G_CTRL, VIDIOC_S_CTRL

@@ -48,9 +48,9 @@ actual new value. If the ``value`` is inappropriate for the control
 EINVAL error code is returned as well.
 
 These ioctls work only with user controls. For other control classes the
-:ref:`VIDIOC_G_EXT_CTRLS <vidioc-g-ext-ctrls>`,
-:ref:`VIDIOC_S_EXT_CTRLS <vidioc-g-ext-ctrls>` or
-:ref:`VIDIOC_TRY_EXT_CTRLS <vidioc-g-ext-ctrls>` must be used.
+:ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`,
+:ref:`VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` or
+:ref:`VIDIOC_TRY_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` must be used.
 
 
 .. _v4l2-control:

@@ -90,7 +90,7 @@ EINVAL
     The struct :ref:`v4l2_control <v4l2-control>` ``id`` is invalid
     or the ``value`` is inappropriate for the given control (i.e. if a
     menu item is selected that is not supported by the driver according
-    to :ref:`VIDIOC_QUERYMENU <vidioc-queryctrl>`).
+    to :ref:`VIDIOC_QUERYMENU <VIDIOC_QUERYCTRL>`).
 
 ERANGE
     The struct :ref:`v4l2_control <v4l2-control>` ``value`` is out of

index 19598b10d425..84f9db487822 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-dv-timings:
+.. _VIDIOC_G_DV_TIMINGS:
 
 **********************************************
 ioctl VIDIOC_G_DV_TIMINGS, VIDIOC_S_DV_TIMINGS

@@ -47,7 +47,7 @@ values are not correct, the driver returns EINVAL error code.
 The ``linux/v4l2-dv-timings.h`` header can be used to get the timings of
 the formats in the :ref:`cea861` and :ref:`vesadmt` standards. If
 the current input or output does not support DV timings (e.g. if
-:ref:`VIDIOC_ENUMINPUT <vidioc-enuminput>` does not set the
+:ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>` does not set the
 ``V4L2_IN_CAP_DV_TIMINGS`` flag), then ENODATA error code is returned.
 
 

index 3138cfe7a26e..26bbf060aa51 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-edid:
+.. _VIDIOC_G_EDID:
 
 ******************************************************************************
 ioctl VIDIOC_G_EDID, VIDIOC_S_EDID, VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID

@@ -44,8 +44,8 @@ with subdevice nodes (/dev/v4l-subdevX) or with video nodes
 
 When used with video nodes the ``pad`` field represents the input (for
 video capture devices) or output (for video output devices) index as is
-returned by :ref:`VIDIOC_ENUMINPUT <vidioc-enuminput>` and
-:ref:`VIDIOC_ENUMOUTPUT <vidioc-enumoutput>` respectively. When used
+returned by :ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>` and
+:ref:`VIDIOC_ENUMOUTPUT <VIDIOC_ENUMOUTPUT>` respectively. When used
 with subdevice nodes the ``pad`` field represents the input or output
 pad of the subdevice. If there is no EDID support for the given ``pad``
 value, then the EINVAL error code will be returned.

@@ -105,8 +105,8 @@ EDID is no longer available.
 
        -  Pad for which to get/set the EDID blocks. When used with a video
           device node the pad represents the input or output index as
-          returned by :ref:`VIDIOC_ENUMINPUT <vidioc-enuminput>` and
-          :ref:`VIDIOC_ENUMOUTPUT <vidioc-enumoutput>` respectively.
+          returned by :ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>` and
+          :ref:`VIDIOC_ENUMOUTPUT <VIDIOC_ENUMOUTPUT>` respectively.
 
     -  .. row 2
 

index 5edf9cb46d15..68af83d964f6 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-enc-index:
+.. _VIDIOC_G_ENC_INDEX:
 
 ************************
 ioctl VIDIOC_G_ENC_INDEX

index 66dce741a3c0..f800458d9dfe 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-ext-ctrls:
+.. _VIDIOC_G_EXT_CTRLS:
 
 ******************************************************************
 ioctl VIDIOC_G_EXT_CTRLS, VIDIOC_S_EXT_CTRLS, VIDIOC_TRY_EXT_CTRLS

@@ -58,14 +58,14 @@ set ``size`` to a valid value and return an ENOSPC error code. You
 should re-allocate the memory to this new size and try again. For the
 string type it is possible that the same issue occurs again if the
 string has grown in the meantime. It is recommended to call
-:ref:`VIDIOC_QUERYCTRL <vidioc-queryctrl>` first and use
+:ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` first and use
 ``maximum``\ +1 as the new ``size`` value. It is guaranteed that that is
 sufficient memory.
 
 N-dimensional arrays are set and retrieved row-by-row. You cannot set a
 partial array, all elements have to be set or retrieved. The total size
 is calculated as ``elems`` * ``elem_size``. These values can be obtained
-by calling :ref:`VIDIOC_QUERY_EXT_CTRL <vidioc-queryctrl>`.
+by calling :ref:`VIDIOC_QUERY_EXT_CTRL <VIDIOC_QUERYCTRL>`.
 
 To change the value of a set of controls applications initialize the
 ``id``, ``size``, ``reserved2`` and ``value/value64/string/ptr`` fields

@@ -366,8 +366,8 @@ still cause this situation.
 
        -  The class containing user controls. These controls are described
           in :ref:`control`. All controls that can be set using the
-          :ref:`VIDIOC_S_CTRL <vidioc-g-ctrl>` and
-          :ref:`VIDIOC_G_CTRL <vidioc-g-ctrl>` ioctl belong to this
+          :ref:`VIDIOC_S_CTRL <VIDIOC_G_CTRL>` and
+          :ref:`VIDIOC_G_CTRL <VIDIOC_G_CTRL>` ioctl belong to this
           class.
 
     -  .. row 2

index 499881e92a28..f4703b3449b3 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-fbuf:
+.. _VIDIOC_G_FBUF:
 
 **********************************
 ioctl VIDIOC_G_FBUF, VIDIOC_S_FBUF

@@ -39,7 +39,7 @@ to get and set the framebuffer parameters for a
 :ref:`Video Overlay <overlay>` or :ref:`Video Output Overlay <osd>`
 (OSD). The type of overlay is implied by the device type (capture or
 output device) and can be determined with the
-:ref:`VIDIOC_QUERYCAP <vidioc-querycap>` ioctl. One ``/dev/videoN``
+:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. One ``/dev/videoN``
 device must not support both kinds of overlay.
 
 The V4L2 API distinguishes destructive and non-destructive overlays. A

@@ -202,7 +202,7 @@ destructive video overlay.
 
        -  Drivers and applications shall ignore this field. If applicable,
           the field order is selected with the
-          :ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl, using the ``field``
+          :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, using the ``field``
           field of struct :ref:`v4l2_window <v4l2-window>`.
 
     -  .. row 13

@@ -396,12 +396,12 @@ destructive video overlay.
        -  If this flag is set for a video capture device, then the driver
           will set the initial overlay size to cover the full framebuffer
           size, otherwise the existing overlay size (as set by
-          :ref:`VIDIOC_S_FMT <vidioc-g-fmt>`) will be used. Only one
+          :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`) will be used. Only one
           video capture driver (bttv) supports this flag. The use of this
           flag for capture devices is deprecated. There is no way to detect
           which drivers support this flag, so the only reliable method of
           setting the overlay size is through
-          :ref:`VIDIOC_S_FMT <vidioc-g-fmt>`. If this flag is set for a
+          :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`. If this flag is set for a
           video output device, then the video output overlay window is
           relative to the top-left corner of the framebuffer and restricted
           to the size of the framebuffer. If it is cleared, then the video

@@ -415,14 +415,14 @@ destructive video overlay.
 
        -  Use chroma-keying. The chroma-key color is determined by the
           ``chromakey`` field of struct :ref:`v4l2_window <v4l2-window>`
-          and negotiated with the :ref:`VIDIOC_S_FMT <vidioc-g-fmt>`
+          and negotiated with the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
           ioctl, see :ref:`overlay` and :ref:`osd`.
 
     -  .. row 4
 
        -  :cspan:`2` There are no flags to enable clipping using a list of
           clip rectangles or a bitmap. These methods are negotiated with the
-          :ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl, see :ref:`overlay`
+          :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, see :ref:`overlay`
           and :ref:`osd`.
 
     -  .. row 5

@@ -447,7 +447,7 @@ destructive video overlay.
           + video pixel * (255 - alpha)) / 255. The alpha value is
           determined by the ``global_alpha`` field of struct
           :ref:`v4l2_window <v4l2-window>` and negotiated with the
-          :ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl, see :ref:`overlay`
+          :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, see :ref:`overlay`
           and :ref:`osd`.
 
     -  .. row 7

@@ -471,7 +471,7 @@ destructive video overlay.
        -  Use source chroma-keying. The source chroma-key color is
           determined by the ``chromakey`` field of struct
           :ref:`v4l2_window <v4l2-window>` and negotiated with the
-          :ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl, see :ref:`overlay`
+          :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, see :ref:`overlay`
           and :ref:`osd`. Both chroma-keying are mutual exclusive to each
           other, so same ``chromakey`` field of struct
           :ref:`v4l2_window <v4l2-window>` is being used.

index ed1daa32122b..1d392e6c538d 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-fmt:
+.. _VIDIOC_G_FMT:
 
 ************************************************
 ioctl VIDIOC_G_FMT, VIDIOC_S_FMT, VIDIOC_TRY_FMT

index 1d9f0fe86fb0..ce247577c3a0 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-frequency:
+.. _VIDIOC_G_FREQUENCY:
 
 ********************************************
 ioctl VIDIOC_G_FREQUENCY, VIDIOC_S_FREQUENCY

index fffba83242ed..62990976ff9b 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-input:
+.. _VIDIOC_G_INPUT:
 
 ************************************
 ioctl VIDIOC_G_INPUT, VIDIOC_S_INPUT

@@ -47,7 +47,7 @@ applications must select an input before querying or negotiating any
 other parameters.
 
 Information about video inputs is available using the
-:ref:`VIDIOC_ENUMINPUT <vidioc-enuminput>` ioctl.
+:ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>` ioctl.
 
 
 Return Value

index 05d4ebf221e2..acd05bf0d7b6 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-jpegcomp:
+.. _VIDIOC_G_JPEGCOMP:
 
 ******************************************
 ioctl VIDIOC_G_JPEGCOMP, VIDIOC_S_JPEGCOMP

index 3a8ae0a5891a..4399a13f94c1 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-modulator:
+.. _VIDIOC_G_MODULATOR:
 
 ********************************************
 ioctl VIDIOC_G_MODULATOR, VIDIOC_S_MODULATOR

@@ -57,7 +57,7 @@ initialized to zero. The term 'modulator' means SDR transmitter in this
 context.
 
 To change the radio frequency the
-:ref:`VIDIOC_S_FREQUENCY <vidioc-g-frequency>` ioctl is available.
+:ref:`VIDIOC_S_FREQUENCY <VIDIOC_G_FREQUENCY>` ioctl is available.
 
 
 .. _v4l2-modulator:

index 8341f1f8a45c..3b9ea56e3b9e 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-output:
+.. _VIDIOC_G_OUTPUT:
 
 **************************************
 ioctl VIDIOC_G_OUTPUT, VIDIOC_S_OUTPUT

@@ -48,7 +48,7 @@ effects applications must select an output before querying or
 negotiating any other parameters.
 
 Information about video outputs is available using the
-:ref:`VIDIOC_ENUMOUTPUT <vidioc-enumoutput>` ioctl.
+:ref:`VIDIOC_ENUMOUTPUT <VIDIOC_ENUMOUTPUT>` ioctl.
 
 
 Return Value

index 2892653b5bc4..07432d386356 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-parm:
+.. _VIDIOC_G_PARM:
 
 **********************************
 ioctl VIDIOC_G_PARM, VIDIOC_S_PARM

index 0706f2f85a79..ee80c9e0c7d4 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-priority:
+.. _VIDIOC_G_PRIORITY:
 
 ******************************************
 ioctl VIDIOC_G_PRIORITY, VIDIOC_S_PRIORITY

index 7846553dc4de..fd07c87a369c 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-selection:
+.. _VIDIOC_G_SELECTION:
 
 ********************************************
 ioctl VIDIOC_G_SELECTION, VIDIOC_S_SELECTION

index c76f5682ad0a..8c86d2b41a5b 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-sliced-vbi-cap:
+.. _VIDIOC_G_SLICED_VBI_CAP:
 
 *****************************
 ioctl VIDIOC_G_SLICED_VBI_CAP

@@ -134,7 +134,7 @@ to write-read, in Linux 2.6.19.
           given line may be limited. For example on PAL line 16 the hardware
           may be able to look for a VPS or Teletext signal, but not both at
           the same time. Applications can learn about these limits using the
-          :ref:`VIDIOC_S_FMT <vidioc-g-fmt>` ioctl as described in
+          :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl as described in
           :ref:`sliced`.
 
     -  .. row 10

index c01e8c1f51d0..9cbf2d2995c6 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-std:
+.. _VIDIOC_G_STD:
 
 ********************************
 ioctl VIDIOC_G_STD, VIDIOC_S_STD

@@ -48,7 +48,7 @@ no flags are given or the current input does not support the requested
 standard the driver returns an EINVAL error code. When the standard set
 is ambiguous drivers may return EINVAL or choose any of the requested
 standards. If the current input or output does not support standard
-video timings (e.g. if :ref:`VIDIOC_ENUMINPUT <vidioc-enuminput>`
+video timings (e.g. if :ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>`
 does not set the ``V4L2_IN_CAP_STD`` flag), then ENODATA error code is
 returned.
 

index d897f6862b9d..1ad5107a0ad5 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-g-tuner:
+.. _VIDIOC_G_TUNER:
 
 ************************************
 ioctl VIDIOC_G_TUNER, VIDIOC_S_TUNER

@@ -56,7 +56,7 @@ selected audio mode.
 to zero. The term 'tuner' means SDR receiver in this context.
 
 To change the radio frequency the
-:ref:`VIDIOC_S_FREQUENCY <vidioc-g-frequency>` ioctl is available.
+:ref:`VIDIOC_S_FREQUENCY <VIDIOC_G_FREQUENCY>` ioctl is available.
 
 
 .. _v4l2-tuner:

@@ -323,7 +323,7 @@ To change the radio frequency the
           determined from the frequency band.) The set of supported video
           standards is available from the struct
           :ref:`v4l2_input <v4l2-input>` pointing to this tuner, see the
-          description of ioctl :ref:`VIDIOC_ENUMINPUT <vidioc-enuminput>`
+          description of ioctl :ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>`
           for details. Only ``V4L2_TUNER_ANALOG_TV`` tuners can have this
           capability.
 

@@ -425,7 +425,7 @@ To change the radio frequency the
 
        -  0x0400
 
-       -  The :ref:`VIDIOC_ENUM_FREQ_BANDS <vidioc-enum-freq-bands>`
+       -  The :ref:`VIDIOC_ENUM_FREQ_BANDS <VIDIOC_ENUM_FREQ_BANDS>`
           ioctl can be used to enumerate the available frequency bands.
 
     -  .. row 13

@@ -436,7 +436,7 @@ To change the radio frequency the
 
        -  The range to search when using the hardware seek functionality is
           programmable, see
-          :ref:`VIDIOC_S_HW_FREQ_SEEK <vidioc-s-hw-freq-seek>` for
+          :ref:`VIDIOC_S_HW_FREQ_SEEK <VIDIOC_S_HW_FREQ_SEEK>` for
           details.
 
     -  .. row 14

index 0706274ff6a3..6df7c2fd5b6c 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-log-status:
+.. _VIDIOC_LOG_STATUS:
 
 ***********************
 ioctl VIDIOC_LOG_STATUS

index d82d24fd7fb2..e0373a9d6f14 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-overlay:
+.. _VIDIOC_OVERLAY:
 
 ********************
 ioctl VIDIOC_OVERLAY

@@ -36,8 +36,8 @@ Applications call ``VIDIOC_OVERLAY`` to start or stop the overlay. It
 takes a pointer to an integer which must be set to zero by the
 application to stop overlay, to one to start.
 
-Drivers do not support :ref:`VIDIOC_STREAMON <vidioc-streamon>` or
-:ref:`VIDIOC_STREAMOFF <vidioc-streamon>` with
+Drivers do not support :ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` or
+:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` with
 ``V4L2_BUF_TYPE_VIDEO_OVERLAY``.
 
 

index c29757f38066..fb3ac38b3db2 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-prepare-buf:
+.. _VIDIOC_PREPARE_BUF:
 
 ************************
 ioctl VIDIOC_PREPARE_BUF

index 6912780b0e3d..045fa53e0417 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-qbuf:
+.. _VIDIOC_QBUF:
 
 *******************************
 ioctl VIDIOC_QBUF, VIDIOC_DQBUF

@@ -42,10 +42,10 @@ previously used with struct :ref:`v4l2_format <v4l2-format>` ``type``
 and struct :ref:`v4l2_requestbuffers <v4l2-requestbuffers>` ``type``.
 Applications must also set the ``index`` field. Valid index numbers
 range from zero to the number of buffers allocated with
-:ref:`VIDIOC_REQBUFS <vidioc-reqbufs>` (struct
+:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` (struct
 :ref:`v4l2_requestbuffers <v4l2-requestbuffers>` ``count``) minus
 one. The contents of the struct :c:type:`struct v4l2_buffer` returned
-by a :ref:`VIDIOC_QUERYBUF <vidioc-querybuf>` ioctl will do as well.
+by a :ref:`VIDIOC_QUERYBUF <VIDIOC_QUERYBUF>` ioctl will do as well.
 When the buffer is intended for output (``type`` is
 ``V4L2_BUF_TYPE_VIDEO_OUTPUT``, ``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE``,
 or ``V4L2_BUF_TYPE_VBI_OUTPUT``) applications must also initialize the

@@ -75,8 +75,8 @@ the driver sets the ``V4L2_BUF_FLAG_QUEUED`` flag and clears the
 ``flags`` field, or it returns an error code. This ioctl locks the
 memory pages of the buffer in physical memory, they cannot be swapped
 out to disk. Buffers remain locked until dequeued, until the
-:ref:`VIDIOC_STREAMOFF <vidioc-streamon>` or
-:ref:`VIDIOC_REQBUFS <vidioc-reqbufs>` ioctl is called, or until the
+:ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` or
+:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl is called, or until the
 device is closed.
 
 To enqueue a :ref:`DMABUF <dmabuf>` buffer applications set the

@@ -91,8 +91,8 @@ sets the ``V4L2_BUF_FLAG_QUEUED`` flag and clears the
 buffer. Locking a buffer means passing it to a driver for a hardware
 access (usually DMA). If an application accesses (reads/writes) a locked
 buffer then the result is undefined. Buffers remain locked until
-dequeued, until the :ref:`VIDIOC_STREAMOFF <vidioc-streamon>` or
-:ref:`VIDIOC_REQBUFS <vidioc-reqbufs>` ioctl is called, or until the
+dequeued, until the :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` or
+:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl is called, or until the
 device is closed.
 
 Applications call the ``VIDIOC_DQBUF`` ioctl to dequeue a filled

index 567faa73e23b..88aedbd1fcae 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-query-dv-timings:
+.. _VIDIOC_QUERY_DV_TIMINGS:
 
 *****************************
 ioctl VIDIOC_QUERY_DV_TIMINGS

@@ -56,7 +56,7 @@ 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
 and returns ERANGE. In that case the application can call
-:ref:`VIDIOC_DV_TIMINGS_CAP <vidioc-dv-timings-cap>` to compare the
+:ref:`VIDIOC_DV_TIMINGS_CAP <VIDIOC_DV_TIMINGS_CAP>` to compare the
 found timings with the hardware's capabilities in order to give more
 precise feedback to the user.
 

index 092ed4586a18..baa3ad6591c7 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-querybuf:
+.. _VIDIOC_QUERYBUF:
 
 *********************
 ioctl VIDIOC_QUERYBUF

@@ -33,7 +33,7 @@ Description
 
 This ioctl is part of the :ref:`streaming <mmap>` I/O method. It can
 be used to query the status of a buffer at any time after buffers have
-been allocated with the :ref:`VIDIOC_REQBUFS <vidioc-reqbufs>` ioctl.
+been allocated with the :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl.
 
 Applications set the ``type`` field of a struct
 :ref:`v4l2_buffer <v4l2-buffer>` to the same buffer type as was

@@ -41,7 +41,7 @@ previously used with struct :ref:`v4l2_format <v4l2-format>` ``type``
 and struct :ref:`v4l2_requestbuffers <v4l2-requestbuffers>` ``type``,
 and the ``index`` field. Valid index numbers range from zero to the
 number of buffers allocated with
-:ref:`VIDIOC_REQBUFS <vidioc-reqbufs>` (struct
+:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` (struct
 :ref:`v4l2_requestbuffers <v4l2-requestbuffers>` ``count``) minus
 one. The ``reserved`` and ``reserved2`` fields must be set to 0. When
 using the :ref:`multi-planar API <planar-apis>`, the ``m.planes``

index 54f86443dfcc..3032a9ee1c6b 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _vidioc-querycap:
+.. _VIDIOC_QUERYCAP:
 
 *********************
 ioctl VIDIOC_QUERYCAP

@@ -308,7 +308,7 @@ specification the ioctl returns an EINVAL error code.
        -  0x00000400
 
[… more lines in the raw message]

Lines of this file are not shown. View the raw message.

index 116b69c1f818..7d38a51c4f73 100644

Lines of this file are not shown. View the raw message.

index 8e22ba4b9c99..1d825fff9d15 100644

Lines of this file are not shown. View the raw message.

index 621e3c1e054d..c17d3b0465d6 100644

Lines of this file are not shown. View the raw message.

index 72ae6ba6bada..19c2e0afd7de 100644

Lines of this file are not shown. View the raw message.

index 0f7f6e00a759..349204d81334 100644

Lines of this file are not shown. View the raw message.

index 87506d6b0e53..d9f27e32eb60 100644

Lines of this file are not shown. View the raw message.

index 7f867e2930be..49be2eefaa57 100644

Lines of this file are not shown. View the raw message.

index 97534457db6a..a9b0baba2633 100644

Lines of this file are not shown. View the raw message.

index e54a07c8ba1d..bef416cfe46c 100644

Lines of this file are not shown. View the raw message.

index 5dcbc03b4ffc..789277a2647a 100644

Lines of this file are not shown. View the raw message.

index af0918900f8a..bcc54e2e396f 100644

Lines of this file are not shown. View the raw message.

index 8e4c8e10494e..7b60c9b99aad 100644

Lines of this file are not shown. View the raw message.

index f12981c38f63..8d0e346461e9 100644

Lines of this file are not shown. View the raw message.

index f4effaab9a1a..a01cafad8d3c 100644
@@ -20,7 +20,7 @@ dishes were already legacy in 2004.
 SYNOPSIS
 
 int ioctl(int fd, int request =
-:ref:`FE_DISHNETWORK_SEND_LEGACY_CMD <FE_DISHNETWORK_SEND_LEGACY_CMD>`,
+:ref:`FE_DISHNETWORK_SEND_LEGACY_CMD`,
 unsigned long cmd);
 
 PARAMETERS

index 75eab893c184..8d1caedd2f97 100644
@@ -38,7 +38,7 @@ PARAMETERS
 
        -  int request
 
-       -  Equals :ref:`FE_GET_EVENT <FE_GET_EVENT>` for this command.
+       -  Equals :ref:`FE_GET_EVENT` for this command.
 
     -  .. row 3
 

index 30c85cf0423c..2e60b239d1da 100644
@@ -14,7 +14,7 @@ this command, read-only access to the device is sufficient.
 SYNOPSIS
 
 int ioctl(int fd, int request =
-:ref:`FE_GET_FRONTEND <FE_GET_FRONTEND>`, struct
+:ref:`FE_GET_FRONTEND`, struct
 dvb_frontend_parameters *p);
 
 PARAMETERS

@@ -36,7 +36,7 @@ PARAMETERS
 
        -  int request
 
-       -  Equals :ref:`FE_SET_FRONTEND <FE_SET_FRONTEND>` for this
+       -  Equals :ref:`FE_SET_FRONTEND` for this
           command.
 
     -  .. row 3

index e21451886dc2..935c0e50b0fd 100644
@@ -14,7 +14,7 @@ access to the device is sufficient.
 
 SYNOPSIS
 
-int ioctl(int fd, int request = :ref:`FE_READ_BER <FE_READ_BER>`,
+int ioctl(int fd, int request = :ref:`FE_READ_BER`,
 uint32_t *ber);
 
 PARAMETERS

@@ -36,7 +36,7 @@ PARAMETERS
 
        -  int request
 
-       -  Equals :ref:`FE_READ_BER <FE_READ_BER>` for this command.
+       -  Equals :ref:`FE_READ_BER` for this command.
 
     -  .. row 3
 

index 3e34bea21b6c..01180e20e4d4 100644
@@ -15,7 +15,7 @@ to the device is sufficient.
 SYNOPSIS
 
 int ioctl( int fd, int request =
-:ref:`FE_READ_SIGNAL_STRENGTH <FE_READ_SIGNAL_STRENGTH>`,
+:ref:`FE_READ_SIGNAL_STRENGTH`,
 uint16_t *strength);
 
 PARAMETERS

@@ -38,7 +38,7 @@ PARAMETERS
        -  int request
 
        -  Equals
-          :ref:`FE_READ_SIGNAL_STRENGTH <FE_READ_SIGNAL_STRENGTH>`
+          :ref:`FE_READ_SIGNAL_STRENGTH`
           for this command.
 
     -  .. row 3

index b8a639706e9e..0ccc7d71d8a4 100644
@@ -14,7 +14,7 @@ to the device is sufficient.
 
 SYNOPSIS
 
-int ioctl(int fd, int request = :ref:`FE_READ_SNR <FE_READ_SNR>`,
+int ioctl(int fd, int request = :ref:`FE_READ_SNR`,
 uint16_t *snr);
 
 PARAMETERS

@@ -36,7 +36,7 @@ PARAMETERS
 
        -  int request
 
-       -  Equals :ref:`FE_READ_SNR <FE_READ_SNR>` for this command.
+       -  Equals :ref:`FE_READ_SNR` for this command.
 
     -  .. row 3
 

index 261eb20ddadf..3827c7b953e1 100644
@@ -17,7 +17,7 @@ sufficient.
 SYNOPSIS
 
 int ioctl( int fd, int request =
-:ref:`FE_READ_UNCORRECTED_BLOCKS <FE_READ_UNCORRECTED_BLOCKS>`,
+:ref:`FE_READ_UNCORRECTED_BLOCKS`,
 uint32_t *ublocks);
 
 PARAMETERS

@@ -40,7 +40,7 @@ PARAMETERS
        -  int request
 
        -  Equals
-          :ref:`FE_READ_UNCORRECTED_BLOCKS <FE_READ_UNCORRECTED_BLOCKS>`
+          :ref:`FE_READ_UNCORRECTED_BLOCKS`
           for this command.
 
     -  .. row 3

index 885f9e3ceb59..f18e12cb3dff 100644
@@ -12,8 +12,8 @@ This ioctl call starts a tuning operation using specified parameters.
 The result of this call will be successful if the parameters were valid
 and the tuning could be initiated. The result of the tuning operation in
 itself, however, will arrive asynchronously as an event (see
-documentation for :ref:`FE_GET_EVENT <FE_GET_EVENT>` and
-FrontendEvent.) If a new :ref:`FE_SET_FRONTEND <FE_SET_FRONTEND>`
+documentation for :ref:`FE_GET_EVENT` and
+FrontendEvent.) If a new :ref:`FE_SET_FRONTEND`
 operation is initiated before the previous one was completed, the
 previous operation will be aborted in favor of the new one. This command
 requires read/write access to the device.

@@ -21,7 +21,7 @@ requires read/write access to the device.
 SYNOPSIS
 
 int ioctl(int fd, int request =
-:ref:`FE_SET_FRONTEND <FE_SET_FRONTEND>`, struct
+:ref:`FE_SET_FRONTEND`, struct
 dvb_frontend_parameters *p);
 
 PARAMETERS

@@ -43,7 +43,7 @@ PARAMETERS
 
        -  int request
 
-       -  Equals :ref:`FE_SET_FRONTEND <FE_SET_FRONTEND>` for this
+       -  Equals :ref:`FE_SET_FRONTEND` for this
           command.
 
     -  .. row 3

index d1a5b5970b71..a68149e16116 100644
@@ -456,7 +456,7 @@ AUDIO_SET_MUTE
 DESCRIPTION
 
 This ioctl is for DVB devices only. To control a V4L2 decoder use the
-V4L2 :ref:`VIDIOC_DECODER_CMD <VIDIOC_DECODER_CMD>` with the
+V4L2 :ref:`VIDIOC_DECODER_CMD` with the
 ``V4L2_DEC_CMD_START_MUTE_AUDIO`` flag instead.
 
 This ioctl call asks the audio device to mute the stream that is

index 12d8749e9e05..e36cd134007e 100644
@@ -12,10 +12,10 @@ tuner lock status and provide statistics about the quality of the
 signal.
 
 The information about the frontend tuner locking status can be queried
-using :ref:`FE_READ_STATUS <FE_READ_STATUS>`.
+using :ref:`FE_READ_STATUS`.
 
 Signal statistics are provided via
-:ref:`FE_GET_PROPERTY <FE_GET_PROPERTY>`. Please note that several
+:ref:`FE_GET_PROPERTY`. Please note that several
 statistics require the demodulator to be fully locked (e. g. with
 FE_HAS_LOCK bit set). See
 :ref:`Frontend statistics indicators <frontend-stat-properties>` for

index 36461d65a661..7f3999db3e5d 100644
@@ -234,7 +234,7 @@ measurement was taken.
 
 It can be used to calculate the PER indicator, by dividing
 :ref:`DTV_STAT_ERROR_BLOCK_COUNT <DTV-STAT-ERROR-BLOCK-COUNT>` by
-:ref:`DTV-STAT-TOTAL-BLOCK-COUNT <DTV-STAT-TOTAL-BLOCK-COUNT>`.
+:ref:`DTV-STAT-TOTAL-BLOCK-COUNT`.
 
 Possible scales for this metric are:
 

index 676ae922338d..91ac9ef8c356 100644
@@ -49,7 +49,7 @@ Description
 This system call opens a named frontend device
 (``/dev/dvb/adapter?/frontend?``) for subsequent use. Usually the first
 thing to do after a successful open is to find out the frontend type
-with :ref:`FE_GET_INFO <FE_GET_INFO>`.
+with :ref:`FE_GET_INFO`.
 
 The device can be opened in read-only mode, which only allows monitoring
 of device status and statistics, or read/write mode, which allows any

index 4a4fd5af6e0f..a3da1b8376bc 100644
@@ -8,7 +8,7 @@ Querying frontend information
 
 Usually, the first thing to do when the frontend is opened is to check
 the frontend capabilities. This is done using
-:ref:`FE_GET_INFO <FE_GET_INFO>`. This ioctl will enumerate the
+:ref:`FE_GET_INFO`. This ioctl will enumerate the
 DVB API version and other characteristics about the frontend, and can be
 opened either in read only or read/write mode.
 

index 98c90dcdb587..78917bdf51ed 100644
@@ -239,7 +239,7 @@ VIDEO_STOP
 DESCRIPTION
 
 This ioctl is for DVB devices only. To control a V4L2 decoder use the
-V4L2 :ref:`VIDIOC_DECODER_CMD <VIDIOC_DECODER_CMD>` instead.
+V4L2 :ref:`VIDIOC_DECODER_CMD` instead.
 
 This ioctl call asks the Video Device to stop playing the current
 stream. Depending on the input parameter, the screen can be blanked out

@@ -302,7 +302,7 @@ VIDEO_PLAY
 DESCRIPTION
 
 This ioctl is for DVB devices only. To control a V4L2 decoder use the
-V4L2 :ref:`VIDIOC_DECODER_CMD <VIDIOC_DECODER_CMD>` instead.
+V4L2 :ref:`VIDIOC_DECODER_CMD` instead.
 
 This ioctl call asks the Video Device to start playing a video stream
 from the selected source.

@@ -348,7 +348,7 @@ VIDEO_FREEZE
 DESCRIPTION
 
 This ioctl is for DVB devices only. To control a V4L2 decoder use the
-V4L2 :ref:`VIDIOC_DECODER_CMD <VIDIOC_DECODER_CMD>` instead.
+V4L2 :ref:`VIDIOC_DECODER_CMD` instead.
 
 This ioctl call suspends the live video stream being played. Decoding
 and playing are frozen. It is then possible to restart the decoding and

@@ -398,7 +398,7 @@ VIDEO_CONTINUE
 DESCRIPTION
 
 This ioctl is for DVB devices only. To control a V4L2 decoder use the
-V4L2 :ref:`VIDIOC_DECODER_CMD <VIDIOC_DECODER_CMD>` instead.
+V4L2 :ref:`VIDIOC_DECODER_CMD` instead.
 
 This ioctl call restarts decoding and playing processes of the video
 stream which was played before a call to VIDEO_FREEZE was made.

@@ -763,7 +763,7 @@ VIDEO_GET_EVENT
 DESCRIPTION
 
 This ioctl is for DVB devices only. To get events from a V4L2 decoder
-use the V4L2 :ref:`VIDIOC_DQEVENT <VIDIOC_DQEVENT>` ioctl instead.
+use the V4L2 :ref:`VIDIOC_DQEVENT` ioctl instead.
 
 This ioctl call returns an event of type video_event if available. If
 an event is not available, the behavior depends on whether the device is

@@ -844,11 +844,11 @@ DESCRIPTION
 
 This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders
 this ioctl has been replaced by the
-:ref:`VIDIOC_DECODER_CMD <VIDIOC_DECODER_CMD>` ioctl.
+:ref:`VIDIOC_DECODER_CMD` ioctl.
 
 This ioctl commands the decoder. The ``video_command`` struct is a
 subset of the ``v4l2_decoder_cmd`` struct, so refer to the
-:ref:`VIDIOC_DECODER_CMD <VIDIOC_DECODER_CMD>` documentation for
+:ref:`VIDIOC_DECODER_CMD` documentation for
 more information.
 
 SYNOPSIS

index bc50afca95fc..4faf9042f612 100644
@@ -16,14 +16,14 @@ applications and automatically regain control of the device at a later
 time.
 
 Since these features cannot be implemented entirely in user space V4L2
-defines the :ref:`VIDIOC_G_PRIORITY <VIDIOC_G_PRIORITY>` and
+defines the :ref:`VIDIOC_G_PRIORITY` and
 :ref:`VIDIOC_S_PRIORITY <VIDIOC_G_PRIORITY>` ioctls to request and
 query the access priority associate with a file descriptor. Opening a
 device assigns a medium priority, compatible with earlier versions of
 V4L2 and drivers not supporting these ioctls. Applications requiring a
 different priority will usually call :ref:`VIDIOC_S_PRIORITY
 <VIDIOC_G_PRIORITY>` after verifying the device with the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl.
+:ref:`VIDIOC_QUERYCAP` ioctl.
 
 Ioctls changing driver properties, such as
 :ref:`VIDIOC_S_INPUT <VIDIOC_G_INPUT>`, return an EBUSY error code

index fa6bf5ad8d32..21db1b97b83c 100644
@@ -27,18 +27,18 @@ number, starting at zero, of one audio input or output.
 
 To learn about the number and attributes of the available inputs and
 outputs applications can enumerate them with the
-:ref:`VIDIOC_ENUMAUDIO <VIDIOC_ENUMAUDIO>` and
+:ref:`VIDIOC_ENUMAUDIO` and
 :ref:`VIDIOC_ENUMAUDOUT <VIDIOC_ENUMAUDIOout>` ioctl, respectively.
 The struct :ref:`v4l2_audio <v4l2-audio>` returned by the
-:ref:`VIDIOC_ENUMAUDIO <VIDIOC_ENUMAUDIO>` ioctl also contains signal
+:ref:`VIDIOC_ENUMAUDIO` ioctl also contains signal
 :status information applicable when the current audio input is queried.
 
-The :ref:`VIDIOC_G_AUDIO <VIDIOC_G_AUDIO>` and
+The :ref:`VIDIOC_G_AUDIO` and
 :ref:`VIDIOC_G_AUDOUT <VIDIOC_G_AUDIOout>` ioctls report the current
 audio input and output, respectively. Note that, unlike
-:ref:`VIDIOC_G_INPUT <VIDIOC_G_INPUT>` and
-:ref:`VIDIOC_G_OUTPUT <VIDIOC_G_OUTPUT>` these ioctls return a
-structure as :ref:`VIDIOC_ENUMAUDIO <VIDIOC_ENUMAUDIO>` and
+:ref:`VIDIOC_G_INPUT` and
+:ref:`VIDIOC_G_OUTPUT` these ioctls return a
+structure as :ref:`VIDIOC_ENUMAUDIO` and
 :ref:`VIDIOC_ENUMAUDOUT <VIDIOC_ENUMAUDIOout>` do, not just an index.
 
 To select an audio input and change its properties applications call the

@@ -51,7 +51,7 @@ multiple selectable audio inputs, all audio output ioctls when the
 device has multiple selectable audio outputs. When the device has any
 audio inputs or outputs the driver must set the ``V4L2_CAP_AUDIO`` flag
 in the struct :ref:`v4l2_capability <v4l2-capability>` returned by
-the :ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl.
+the :ref:`VIDIOC_QUERYCAP` ioctl.
 
 
 .. code-block:: c

index 7d96ab74500f..374e9ba6b4bb 100644
@@ -12,8 +12,8 @@ planes, while the buffer structure acts as a container for the planes.
 Only pointers to buffers (planes) are exchanged, the data itself is not
 copied. These pointers, together with meta-information like timestamps
 or field parity, are stored in a struct :c:type:`struct v4l2_buffer`,
-argument to the :ref:`VIDIOC_QUERYBUF <VIDIOC_QUERYBUF>`,
-:ref:`VIDIOC_QBUF <VIDIOC_QBUF>` and
+argument to the :ref:`VIDIOC_QUERYBUF`,
+:ref:`VIDIOC_QBUF` and
 :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. In the multi-planar API,
 some plane-specific members of struct :c:type:`struct v4l2_buffer`,
 such as pointers and sizes for each plane, are stored in struct

@@ -52,10 +52,10 @@ buffer.
        -  Number of the buffer, set by the application except when calling
           :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>`, then it is set by the
           driver. This field can range from zero to the number of buffers
-          allocated with the :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl
+          allocated with the :ref:`VIDIOC_REQBUFS` ioctl
           (struct :ref:`v4l2_requestbuffers <v4l2-requestbuffers>`
           ``count``), plus any buffers allocated with
-          :ref:`VIDIOC_CREATE_BUFS <VIDIOC_CREATE_BUFS>` minus one.
+          :ref:`VIDIOC_CREATE_BUFS` minus one.
 
     -  .. row 2
 

@@ -243,8 +243,8 @@ buffer.
        -  
        -  Size of the buffer (not the payload) in bytes for the
           single-planar API. This is set by the driver based on the calls to
-          :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` and/or
-          :ref:`VIDIOC_CREATE_BUFS <VIDIOC_CREATE_BUFS>`. For the
+          :ref:`VIDIOC_REQBUFS` and/or
+          :ref:`VIDIOC_CREATE_BUFS`. For the
           multi-planar API the application sets this to the number of
           elements in the ``planes`` array. The driver will fill in the
           actual number of valid elements in that array.

@@ -303,8 +303,8 @@ buffer.
        -  
        -  Size in bytes of the plane (not its payload). This is set by the
           driver based on the calls to
-          :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` and/or
-          :ref:`VIDIOC_CREATE_BUFS <VIDIOC_CREATE_BUFS>`.
+          :ref:`VIDIOC_REQBUFS` and/or
+          :ref:`VIDIOC_CREATE_BUFS`.
 
     -  .. row 3
 

@@ -506,8 +506,8 @@ buffer.
        -  The buffer resides in device memory and has been mapped into the
           application's address space, see :ref:`mmap` for details.
           Drivers set or clear this flag when the
-          :ref:`VIDIOC_QUERYBUF <VIDIOC_QUERYBUF>`,
-          :ref:`VIDIOC_QBUF <VIDIOC_QBUF>` or
+          :ref:`VIDIOC_QUERYBUF`,
+          :ref:`VIDIOC_QBUF` or
           :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl is called. Set by the
           driver.
 

@@ -609,9 +609,9 @@ buffer.
 
        -  The buffer has been prepared for I/O and can be queued by the
           application. Drivers set or clear this flag when the
-          :ref:`VIDIOC_QUERYBUF <VIDIOC_QUERYBUF>`,
+          :ref:`VIDIOC_QUERYBUF`,
           :ref:`VIDIOC_PREPARE_BUF <VIDIOC_QBUF>`,
-          :ref:`VIDIOC_QBUF <VIDIOC_QBUF>` or
+          :ref:`VIDIOC_QBUF` or
           :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl is called.
 
     -  .. row 10

@@ -645,7 +645,7 @@ buffer.
 
        -  Last buffer produced by the hardware. mem2mem codec drivers set
           this flag on the capture queue for the last buffer when the
-          :ref:`VIDIOC_QUERYBUF <VIDIOC_QUERYBUF>` or
+          :ref:`VIDIOC_QUERYBUF` or
           :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl is called. Due to
           hardware limitations, the last buffer may be empty. In this case
           the driver will set the ``bytesused`` field to 0, regardless of

index 3e5c650707ae..02bd455a2616 100644
@@ -47,7 +47,7 @@ changed or generally never without application request.
 
 V4L2 specifies an event mechanism to notify applications when controls
 change value (see
-:ref:`VIDIOC_SUBSCRIBE_EVENT <VIDIOC_SUBSCRIBE_EVENT>`, event
+:ref:`VIDIOC_SUBSCRIBE_EVENT`, event
 ``V4L2_EVENT_CTRL``), panel applications might want to make use of that
 in order to always reflect the correct control value.
 

@@ -362,9 +362,9 @@ Control IDs
     and version, see :ref:`querycap`.
 
 Applications can enumerate the available controls with the
-:ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` and
+:ref:`VIDIOC_QUERYCTRL` and
 :ref:`VIDIOC_QUERYMENU <VIDIOC_QUERYCTRL>` ioctls, get and set a
-control value with the :ref:`VIDIOC_G_CTRL <VIDIOC_G_CTRL>` and
+control value with the :ref:`VIDIOC_G_CTRL` and
 :ref:`VIDIOC_S_CTRL <VIDIOC_G_CTRL>` ioctls. Drivers must implement
 ``VIDIOC_QUERYCTRL``, ``VIDIOC_G_CTRL`` and ``VIDIOC_S_CTRL`` when the
 device has one or more controls, ``VIDIOC_QUERYMENU`` when it has one or

@@ -522,7 +522,7 @@ more menu type controls.
    the real IDs.
 
    Many applications today still use the ``V4L2_CID_PRIVATE_BASE`` IDs
-   instead of using :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` with
+   instead of using :ref:`VIDIOC_QUERYCTRL` with
    the ``V4L2_CTRL_FLAG_NEXT_CTRL`` flag to enumerate all IDs, so
    support for ``V4L2_CID_PRIVATE_BASE`` is still around.
 

index 94f2d0e77ed8..41a5efaaa679 100644
@@ -14,8 +14,8 @@ offset into a video signal.
 
 Applications can use the following API to select an area in the video
 signal, query the default area and the hardware limits. *Despite their
-name, the :ref:`VIDIOC_CROPCAP <VIDIOC_CROPCAP>`,
-:ref:`VIDIOC_G_CROP <VIDIOC_G_CROP>` and
+name, the :ref:`VIDIOC_CROPCAP`,
+:ref:`VIDIOC_G_CROP` and
 :ref:`VIDIOC_S_CROP <VIDIOC_G_CROP>` ioctls apply to input as well
 as output devices.*
 

@@ -23,7 +23,7 @@ Scaling requires a source and a target. On a video capture or overlay
 device the source is the video signal, and the cropping ioctls determine
 the area actually sampled. The target are images read by the application
 or overlaid onto the graphics screen. Their size (and position for an
-overlay) is negotiated with the :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`
+overlay) is negotiated with the :ref:`VIDIOC_G_FMT`
 and :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctls.
 
 On a video output device the source are the images passed in by the

index fd6357c995aa..eb5c1522905d 100644
@@ -25,7 +25,7 @@ Devices supporting the video capture interface set the
 ``V4L2_CAP_VIDEO_CAPTURE`` or ``V4L2_CAP_VIDEO_CAPTURE_MPLANE`` flag in
 the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. As secondary device
+:ref:`VIDIOC_QUERYCAP` ioctl. As secondary device
 functions they may also support the :ref:`video overlay <overlay>`
 (``V4L2_CAP_VIDEO_OVERLAY``) and the :ref:`raw VBI capture <raw-vbi>`
 (``V4L2_CAP_VBI_CAPTURE``) interface. At least one of the read/write or

@@ -37,7 +37,7 @@ Supplemental Functions
 ======================
 
 Video capture devices shall support :ref:`audio input <audio>`,
-:ref:`tuner <tuner>`, :ref:`controls <control>`,
+:ref:`tuner`, :ref:`controls <control>`,
 :ref:`cropping and scaling <crop>` and
 :ref:`streaming parameter <streaming-par>` ioctls as needed. The
 :ref:`video input <video>` and :ref:`video standard <standard>`

@@ -65,7 +65,7 @@ To query the current image format applications set the ``type`` field of
 a struct :ref:`v4l2_format <v4l2-format>` to
 ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` or
 ``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE`` and call the
-:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` ioctl with a pointer to this
+:ref:`VIDIOC_G_FMT` ioctl with a pointer to this
 structure. Drivers fill the struct
 :ref:`v4l2_pix_format <v4l2-pix-format>` ``pix`` or the struct
 :ref:`v4l2_pix_format_mplane <v4l2-pix-format-mplane>` ``pix_mp``

index 1540755b1735..170954acc049 100644
@@ -15,7 +15,7 @@ A memory-to-memory video node acts just like a normal video node, but it
 supports both output (sending frames from memory to the codec hardware)
 and capture (receiving the processed frames from the codec hardware into
 memory) stream I/O. An application will have to setup the stream I/O for
-both sides and finally call :ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>`
+both sides and finally call :ref:`VIDIOC_STREAMON`
 for both capture and output to start the codec.
 
 Video compression codecs use the MPEG controls to setup their codec

index 5d21c6873b1a..385a8a342903 100644
@@ -14,9 +14,9 @@ events.
 
 To receive events, the events the user is interested in first must be
 subscribed using the
-:ref:`VIDIOC_SUBSCRIBE_EVENT <VIDIOC_SUBSCRIBE_EVENT>` ioctl. Once
+:ref:`VIDIOC_SUBSCRIBE_EVENT` ioctl. Once
 an event is subscribed, the events of subscribed types are dequeueable
-using the :ref:`VIDIOC_DQEVENT <VIDIOC_DQEVENT>` ioctl. Events may be
+using the :ref:`VIDIOC_DQEVENT` ioctl. Events may be
 unsubscribed using VIDIOC_UNSUBSCRIBE_EVENT ioctl. The special event
 type V4L2_EVENT_ALL may be used to unsubscribe all the events the
 driver supports.

index 93fb8f309091..27d2cfbf3d9c 100644
@@ -26,7 +26,7 @@ Querying Capabilities
 Devices supporting the *Video Output Overlay* interface set the
 ``V4L2_CAP_VIDEO_OUTPUT_OVERLAY`` flag in the ``capabilities`` field of
 struct :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl.
+:ref:`VIDIOC_QUERYCAP` ioctl.
 
 
 Framebuffer

@@ -36,7 +36,7 @@ Contrary to the *Video Overlay* interface the framebuffer is normally
 implemented on the TV card and not the graphics card. On Linux it is
 accessible as a framebuffer device (``/dev/fbN``). Given a V4L2 device,
 applications can find the corresponding framebuffer device by calling
-the :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` ioctl. It returns, amongst
+the :ref:`VIDIOC_G_FBUF` ioctl. It returns, amongst
 other information, the physical address of the framebuffer in the
 ``base`` field of struct :ref:`v4l2_framebuffer <v4l2-framebuffer>`.
 The framebuffer device ioctl ``FBIOGET_FSCREENINFO`` returns the same

@@ -115,7 +115,7 @@ clipping/blending method to be used for the overlay. To get the current
 parameters applications set the ``type`` field of a struct
 :ref:`v4l2_format <v4l2-format>` to
 ``V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY`` and call the
-:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` ioctl. The driver fills the
+:ref:`VIDIOC_G_FMT` ioctl. The driver fills the
 :c:type:`struct v4l2_window` substructure named ``win``. It is not
 possible to retrieve a previously programmed clipping list or bitmap.
 

index 3efbbcc3c093..1ca0e5873a86 100644
@@ -24,7 +24,7 @@ Devices supporting the video output interface set the
 ``V4L2_CAP_VIDEO_OUTPUT`` or ``V4L2_CAP_VIDEO_OUTPUT_MPLANE`` flag in
 the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. As secondary device
+:ref:`VIDIOC_QUERYCAP` ioctl. As secondary device
 functions they may also support the :ref:`raw VBI output <raw-vbi>`
 (``V4L2_CAP_VBI_OUTPUT``) interface. At least one of the read/write or
 streaming I/O methods must be supported. Modulators and audio outputs

@@ -62,7 +62,7 @@ defaults. An example is given in :ref:`crop`.
 To query the current image format applications set the ``type`` field of
 a struct :ref:`v4l2_format <v4l2-format>` to
 ``V4L2_BUF_TYPE_VIDEO_OUTPUT`` or ``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE``
-and call the :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` ioctl with a pointer
+and call the :ref:`VIDIOC_G_FMT` ioctl with a pointer
 to this structure. Drivers fill the struct
 :ref:`v4l2_pix_format <v4l2-pix-format>` ``pix`` or the struct
 :ref:`v4l2_pix_format_mplane <v4l2-pix-format-mplane>` ``pix_mp``

index 8a81e19a5d7c..acbcfb4cbe57 100644
@@ -41,7 +41,7 @@ Querying Capabilities
 Devices supporting the video overlay interface set the
 ``V4L2_CAP_VIDEO_OVERLAY`` flag in the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. The overlay I/O
+:ref:`VIDIOC_QUERYCAP` ioctl. The overlay I/O
 method specified below must be supported. Tuners and audio inputs are
 optional.
 

@@ -50,7 +50,7 @@ Supplemental Functions
 ======================
 
 Video overlay devices shall support :ref:`audio input <audio>`,
-:ref:`tuner <tuner>`, :ref:`controls <control>`,
+:ref:`tuner`, :ref:`controls <control>`,
 :ref:`cropping and scaling <crop>` and
 :ref:`streaming parameter <streaming-par>` ioctls as needed. The
 :ref:`video input <video>` and :ref:`video standard <standard>`

@@ -63,7 +63,7 @@ Setup
 Before overlay can commence applications must program the driver with
 frame buffer parameters, namely the address and size of the frame buffer
 and the image format, for example RGB 5:6:5. The
-:ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` and
+:ref:`VIDIOC_G_FBUF` and
 :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>` ioctls are available to get and
 set these parameters, respectively. The ``VIDIOC_S_FBUF`` ioctl is
 privileged because it allows to set up DMA into physical memory,

@@ -121,7 +121,7 @@ its position over the graphics surface and the clipping to be applied.
 To get the current parameters applications set the ``type`` field of a
 struct :ref:`v4l2_format <v4l2-format>` to
 ``V4L2_BUF_TYPE_VIDEO_OVERLAY`` and call the
-:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` ioctl. The driver fills the
+:ref:`VIDIOC_G_FMT` ioctl. The driver fills the
 :c:type:`struct v4l2_window` substructure named ``win``. It is not
 possible to retrieve a previously programmed clipping list or bitmap.
 

@@ -179,7 +179,7 @@ struct v4l2_window
 
 ``struct v4l2_clip * clips``
     When chroma-keying has *not* been negotiated and
-    :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` indicated this capability,
+    :ref:`VIDIOC_G_FBUF` indicated this capability,
     applications can set this field to point to an array of clipping
     rectangles.
 

@@ -204,7 +204,7 @@ are undefined.
 
 ``void * bitmap``
     When chroma-keying has *not* been negotiated and
-    :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` indicated this capability,
+    :ref:`VIDIOC_G_FBUF` indicated this capability,
     applications can set this field to point to a clipping bit mask.
 
 It must be of the same size as the window, ``w.width`` and ``w.height``.

@@ -289,7 +289,7 @@ Enabling Overlay
 ================
 
 To start or stop the frame buffer overlay applications call the
-:ref:`VIDIOC_OVERLAY <VIDIOC_OVERLAY>` ioctl.
+:ref:`VIDIOC_OVERLAY` ioctl.
 
 .. [1]
    A common application of two file descriptors is the XFree86

index 955173aaf48e..7a0d25a143a6 100644
@@ -21,7 +21,7 @@ Devices supporting the radio interface set the ``V4L2_CAP_RADIO`` and
 ``V4L2_CAP_TUNER`` or ``V4L2_CAP_MODULATOR`` flag in the
 ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. Other combinations of
+:ref:`VIDIOC_QUERYCAP` ioctl. Other combinations of
 capability flags are reserved for future extensions.
 
 

@@ -47,8 +47,8 @@ discussed in :ref:`tuner`) with index number zero to select the radio
 frequency and to determine if a monaural or FM stereo program is
 received/emitted. Drivers switch automatically between AM and FM
 depending on the selected frequency. The
-:ref:`VIDIOC_G_TUNER <VIDIOC_G_TUNER>` or
-:ref:`VIDIOC_G_MODULATOR <VIDIOC_G_MODULATOR>` ioctl reports the
+:ref:`VIDIOC_G_TUNER` or
+:ref:`VIDIOC_G_MODULATOR` ioctl reports the
 supported frequency range.
 
 

index 883ac4fbaeb6..ca61dde3ad38 100644
@@ -40,7 +40,7 @@ Devices supporting the raw VBI capturing or output API set the
 ``V4L2_CAP_VBI_CAPTURE`` or ``V4L2_CAP_VBI_OUTPUT`` flags, respectively,
 in the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. At least one of the
+:ref:`VIDIOC_QUERYCAP` ioctl. At least one of the
 read/write, streaming or asynchronous I/O methods must be supported. VBI
 devices may or may not have a tuner or modulator.
 

@@ -71,7 +71,7 @@ parameters and then checking if the actual parameters are suitable.
 To query the current raw VBI capture parameters applications set the
 ``type`` field of a struct :ref:`v4l2_format <v4l2-format>` to
 ``V4L2_BUF_TYPE_VBI_CAPTURE`` or ``V4L2_BUF_TYPE_VBI_OUTPUT``, and call
-the :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` ioctl with a pointer to this
+the :ref:`VIDIOC_G_FMT` ioctl with a pointer to this
 structure. Drivers fill the struct
 :ref:`v4l2_vbi_format <v4l2-vbi-format>` ``vbi`` member of the
 ``fmt`` union.

@@ -91,7 +91,7 @@ happen for instance when the video and VBI areas to capture would
 overlap, or when the driver supports multiple opens and another process
 already requested VBI capturing or output. Anyway, applications must
 expect other resource allocation points which may return EBUSY, at the
-:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` ioctl and the first read(),
+:ref:`VIDIOC_STREAMON` ioctl and the first read(),
 write() and select() call.
 
 VBI devices must implement both the ``VIDIOC_G_FMT`` and

@@ -339,7 +339,7 @@ A VBI device may support :ref:`read/write <rw>` and/or streaming
 The latter bears the possibility of synchronizing video and VBI data by
 using buffer timestamps.
 
-Remember the :ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` ioctl and the
+Remember the :ref:`VIDIOC_STREAMON` ioctl and the
 first read(), write() and select() call can be resource allocation
 points returning an EBUSY error code if the required hardware resources
 are temporarily unavailable, for example the device is already in use by

index af20f8fa1cdf..223df4971405 100644
@@ -33,7 +33,7 @@ Querying Capabilities
 Devices supporting the RDS capturing API set the
 ``V4L2_CAP_RDS_CAPTURE`` flag in the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. Any tuner that
+:ref:`VIDIOC_QUERYCAP` ioctl. Any tuner that
 supports RDS will set the ``V4L2_TUNER_CAP_RDS`` flag in the
 ``capability`` field of struct :ref:`v4l2_tuner <v4l2-tuner>`. If the
 driver only passes RDS blocks without interpreting the data the

@@ -52,7 +52,7 @@ Whether an RDS signal is present can be detected by looking at the
 Devices supporting the RDS output API set the ``V4L2_CAP_RDS_OUTPUT``
 flag in the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. Any modulator that
+:ref:`VIDIOC_QUERYCAP` ioctl. Any modulator that
 supports RDS will set the ``V4L2_TUNER_CAP_RDS`` flag in the
 ``capability`` field of struct
 :ref:`v4l2_modulator <v4l2-modulator>`. In order to enable the RDS

index 5e4f7030f644..0cae31c93dd0 100644
@@ -22,7 +22,7 @@ Devices supporting the SDR receiver interface set the
 ``V4L2_CAP_SDR_CAPTURE`` and ``V4L2_CAP_TUNER`` flag in the
 ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. That flag means the
+:ref:`VIDIOC_QUERYCAP` ioctl. That flag means the
 device has an Analog to Digital Converter (ADC), which is a mandatory
 element for the SDR receiver.
 

@@ -30,7 +30,7 @@ Devices supporting the SDR transmitter interface set the
 ``V4L2_CAP_SDR_OUTPUT`` and ``V4L2_CAP_MODULATOR`` flag in the
 ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. That flag means the
+:ref:`VIDIOC_QUERYCAP` ioctl. That flag means the
 device has an Digital to Analog Converter (DAC), which is a mandatory
 element for the SDR transmitter.
 

@@ -42,7 +42,7 @@ Supplemental Functions
 ======================
 
 SDR devices can support :ref:`controls <control>`, and must support
-the :ref:`tuner <tuner>` ioctls. Tuner ioctls are used for setting the
+the :ref:`tuner` ioctls. Tuner ioctls are used for setting the
 ADC/DAC sampling rate (sampling frequency) and the possible radio
 frequency (RF).
 

@@ -52,21 +52,21 @@ radio frequency. The tuner index of the RF tuner (if any) must always
 follow the SDR tuner index. Normally the SDR tuner is #0 and the RF
 tuner is #1.
 
-The :ref:`VIDIOC_S_HW_FREQ_SEEK <VIDIOC_S_HW_FREQ_SEEK>` ioctl is
+The :ref:`VIDIOC_S_HW_FREQ_SEEK` ioctl is
 not supported.
 
 
 Data Format Negotiation
 =======================
 
-The SDR device uses the :ref:`format <format>` ioctls to select the
+The SDR device uses the :ref:`format` ioctls to select the
 capture and output format. Both the sampling resolution and the data
 streaming format are bound to that selectable format. In addition to the
-basic :ref:`format <format>` ioctls, the
-:ref:`VIDIOC_ENUM_FMT <VIDIOC_ENUM_FMT>` ioctl must be supported as
+basic :ref:`format` ioctls, the
+:ref:`VIDIOC_ENUM_FMT` ioctl must be supported as
 well.
 
-To use the :ref:`format <format>` ioctls applications set the ``type``
+To use the :ref:`format` ioctls applications set the ``type``
 field of a struct :ref:`v4l2_format <v4l2-format>` to
 ``V4L2_BUF_TYPE_SDR_CAPTURE`` or ``V4L2_BUF_TYPE_SDR_OUTPUT`` and use
 the struct :ref:`v4l2_sdr_format <v4l2-sdr-format>` ``sdr`` member

index 0faf178168e4..d53353afbedf 100644
@@ -35,7 +35,7 @@ Devices supporting the sliced VBI capturing or output API set the
 ``V4L2_CAP_SLICED_VBI_CAPTURE`` or ``V4L2_CAP_SLICED_VBI_OUTPUT`` flag
 respectively, in the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. At least one of the
+:ref:`VIDIOC_QUERYCAP` ioctl. At least one of the
 read/write, streaming or asynchronous :ref:`I/O methods <io>` must be
 supported. Sliced VBI devices may have a tuner or modulator.
 

@@ -45,7 +45,7 @@ Supplemental Functions
 
 Sliced VBI devices shall support :ref:`video input or output <video>`
 and :ref:`tuner or modulator <tuner>` ioctls if they have these
-capabilities, and they may support :ref:`control <control>` ioctls.
+capabilities, and they may support :ref:`control` ioctls.
 The :ref:`video standard <standard>` ioctls provide information vital
 to program a sliced VBI device, therefore must be supported.
 

@@ -57,7 +57,7 @@ Sliced VBI Format Negotiation
 
 To find out which data services are supported by the hardware
 applications can call the
-:ref:`VIDIOC_G_SLICED_VBI_CAP <VIDIOC_G_SLICED_VBI_CAP>` ioctl.
+:ref:`VIDIOC_G_SLICED_VBI_CAP` ioctl.
 All drivers implementing the sliced VBI interface must support this
 ioctl. The results may differ from those of the
 :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl when the number of VBI

@@ -70,7 +70,7 @@ To determine the currently selected services applications set the
 ``type`` field of struct :ref:`v4l2_format <v4l2-format>` to
 ``V4L2_BUF_TYPE_SLICED_VBI_CAPTURE`` or
 ``V4L2_BUF_TYPE_SLICED_VBI_OUTPUT``, and the
-:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` ioctl fills the ``fmt.sliced``
+:ref:`VIDIOC_G_FMT` ioctl fills the ``fmt.sliced``
 member, a struct
 :ref:`v4l2_sliced_vbi_format <v4l2-sliced-vbi-format>`.
 

@@ -95,7 +95,7 @@ according to hardware capabilities. When the driver allocates resources
 at this point, it may return an EBUSY error code if the required
 resources are temporarily unavailable. Other resource allocation points
 which may return EBUSY can be the
-:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` ioctl and the first
+:ref:`VIDIOC_STREAMON` ioctl and the first
 :ref:`read() <func-read>`, :ref:`write() <func-write>` and
 :ref:`select() <func-select>` call.
 

@@ -224,7 +224,7 @@ which may return EBUSY can be the
        -  :cspan:`2` Maximum number of bytes passed by one
           :ref:`read() <func-read>` or :ref:`write() <func-write>` call,
           and the buffer size in bytes for the
-          :ref:`VIDIOC_QBUF <VIDIOC_QBUF>` and
+          :ref:`VIDIOC_QBUF` and
           :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. Drivers set this field
           to the size of struct
           :ref:`v4l2_sliced_vbi_data <v4l2-sliced-vbi-data>` times the

@@ -343,7 +343,7 @@ after switching the video input (which may change the video standard as
 a side effect). The :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl may
 return an EBUSY error code when applications attempt to change the
 format while i/o is in progress (between a
-:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` and
+:ref:`VIDIOC_STREAMON` and
 :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` call, and after the first
 :ref:`read() <func-read>` or :ref:`write() <func-write>` call).
 

@@ -428,11 +428,11 @@ of one video frame. The ``id`` of unused
 
 Packets are always passed in ascending line number order, without
 duplicate line numbers. The :ref:`write() <func-write>` function and
-the :ref:`VIDIOC_QBUF <VIDIOC_QBUF>` ioctl must return an EINVAL
+the :ref:`VIDIOC_QBUF` ioctl must return an EINVAL
 error code when applications violate this rule. They must also return an
 EINVAL error code when applications pass an incorrect field or line
 number, or a combination of ``field``, ``line`` and ``id`` which has not
-been negotiated with the :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` or
+been negotiated with the :ref:`VIDIOC_G_FMT` or
 :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl. When the line numbers are
 unknown the driver must pass the packets in transmitted order. The
 driver can insert empty packets with ``id`` set to zero anywhere in the

index 1fe594c0026f..67732da53be5 100644
@@ -118,18 +118,18 @@ every point in the pipeline explicitly.
 Drivers that implement the :ref:`media API <media-controller-intro>`
 can expose pad-level image format configuration to applications. When
 they do, applications can use the
-:ref:`VIDIOC_SUBDEV_G_FMT <VIDIOC_SUBDEV_G_FMT>` and
+:ref:`VIDIOC_SUBDEV_G_FMT` and
 :ref:`VIDIOC_SUBDEV_S_FMT <VIDIOC_SUBDEV_G_FMT>` ioctls. to
 negotiate formats on a per-pad basis.
 
 Applications are responsible for configuring coherent parameters on the
 whole pipeline and making sure that connected pads have compatible
 formats. The pipeline is checked for formats mismatch at
-:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` time, and an EPIPE error
+:ref:`VIDIOC_STREAMON` time, and an EPIPE error
 code is then returned if the configuration is invalid.
 
 Pad-level image format configuration support can be tested by calling
-the :ref:`VIDIOC_SUBDEV_G_FMT <VIDIOC_SUBDEV_G_FMT>` ioctl on pad
+the :ref:`VIDIOC_SUBDEV_G_FMT` ioctl on pad
 0. If the driver returns an EINVAL error code pad-level format
 configuration is not supported by the sub-device.
 

@@ -146,7 +146,7 @@ formats enumeration only. A format negotiation mechanism is required.
 Central to the format negotiation mechanism are the get/set format
 operations. When called with the ``which`` argument set to
 ``V4L2_SUBDEV_FORMAT_TRY``, the
-:ref:`VIDIOC_SUBDEV_G_FMT <VIDIOC_SUBDEV_G_FMT>` and
+:ref:`VIDIOC_SUBDEV_G_FMT` and
 :ref:`VIDIOC_SUBDEV_S_FMT <VIDIOC_SUBDEV_G_FMT>` ioctls operate on
 a set of formats parameters that are not connected to the hardware
 configuration. Modifying those 'try' formats leaves the device state

@@ -155,7 +155,7 @@ and the hardware state stored in the device itself).
 
 While not kept as part of the device state, try formats are stored in
 the sub-device file handles. A
-:ref:`VIDIOC_SUBDEV_G_FMT <VIDIOC_SUBDEV_G_FMT>` call will return
+:ref:`VIDIOC_SUBDEV_G_FMT` call will return
 the last try format set *on the same sub-device file handle*. Several
 applications querying the same sub-device at the same time will thus not
 interact with each other.

index ed69e0fb6371..501e68077af2 100644
@@ -31,7 +31,7 @@ them. So the decision was made to finally remove support for the
 Teletext API in kernel 2.6.37.
 
 Modern devices all use the :ref:`raw <raw-vbi>` or
-:ref:`sliced <sliced>` VBI API.
+:ref:`sliced` VBI API.
 
 
 .. ------------------------------------------------------------------------------

207 lines not on this page · raw message

index bc2944c27e70..773d39308fd6 100644
@@ -20,9 +20,9 @@ exporting V4L2 buffers as DMABUF file descriptors.
 Input and output devices support the streaming I/O method when the
 ``V4L2_CAP_STREAMING`` flag in the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl is set. Whether
+:ref:`VIDIOC_QUERYCAP` ioctl is set. Whether
 importing DMA buffers through DMABUF file descriptors is supported is
-determined by calling the :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>`
+determined by calling the :ref:`VIDIOC_REQBUFS`
 ioctl with the memory type set to ``V4L2_MEMORY_DMABUF``.
 
 This I/O method is dedicated to sharing DMA buffers between different

@@ -34,7 +34,7 @@ such file descriptor are exchanged. The descriptors and meta-information
 are passed in struct :ref:`v4l2_buffer <v4l2-buffer>` (or in struct
 :ref:`v4l2_plane <v4l2-plane>` in the multi-planar API case). The
 driver must be switched into DMABUF I/O mode by calling the
-:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` with the desired buffer type.
+:ref:`VIDIOC_REQBUFS` with the desired buffer type.
 
 
 .. code-block:: c

@@ -56,7 +56,7 @@ driver must be switched into DMABUF I/O mode by calling the
     }
 
 The buffer (plane) file descriptor is passed on the fly with the
-:ref:`VIDIOC_QBUF <VIDIOC_QBUF>` ioctl. In case of multiplanar
+:ref:`VIDIOC_QBUF` ioctl. In case of multiplanar
 buffers, every plane can be associated with a different DMABUF
 descriptor. Although buffers are commonly cycled, applications can pass
 a different DMABUF descriptor at each ``VIDIOC_QBUF`` call.

@@ -116,7 +116,7 @@ Captured or displayed buffers are dequeued with the
 buffer at any time between the completion of the DMA and this ioctl. The
 memory is also unlocked when
 :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` is called,
-:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>`, or when the device is closed.
+:ref:`VIDIOC_REQBUFS`, or when the device is closed.
 
 For capturing applications it is customary to enqueue a number of empty
 buffers, to start capturing and enter the read loop. Here the

@@ -134,7 +134,7 @@ immediately with an EAGAIN error code when no buffer is available. The
 functions are always available.
 
 To start and stop capturing or displaying applications call the
-:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` and
+:ref:`VIDIOC_STREAMON` and
 :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` ioctls. Note that
 ``VIDIOC_STREAMOFF`` removes all buffers from both queues and unlocks
 all buffers as a side effect. Since there is no notion of doing anything

index d51c36ec604c..4b22b1b0fccb 100644
@@ -24,14 +24,14 @@ standards.
 
 To enumerate and query the attributes of the DV timings supported by a
 device applications use the
-:ref:`VIDIOC_ENUM_DV_TIMINGS <VIDIOC_ENUM_DV_TIMINGS>` and
-:ref:`VIDIOC_DV_TIMINGS_CAP <VIDIOC_DV_TIMINGS_CAP>` ioctls. To set
+:ref:`VIDIOC_ENUM_DV_TIMINGS` and
+:ref:`VIDIOC_DV_TIMINGS_CAP` ioctls. To set
 DV timings for the device applications use the
 :ref:`VIDIOC_S_DV_TIMINGS <VIDIOC_G_DV_TIMINGS>` ioctl and to get
 current DV timings they use the
-:ref:`VIDIOC_G_DV_TIMINGS <VIDIOC_G_DV_TIMINGS>` ioctl. To detect
+:ref:`VIDIOC_G_DV_TIMINGS` ioctl. To detect
 the DV timings as seen by the video receiver applications use the
-:ref:`VIDIOC_QUERY_DV_TIMINGS <VIDIOC_QUERY_DV_TIMINGS>` ioctl.
+:ref:`VIDIOC_QUERY_DV_TIMINGS` ioctl.
 
 Applications can make use of the :ref:`input-capabilities` and
 :ref:`output-capabilities` flags to determine whether the digital

index 66333b9f60fd..9a10edc50fa0 100644
@@ -39,11 +39,11 @@ The Extended Control API
 ========================
 
 Three new ioctls are available:
-:ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`,
+:ref:`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_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.

@@ -79,7 +79,7 @@ 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_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.

@@ -87,7 +87,7 @@ if this control consists of more than one element.
 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
-the :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` (or
+the :ref:`VIDIOC_QUERYCTRL` (or
 :ref:`VIDIOC_QUERY_EXT_CTRL <VIDIOC_QUERYCTRL>`) and
 :ref:`VIDIOC_QUERYMENU <VIDIOC_QUERYCTRL>` ioctls to check this. Also
 note that it is possible that some of the menu indices in a control of

@@ -103,7 +103,7 @@ Enumerating Extended Controls
 =============================
 
 The recommended way to enumerate over the extended controls is by using
-:ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` in combination with the
+:ref:`VIDIOC_QUERYCTRL` in combination with the
 ``V4L2_CTRL_FLAG_NEXT_CTRL`` flag:
 
 

@@ -169,7 +169,7 @@ 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 <VIDIOC_QUERYCTRL>` documentation for more
+:ref:`VIDIOC_QUERYCTRL` documentation for more
 details.
 
 

@@ -198,7 +198,7 @@ Codec Control IDs
 
 ``V4L2_CID_MPEG_CLASS (class)``
     The Codec class descriptor. Calling
-    :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` for this control will
+    :ref:`VIDIOC_QUERYCTRL` for this control will
     return a description of this control class. This description can be
     used as the caption of a Tab page in a GUI, for example.
 

@@ -1168,7 +1168,7 @@ Codec Control IDs
     This read-only control returns the 33-bit video Presentation Time
     Stamp as defined in ITU T-REC-H.222.0 and ISO/IEC 13818-1 of the
     currently displayed frame. This is the same PTS as is used in
-    :ref:`VIDIOC_DECODER_CMD <VIDIOC_DECODER_CMD>`.
+    :ref:`VIDIOC_DECODER_CMD`.
 
 .. _`v4l2-mpeg-video-dec-frame`:
 

@@ -2781,7 +2781,7 @@ Camera Control IDs
 
 ``V4L2_CID_CAMERA_CLASS (class)``
     The Camera class descriptor. Calling
-    :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` for this control will
+    :ref:`VIDIOC_QUERYCTRL` for this control will
     return a description of this control class.
 
 .. _`v4l2-exposure-auto-type`:

@@ -3441,7 +3441,7 @@ FM_TX Control IDs
 
 ``V4L2_CID_FM_TX_CLASS (class)``
     The FM_TX class descriptor. Calling
-    :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` for this control will
+    :ref:`VIDIOC_QUERYCTRL` for this control will
     return a description of this control class.
 
 ``V4L2_CID_RDS_TX_DEVIATION (integer)``

@@ -3870,7 +3870,7 @@ JPEG Control IDs
 
 ``V4L2_CID_JPEG_CLASS (class)``
     The JPEG class descriptor. Calling
-    :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` for this control will
+    :ref:`VIDIOC_QUERYCTRL` for this control will
     return a description of this control class.
 
 ``V4L2_CID_JPEG_CHROMA_SUBSAMPLING (menu)``

@@ -4271,7 +4271,7 @@ FM_RX Control IDs
 
 ``V4L2_CID_FM_RX_CLASS (class)``
     The FM_RX class descriptor. Calling
-    :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` for this control will
+    :ref:`VIDIOC_QUERYCTRL` for this control will
     return a description of this control class.
 
 ``V4L2_CID_RDS_RECEPTION (boolean)``

@@ -4369,7 +4369,7 @@ Detect Control IDs
 
 ``V4L2_CID_DETECT_CLASS (class)``
     The Detect class descriptor. Calling
-    :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` for this control will
+    :ref:`VIDIOC_QUERYCTRL` for this control will
     return a description of this control class.
 
 ``V4L2_CID_DETECT_MD_MODE (menu)``

@@ -4463,7 +4463,7 @@ RF_TUNER Control IDs
 
 ``V4L2_CID_RF_TUNER_CLASS (class)``
     The RF_TUNER class descriptor. Calling
-    :ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` for this control will
+    :ref:`VIDIOC_QUERYCTRL` for this control will
     return a description of this control class.
 
 ``V4L2_CID_RF_TUNER_BANDWIDTH_AUTO (boolean)``

index a754fa81f707..46f740a0092e 100644
@@ -23,7 +23,7 @@ current selection.
 
 A single mechanism exists to negotiate all data formats using the
 aggregate struct :ref:`v4l2_format <v4l2-format>` and the
-:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` and
+:ref:`VIDIOC_G_FMT` and
 :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctls. Additionally the
 :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl can be used to examine
 what the hardware *could* do, without actually selecting a new data

@@ -52,7 +52,7 @@ image size.
 
 When applications omit the ``VIDIOC_S_FMT`` ioctl its locking side
 effects are implied by the next step, the selection of an I/O method
-with the :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl or implicit
+with the :ref:`VIDIOC_REQBUFS` ioctl or implicit
 with the first :ref:`read() <func-read>` or
 :ref:`write() <func-write>` call.
 

@@ -75,7 +75,7 @@ Apart of the generic format negotiation functions a special ioctl to
 enumerate all image formats supported by video capture, overlay or
 output devices is available. [1]_
 
-The :ref:`VIDIOC_ENUM_FMT <VIDIOC_ENUM_FMT>` ioctl must be supported
+The :ref:`VIDIOC_ENUM_FMT` ioctl must be supported
 by all drivers exchanging image data with applications.
 
     **Important**

index 7243142384bb..b908c0253c07 100644
@@ -98,8 +98,8 @@ application address space, preferably at address ``start``. This latter
 address is a hint only, and is usually specified as 0.
 
 Suitable length and offset parameters are queried with the
-:ref:`VIDIOC_QUERYBUF <VIDIOC_QUERYBUF>` ioctl. Buffers must be
-allocated with the :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl
+:ref:`VIDIOC_QUERYBUF` ioctl. Buffers must be
+allocated with the :ref:`VIDIOC_REQBUFS` ioctl
 before they can be queried.
 
 To unmap buffers the :ref:`munmap() <func-munmap>` function is used.

@@ -125,7 +125,7 @@ EINVAL
     The ``flags`` or ``prot`` value is not supported.
 
     No buffers have been allocated with the
-    :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl.
+    :ref:`VIDIOC_REQBUFS` ioctl.
 
 ENOMEM
     Not enough physical or virtual memory was available to complete the

index 28a769af9309..782531fe964c 100644
@@ -32,7 +32,7 @@ When streaming I/O has been negotiated this function waits until a
 buffer has been filled by the capture device and can be dequeued with
 the :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. For output devices this
 function waits until the device is ready to accept a new buffer to be
-queued up with the :ref:`VIDIOC_QBUF <VIDIOC_QBUF>` ioctl for
+queued up with the :ref:`VIDIOC_QBUF` ioctl for
 display. When buffers are already in the outgoing queue of the driver
 (capture) or the incoming queue isn't full (display) the function
 returns immediately.

@@ -45,17 +45,17 @@ flags in the ``revents`` field, output devices the ``POLLOUT`` and
 ``POLLWRNORM`` flags. When the function timed out it returns a value of
 zero, on failure it returns -1 and the ``errno`` variable is set
 appropriately. When the application did not call
-:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` the :c:func:`poll()`
+:ref:`VIDIOC_STREAMON` the :c:func:`poll()`
 function succeeds, but sets the ``POLLERR`` flag in the ``revents``
 field. When the application has called
-:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` for a capture device but
-hasn't yet called :ref:`VIDIOC_QBUF <VIDIOC_QBUF>`, the
+:ref:`VIDIOC_STREAMON` for a capture device but
+hasn't yet called :ref:`VIDIOC_QBUF`, the
 :c:func:`poll()` function succeeds and sets the ``POLLERR`` flag in
 the ``revents`` field. For output devices this same situation will cause
 :c:func:`poll()` to succeed as well, but it sets the ``POLLOUT`` and
 ``POLLWRNORM`` flags in the ``revents`` field.
 
-If an event occurred (see :ref:`VIDIOC_DQEVENT <VIDIOC_DQEVENT>`)
+If an event occurred (see :ref:`VIDIOC_DQEVENT`)
 then ``POLLPRI`` will be set in the ``revents`` field and
 :c:func:`poll()` will return.
 

index 497bc9a9dd5a..0eae26288189 100644
@@ -85,7 +85,7 @@ enough. Again, the behavior when the driver runs out of free buffers
 depends on the discarding policy.
 
 Applications can get and set the number of buffers used internally by
-the driver with the :ref:`VIDIOC_G_PARM <VIDIOC_G_PARM>` and
+the driver with the :ref:`VIDIOC_G_PARM` and
 :ref:`VIDIOC_S_PARM <VIDIOC_G_PARM>` ioctls. They are optional,
 however. The discarding policy is not reported and cannot be changed.
 For minimum requirements see :ref:`devices`.

index 77fdf33648b3..77302800e6ca 100644
@@ -39,8 +39,8 @@ On success :c:func:`select()` returns the total number of bits set in
 the :c:type:`struct fd_set`s. When the function timed out it returns
 a value of zero. On failure it returns -1 and the ``errno`` variable is
 set appropriately. When the application did not call
-:ref:`VIDIOC_QBUF <VIDIOC_QBUF>` or
-:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` yet the :c:func:`select()`
+:ref:`VIDIOC_QBUF` or
+:ref:`VIDIOC_STREAMON` yet the :c:func:`select()`
 function succeeds, setting the bit of the file descriptor in ``readfds``
 or ``writefds``, but subsequent :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>`
 calls will fail. [1]_

237 lines not on this page · raw message

index 2bc04e597c90..651d4530c703 100644
@@ -16,7 +16,7 @@ read or write will fail at any time.
 
 Other methods must be negotiated. To select the streaming I/O method
 with memory mapped or user buffers applications call the
-:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl. The asynchronous I/O
+:ref:`VIDIOC_REQBUFS` ioctl. The asynchronous I/O
 method is not defined yet.
 
 Video overlay can be considered another I/O method, although the

index 4fd87ec33260..bc3eb48e1d9f 100644
@@ -92,16 +92,16 @@ and to enhance the image quality.
 In most cases, libv4l2 just passes the calls directly through to the
 v4l2 driver, intercepting the calls to
 :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>`,
-:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`
+:ref:`VIDIOC_G_FMT`
 :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
-:ref:`VIDIOC_ENUM_FRAMESIZES <VIDIOC_ENUM_FRAMESIZES>` and
-:ref:`VIDIOC_ENUM_FRAMEINTERVALS <VIDIOC_ENUM_FRAMEINTERVALS>` in
+:ref:`VIDIOC_ENUM_FRAMESIZES` and
+:ref:`VIDIOC_ENUM_FRAMEINTERVALS` in
 order to emulate the formats
 :ref:`V4L2_PIX_FMT_BGR24 <V4L2-PIX-FMT-BGR24>`,
 :ref:`V4L2_PIX_FMT_RGB24 <V4L2-PIX-FMT-RGB24>`,
 :ref:`V4L2_PIX_FMT_YUV420 <V4L2-PIX-FMT-YUV420>`, and
 :ref:`V4L2_PIX_FMT_YVU420 <V4L2-PIX-FMT-YVU420>`, if they aren't
-available in the driver. :ref:`VIDIOC_ENUM_FMT <VIDIOC_ENUM_FMT>`
+available in the driver. :ref:`VIDIOC_ENUM_FMT`
 keeps enumerating the hardware supported formats, plus the emulated
 formats offered by libv4l at the end.
 

index de144028ec56..2013e882f0d4 100644
@@ -9,10 +9,10 @@ Streaming I/O (Memory Mapping)
 Input and output devices support this I/O method when the
 ``V4L2_CAP_STREAMING`` flag in the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl is set. There are two
+:ref:`VIDIOC_QUERYCAP` ioctl is set. There are two
 streaming methods, to determine if the memory mapping flavor is
 supported applications must call the
-:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl.
+:ref:`VIDIOC_REQBUFS` ioctl.
 
 Streaming is an I/O method where only pointers to buffers are exchanged
 between application and driver, the data itself is not copied. Memory

@@ -29,7 +29,7 @@ a different type of data. To access different sets at the same time
 different file descriptors must be used. [1]_
 
 To allocate device buffers applications call the
-:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl with the desired number
+:ref:`VIDIOC_REQBUFS` ioctl with the desired number
 of buffers and buffer type, for example ``V4L2_BUF_TYPE_VIDEO_CAPTURE``.
 This ioctl can also be used to change the number of buffers or to free
 the allocated memory, provided none of the buffers are still mapped.

@@ -37,7 +37,7 @@ the allocated memory, provided none of the buffers are still mapped.
 Before applications can access the buffers they must map them into their
 address space with the :ref:`mmap() <func-mmap>` function. The
 location of the buffers in device memory can be determined with the
-:ref:`VIDIOC_QUERYBUF <VIDIOC_QUERYBUF>` ioctl. In the single-planar
+:ref:`VIDIOC_QUERYBUF` ioctl. In the single-planar
 API case, the ``m.offset`` and ``length`` returned in a struct
 :ref:`v4l2_buffer <v4l2-buffer>` are passed as sixth and second
 parameter to the :c:func:`mmap()` function. When using the

@@ -227,10 +227,10 @@ when the application runs out of free buffers, it must wait until an
 empty buffer can be dequeued and reused.
 
 To enqueue and dequeue a buffer applications use the
-:ref:`VIDIOC_QBUF <VIDIOC_QBUF>` and
+:ref:`VIDIOC_QBUF` and
 :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl. The status of a buffer being
 mapped, enqueued, full or empty can be determined at any time using the
-:ref:`VIDIOC_QUERYBUF <VIDIOC_QUERYBUF>` ioctl. Two methods exist to
+:ref:`VIDIOC_QUERYBUF` ioctl. Two methods exist to
 suspend execution of the application until one or more buffers can be
 dequeued. By default ``VIDIOC_DQBUF`` blocks when no buffer is in the
 outgoing queue. When the ``O_NONBLOCK`` flag was given to the

@@ -240,7 +240,7 @@ immediately with an EAGAIN error code when no buffer is available. The
 are always available.
 
 To start and stop capturing or output applications call the
-:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` and
+:ref:`VIDIOC_STREAMON` and
 :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` ioctl. Note
 ``VIDIOC_STREAMOFF`` removes all buffers from both queues as a side
 effect. Since there is no notion of doing anything "now" on a

@@ -258,7 +258,7 @@ the :c:func:`mmap()`, :c:func:`munmap()`, :c:func:`select()` and
 
 .. [1]
    One could use one file descriptor and set the buffer type field
-   accordingly when calling :ref:`VIDIOC_QBUF <VIDIOC_QBUF>` etc.,
+   accordingly when calling :ref:`VIDIOC_QBUF` etc.,
    but it makes the :c:func:`select()` function ambiguous. We also
    like the clean approach of one file descriptor per logical stream.
    Video overlay for example is also a logical stream, although the CPU

index 4c34d61a5253..ec6b456e37f0 100644
@@ -108,8 +108,8 @@ are comparable to an ALSA audio mixer application. Just opening a V4L2
 device should not change the state of the device. [2]_
 
 Once an application has allocated the memory buffers needed for
-streaming data (by calling the :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>`
-or :ref:`VIDIOC_CREATE_BUFS <VIDIOC_CREATE_BUFS>` ioctls, or
+streaming data (by calling the :ref:`VIDIOC_REQBUFS`
+or :ref:`VIDIOC_CREATE_BUFS` ioctls, or
 implicitly by calling the :ref:`read() <func-read>` or
 :ref:`write() <func-write>` functions) that application (filehandle)
 becomes the owner of the device. It is no longer allowed to make changes

index b3cb7c48eb74..7584cb2e5702 100644
@@ -27,7 +27,7 @@ Compressed Formats
 
        -  'JPEG'
 
-       -  TBD. See also :ref:`VIDIOC_G_JPEGCOMP <VIDIOC_G_JPEGCOMP>`,
+       -  TBD. See also :ref:`VIDIOC_G_JPEGCOMP`,
           :ref:`VIDIOC_S_JPEGCOMP <VIDIOC_G_JPEGCOMP>`.
 
     -  .. _`V4L2-PIX-FMT-MPEG`:

index 2caf9ccea69a..2b4a6c725d4c 100644
@@ -967,7 +967,7 @@ XBGR) must be used instead of an alpha format.
 
 The XRGB and XBGR formats contain undefined bits (-). Applications,
 devices and drivers must ignore those bits, for both
-:ref:`capture <capture>` and :ref:`output <output>` devices.
+:ref:`capture` and :ref:`output` devices.
 
 **Byte Order..**
 

index f2c599aaa502..b0e6a95a7205 100644
@@ -13,7 +13,7 @@ single-planar API, while the latter is used with the multi-planar
 version (see :ref:`planar-apis`). Image formats are negotiated with
 the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl. (The explanations here
 focus on video capturing and output, for overlay frame buffer formats
-see also :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>`.)
+see also :ref:`VIDIOC_G_FBUF`.)
 
 
 .. toctree::

index 017f412a6231..0546210f868f 100644
@@ -39,12 +39,12 @@ handle multi-planar formats.
 Calls that distinguish between single and multi-planar APIs
 ===========================================================
 
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>`
+:ref:`VIDIOC_QUERYCAP`
     Two additional multi-planar capabilities are added. They can be set
     together with non-multi-planar ones for devices that handle both
     single- and multi-planar formats.
 
-:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`,
+:ref:`VIDIOC_G_FMT`,
 :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`,
 :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>`
     New structures for describing multi-planar formats are added: struct

@@ -53,15 +53,15 @@ Calls that distinguish between single and multi-planar APIs
     Drivers may define new multi-planar formats, which have distinct
     FourCC codes from the existing single-planar ones.
 
-:ref:`VIDIOC_QBUF <VIDIOC_QBUF>`,
+:ref:`VIDIOC_QBUF`,
 :ref:`VIDIOC_DQBUF <VIDIOC_QBUF>`,
-:ref:`VIDIOC_QUERYBUF <VIDIOC_QUERYBUF>`
+:ref:`VIDIOC_QUERYBUF`
     A new struct :ref:`v4l2_plane <v4l2-plane>` structure for
     describing planes is added. Arrays of this structure are passed in
     the new ``m.planes`` field of struct
     :ref:`v4l2_buffer <v4l2-buffer>`.
 
-:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>`
+:ref:`VIDIOC_REQBUFS`
     Will allocate multi-planar buffers as requested.
 
 

index d8f080a68195..bb905eb82c08 100644
@@ -11,26 +11,26 @@ are equally applicable to all types of devices. Furthermore devices of
 the same type have different capabilities and this specification permits
 the omission of a few complicated and less important parts of the API.
 
-The :ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl is available to
+The :ref:`VIDIOC_QUERYCAP` ioctl is available to
 check if the kernel device is compatible with this specification, and to
 query the :ref:`functions <devices>` and :ref:`I/O methods <io>`
 supported by the device.
 
-Starting with kernel version 3.1, :ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>`
+Starting with kernel version 3.1, :ref:`VIDIOC_QUERYCAP`
 will return the V4L2 API version used by the driver, with generally
 matches the Kernel version. There's no need of using
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` to check if a specific ioctl
+:ref:`VIDIOC_QUERYCAP` to check if a specific ioctl
 is supported, the V4L2 core now returns ENOTTY if a driver doesn't
 provide support for an ioctl.
 
 Other features can be queried by calling the respective ioctl, for
-example :ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>` to learn about the
+example :ref:`VIDIOC_ENUMINPUT` to learn about the
 number, types and names of video connectors on the device. Although
 abstraction is a major objective of this API, the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl also allows driver
+:ref:`VIDIOC_QUERYCAP` ioctl also allows driver
 specific applications to reliably identify the driver.
 
-All V4L2 drivers must support :ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>`.
+All V4L2 drivers must support :ref:`VIDIOC_QUERYCAP`.
 Applications should always call this ioctl after opening the device.
 
 

index ad365a6e435d..c840ee0fd14c 100644
@@ -10,7 +10,7 @@ Input and output devices support the :c:func:`read()` and
 :c:func:`write()` function, respectively, when the
 ``V4L2_CAP_READWRITE`` flag in the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl is set.
+:ref:`VIDIOC_QUERYCAP` ioctl is set.
 
 Drivers may need the CPU to copy the data, but they may also support DMA
 to or from user memory, so this I/O method is not necessarily less

index da0b8101b6cc..3c0f6cb97f13 100644
@@ -11,8 +11,8 @@ variations of standards. Each video input and output may support another
 set of standards. This set is reported by the ``std`` field of struct
 :ref:`v4l2_input <v4l2-input>` and struct
 :ref:`v4l2_output <v4l2-output>` returned by the
-:ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>` and
-:ref:`VIDIOC_ENUMOUTPUT <VIDIOC_ENUMOUTPUT>` ioctls, respectively.
+:ref:`VIDIOC_ENUMINPUT` and
+:ref:`VIDIOC_ENUMOUTPUT` ioctls, respectively.
 
 V4L2 defines one bit for each analog video standard currently in use
 worldwide, and sets aside bits for driver defined standards, e. g.

@@ -20,7 +20,7 @@ hybrid standards to watch NTSC video tapes on PAL TVs and vice versa.
 Applications can use the predefined bits to select a particular
 standard, although presenting the user a menu of supported standards is
 preferred. To enumerate and query the attributes of the supported
-standards applications use the :ref:`VIDIOC_ENUMSTD <VIDIOC_ENUMSTD>`
+standards applications use the :ref:`VIDIOC_ENUMSTD`
 ioctl.
 
 Many of the defined standards are actually just variations of a few

@@ -36,10 +36,10 @@ Composite input may collapse standards, enumerating "PAL-B/G/H/I",
 "NTSC-M" and "SECAM-D/K". [1]_
 
 To query and select the standard used by the current video input or
-output applications call the :ref:`VIDIOC_G_STD <VIDIOC_G_STD>` and
+output applications call the :ref:`VIDIOC_G_STD` and
 :ref:`VIDIOC_S_STD <VIDIOC_G_STD>` ioctl, respectively. The
 *received* standard can be sensed with the
-:ref:`VIDIOC_QUERYSTD <VIDIOC_QUERYSTD>` ioctl. Note that the
+:ref:`VIDIOC_QUERYSTD` ioctl. Note that the
 parameter of all these ioctls is a pointer to a
 :ref:`v4l2_std_id <v4l2-std-id>` type (a standard set), *not* an
 index into the standard enumeration. Drivers must implement all video

index bb8100b6ef87..10420478a3b0 100644
@@ -23,7 +23,7 @@ internally by a driver in read/write mode. For implications see the
 section discussing the :ref:`read() <func-read>` function.
 
 To get and set the streaming parameters applications call the
-:ref:`VIDIOC_G_PARM <VIDIOC_G_PARM>` and
+:ref:`VIDIOC_G_PARM` and
 :ref:`VIDIOC_S_PARM <VIDIOC_G_PARM>` ioctl, respectively. They take
 a pointer to a struct :ref:`v4l2_streamparm <v4l2-streamparm>`, which
 contains a union holding separate parameters for input and output

index 15c2e6c373ab..b1be27bd297e 100644
@@ -14,7 +14,7 @@ Video input devices can have one or more tuners demodulating a RF
 signal. Each tuner is associated with one or more video inputs,
 depending on the number of RF connectors on the tuner. The ``type``
 field of the respective struct :ref:`v4l2_input <v4l2-input>`
-returned by the :ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>` ioctl is
+returned by the :ref:`VIDIOC_ENUMINPUT` ioctl is
 set to ``V4L2_INPUT_TYPE_TUNER`` and its ``tuner`` field contains the
 index number of the tuner.
 

@@ -22,7 +22,7 @@ Radio input devices have exactly one tuner with index zero, no video
 inputs.
 
 To query and change tuner properties applications use the
-:ref:`VIDIOC_G_TUNER <VIDIOC_G_TUNER>` and
+:ref:`VIDIOC_G_TUNER` and
 :ref:`VIDIOC_S_TUNER <VIDIOC_G_TUNER>` ioctls, respectively. The
 struct :ref:`v4l2_tuner <v4l2-tuner>` returned by ``VIDIOC_G_TUNER``
 also contains signal status information applicable when the tuner of the

@@ -31,7 +31,7 @@ does not switch the current tuner, when there is more than one at all.
 The tuner is solely determined by the current video input. Drivers must
 support both ioctls and set the ``V4L2_CAP_TUNER`` flag in the struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl when the device has
+:ref:`VIDIOC_QUERYCAP` ioctl when the device has
 one or more tuners.
 
 

@@ -44,7 +44,7 @@ set or video recorder. Each modulator is associated with one or more
 video outputs, depending on the number of RF connectors on the
 modulator. The ``type`` field of the respective struct
 :ref:`v4l2_output <v4l2-output>` returned by the
-:ref:`VIDIOC_ENUMOUTPUT <VIDIOC_ENUMOUTPUT>` ioctl is set to
+:ref:`VIDIOC_ENUMOUTPUT` ioctl is set to
 ``V4L2_OUTPUT_TYPE_MODULATOR`` and its ``modulator`` field contains the
 index number of the modulator.
 

@@ -59,14 +59,14 @@ functionality. The reason is a limitation with the
 cannot specify whether the frequency is for a tuner or a modulator.
 
 To query and change modulator properties applications use the
-:ref:`VIDIOC_G_MODULATOR <VIDIOC_G_MODULATOR>` and
+:ref:`VIDIOC_G_MODULATOR` and
 :ref:`VIDIOC_S_MODULATOR <VIDIOC_G_MODULATOR>` ioctl. Note that
 ``VIDIOC_S_MODULATOR`` does not switch the current modulator, when there
 is more than one at all. The modulator is solely determined by the
 current video output. Drivers must support both ioctls and set the
 ``V4L2_CAP_MODULATOR`` flag in the struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl when the device has
+:ref:`VIDIOC_QUERYCAP` ioctl when the device has
 one or more modulators.
 
 

@@ -74,7 +74,7 @@ Radio Frequency
 ===============
 
 To get and set the tuner or modulator radio frequency applications use
-the :ref:`VIDIOC_G_FREQUENCY <VIDIOC_G_FREQUENCY>` and
+the :ref:`VIDIOC_G_FREQUENCY` and
 :ref:`VIDIOC_S_FREQUENCY <VIDIOC_G_FREQUENCY>` ioctl which both take
 a pointer to a struct :ref:`v4l2_frequency <v4l2-frequency>`. These
 ioctls are used for TV and radio devices alike. Drivers must support

index 5433025d41d9..a5426d10ceb8 100644
@@ -9,10 +9,10 @@ Streaming I/O (User Pointers)
 Input and output devices support this I/O method when the
 ``V4L2_CAP_STREAMING`` flag in the ``capabilities`` field of struct
 :ref:`v4l2_capability <v4l2-capability>` returned by the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl is set. If the
+:ref:`VIDIOC_QUERYCAP` ioctl is set. If the
 particular user pointer method (not only memory mapping) is supported
 must be determined by calling the
-:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl.
+:ref:`VIDIOC_REQBUFS` ioctl.
 
 This I/O method combines advantages of the read/write and memory mapping
 methods. Buffers (planes) are allocated by the application itself, and

@@ -21,7 +21,7 @@ data are exchanged, these pointers and meta-information are passed in
 struct :ref:`v4l2_buffer <v4l2-buffer>` (or in struct
 :ref:`v4l2_plane <v4l2-plane>` in the multi-planar API case). The
 driver must be switched into user pointer I/O mode by calling the
-:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` with the desired buffer type.
+:ref:`VIDIOC_REQBUFS` with the desired buffer type.
 No buffers (planes) are allocated beforehand, consequently they are not
 indexed and cannot be queried like mapped buffers with the
 ``VIDIOC_QUERYBUF`` ioctl.

@@ -45,7 +45,7 @@ indexed and cannot be queried like mapped buffers with the
     }
 
 Buffer (plane) addresses and sizes are passed on the fly with the
-:ref:`VIDIOC_QBUF <VIDIOC_QBUF>` ioctl. Although buffers are commonly
+:ref:`VIDIOC_QBUF` ioctl. Although buffers are commonly
 cycled, applications can pass different addresses and sizes at each
 ``VIDIOC_QBUF`` call. If required by the hardware the driver swaps
 memory pages within physical memory to create a continuous area of

@@ -59,7 +59,7 @@ Filled or displayed buffers are dequeued with the
 memory pages at any time between the completion of the DMA and this
 ioctl. The memory is also unlocked when
 :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` is called,
-:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>`, or when the device is closed.
+:ref:`VIDIOC_REQBUFS`, or when the device is closed.
 Applications must take care not to free buffers without dequeuing. For
 once, the buffers remain locked until further, wasting physical memory.
 Second the driver will not be notified when the memory is returned to

@@ -82,7 +82,7 @@ immediately with an EAGAIN error code when no buffer is available. The
 are always available.
 
 To start and stop capturing or output applications call the
-:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` and
+:ref:`VIDIOC_STREAMON` and
 :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` ioctl. Note
 ``VIDIOC_STREAMOFF`` removes all buffers from both queues and unlocks
 all buffers as a side effect. Since there is no notion of doing anything

index e4e543b56989..9f2dc4ee4fcd 100644
@@ -14,14 +14,14 @@ Radio devices have no video inputs or outputs.
 
 To learn about the number and attributes of the available inputs and
 outputs applications can enumerate them with the
-:ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>` and
-:ref:`VIDIOC_ENUMOUTPUT <VIDIOC_ENUMOUTPUT>` ioctl, respectively. The
+:ref:`VIDIOC_ENUMINPUT` and
+:ref:`VIDIOC_ENUMOUTPUT` ioctl, respectively. The
 struct :ref:`v4l2_input <v4l2-input>` returned by the
-:ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>` ioctl also contains signal
+:ref:`VIDIOC_ENUMINPUT` ioctl also contains signal
 :status information applicable when the current video input is queried.
 
-The :ref:`VIDIOC_G_INPUT <VIDIOC_G_INPUT>` and
-:ref:`VIDIOC_G_OUTPUT <VIDIOC_G_OUTPUT>` ioctls return the index of
+The :ref:`VIDIOC_G_INPUT` and
+:ref:`VIDIOC_G_OUTPUT` ioctls return the index of
 the current video input or output. To select a different input or output
 applications call the :ref:`VIDIOC_S_INPUT <VIDIOC_G_INPUT>` and
 :ref:`VIDIOC_S_OUTPUT <VIDIOC_G_OUTPUT>` ioctls. Drivers must

index 9c2a011f389c..9220bcea1259 100644
@@ -34,7 +34,7 @@ Description
 This ioctl is used to create buffers for :ref:`memory mapped <mmap>`
 or :ref:`user pointer <userp>` or :ref:`DMA buffer <dmabuf>` I/O. It
 can be used as an alternative or in addition to the
-:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl, when a tighter control
+:ref:`VIDIOC_REQBUFS` ioctl, when a tighter control
 over buffers is required. This ioctl can be called multiple times to
 create buffers of different sizes.
 

@@ -48,7 +48,7 @@ The ``format`` field specifies the image format that the buffers must be
 able to handle. The application has to fill in this struct
 :ref:`v4l2_format <v4l2-format>`. Usually this will be done using the
 :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` or
-:ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` ioctls to ensure that the
+:ref:`VIDIOC_G_FMT` ioctls to ensure that the
 requested format is supported by the driver. Based on the format's
 ``type`` field the requested buffer size (for single-planar) or plane
 sizes (for multi-planar formats) will be used for the allocated buffers.

index 0a92e2550ce0..12c2e5df48ac 100644
@@ -33,7 +33,7 @@ Description
 
     **Note**
 
-    This is an :ref:`experimental <experimental>` interface and may
+    This is an :ref:`experimental` interface and may
     change in the future.
 
 For driver debugging purposes this ioctl allows test applications to

index 1b86abcc44c7..b50c1be72f15 100644
@@ -36,7 +36,7 @@ Description
 
     **Note**
 
-    This is an :ref:`experimental <experimental>` interface and may
+    This is an :ref:`experimental` interface and may
     change in the future.
 
 For driver debugging purposes these ioctls allow test applications to

@@ -65,14 +65,14 @@ When ``match.type`` is ``V4L2_CHIP_MATCH_BRIDGE``, ``match.addr``
 selects the nth non-sub-device chip on the TV card. The number zero
 always selects the host chip, e. g. the chip connected to the PCI or USB
 bus. You can find out which chips are present with the
-:ref:`VIDIOC_DBG_G_CHIP_INFO <VIDIOC_DBG_G_CHIP_INFO>` ioctl.
+:ref:`VIDIOC_DBG_G_CHIP_INFO` ioctl.
 
 When ``match.type`` is ``V4L2_CHIP_MATCH_SUBDEV``, ``match.addr``
 selects the nth sub-device.
 
 These ioctls are optional, not all drivers may support them. However
 when a driver supports these ioctls it must also support
-:ref:`VIDIOC_DBG_G_CHIP_INFO <VIDIOC_DBG_G_CHIP_INFO>`. Conversely
+:ref:`VIDIOC_DBG_G_CHIP_INFO`. Conversely
 it may support ``VIDIOC_DBG_G_CHIP_INFO`` but not these ioctls.
 
 ``VIDIOC_DBG_G_REGISTER`` and ``VIDIOC_DBG_S_REGISTER`` were introduced

index ec9dfed09f76..a56c5fc1ed6f 100644
@@ -43,7 +43,7 @@ this structure.
 The ``cmd`` field must contain the command code. Some commands use the
 ``flags`` field for additional information.
 
-A :c:func:`write()`() or :ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>`
+A :c:func:`write()`() or :ref:`VIDIOC_STREAMON`
 call sends an implicit START command to the decoder if it has not been
 started yet.
 

index 45320997344d..9e41fc818b90 100644
@@ -363,7 +363,7 @@ call.
 
        -  The 32-bit value of the control for 32-bit control types. This is
           0 for string controls since the value of a string cannot be passed
-          using :ref:`VIDIOC_DQEVENT <VIDIOC_DQEVENT>`.
+          using :ref:`VIDIOC_DQEVENT`.
 
     -  .. row 5
 

index ffa363eeaa36..43c7a3928e7b 100644
@@ -48,7 +48,7 @@ currently only used by the STOP command and contains one bit: If the
 until the end of the current *Group Of Pictures*, otherwise it will stop
 immediately.
 
-A :c:func:`read()`() or :ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>`
+A :c:func:`read()`() or :ref:`VIDIOC_STREAMON`
 call sends an implicit START command to the encoder if it has not been
 started yet. After a STOP command, :c:func:`read()`() calls will read
 the remaining data buffered by the driver. When the buffer is empty,

index 5b8f17422fdb..07462519cbf4 100644
@@ -35,7 +35,7 @@ Description
 While some DV receivers or transmitters support a wide range of timings,
 others support only a limited number of timings. With this ioctl
 applications can enumerate a list of known supported timings. Call
-:ref:`VIDIOC_DV_TIMINGS_CAP <VIDIOC_DV_TIMINGS_CAP>` to check if it
+:ref:`VIDIOC_DV_TIMINGS_CAP` to check if it
 also supports other standards or even custom timings that are not in
 this list.
 

index 2c69866c8d9e..a9182898b6dc 100644
@@ -38,8 +38,8 @@ This ioctl allows applications to enumerate all frame intervals that the
 device supports for the given pixel format and frame size.
 
 The supported pixel formats and frame sizes can be obtained by using the
-:ref:`VIDIOC_ENUM_FMT <VIDIOC_ENUM_FMT>` and
-:ref:`VIDIOC_ENUM_FRAMESIZES <VIDIOC_ENUM_FRAMESIZES>` functions.
+:ref:`VIDIOC_ENUM_FMT` and
+:ref:`VIDIOC_ENUM_FRAMESIZES` functions.
 
 The return value and the content of the ``v4l2_frmivalenum.type`` field
 depend on the type of frame intervals the device supports. Here are the

index 9b763ca9d0d8..5e171dbc975c 100644
@@ -39,7 +39,7 @@ and height in pixels) that the device supports for the given pixel
 format.
 
 The supported pixel formats can be obtained by using the
-:ref:`VIDIOC_ENUM_FMT <VIDIOC_ENUM_FMT>` function.
+:ref:`VIDIOC_ENUM_FMT` function.
 
 The return value and the content of the ``v4l2_frmsizeenum.type`` field
 depend on the type of frame sizes the device supports. Here are the

index a389cbc75970..e71925f3f13e 100644
@@ -35,7 +35,7 @@ This ioctl is an extension to the :ref:`memory mapping <mmap>` I/O
 method, therefore it is available only for ``V4L2_MEMORY_MMAP`` buffers.
 It can be used to export a buffer as a DMABUF file at any time after
 buffers have been allocated with the
-:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl.
+:ref:`VIDIOC_REQBUFS` ioctl.
 
 To export a buffer, applications fill struct
 :ref:`v4l2_exportbuffer <v4l2-exportbuffer>`. The ``type`` field is

@@ -43,7 +43,7 @@ set to the same buffer type as was previously used with struct
 :ref:`v4l2_requestbuffers <v4l2-requestbuffers>` ``type``.
 Applications must also set the ``index`` field. Valid index numbers
 range from zero to the number of buffers allocated with
-:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` (struct
+:ref:`VIDIOC_REQBUFS` (struct
 :ref:`v4l2_requestbuffers <v4l2-requestbuffers>` ``count``) minus
 one. For the multi-planar API, applications set the ``plane`` field to
 the index of the plane to be exported. Valid planes range from zero to

@@ -142,8 +142,8 @@ Examples
        -  Number of the buffer, set by the application. This field is only
           used for :ref:`memory mapping <mmap>` I/O and can range from
           zero to the number of buffers allocated with the
-          :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` and/or
-          :ref:`VIDIOC_CREATE_BUFS <VIDIOC_CREATE_BUFS>` ioctls.
+          :ref:`VIDIOC_REQBUFS` and/or
+          :ref:`VIDIOC_CREATE_BUFS` ioctls.
 
     -  .. row 3
 

index 457a6cc6b63e..e66f8c213535 100644
@@ -66,7 +66,7 @@ vertical scaling factor.
 Finally the driver programs the hardware with the actual cropping and
 image parameters. ``VIDIOC_S_CROP`` is a write-only ioctl, it does not
 return the actual parameters. To query them applications must call
-``VIDIOC_G_CROP`` and :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`. When the
+``VIDIOC_G_CROP`` and :ref:`VIDIOC_G_FMT`. When the
 parameters are unsuitable the application may modify the cropping or
 image parameters and repeat the cycle until satisfactory parameters have
 been negotiated.

index 6b2b157ba9c7..2c2677a76462 100644
@@ -48,7 +48,7 @@ actual new value. If the ``value`` is inappropriate for the control
 EINVAL error code is returned as well.
 
 These ioctls work only with user controls. For other control classes the
-:ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>`,
+:ref:`VIDIOC_G_EXT_CTRLS`,
 :ref:`VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` or
 :ref:`VIDIOC_TRY_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` must be used.
 

index 84f9db487822..8a7fa1c0facf 100644
@@ -47,7 +47,7 @@ values are not correct, the driver returns EINVAL error code.
 The ``linux/v4l2-dv-timings.h`` header can be used to get the timings of
 the formats in the :ref:`cea861` and :ref:`vesadmt` standards. If
 the current input or output does not support DV timings (e.g. if
-:ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>` does not set the
+:ref:`VIDIOC_ENUMINPUT` does not set the
 ``V4L2_IN_CAP_DV_TIMINGS`` flag), then ENODATA error code is returned.
 
 

index 26bbf060aa51..0bd8f1ba84d2 100644
@@ -44,8 +44,8 @@ with subdevice nodes (/dev/v4l-subdevX) or with video nodes
 
 When used with video nodes the ``pad`` field represents the input (for
 video capture devices) or output (for video output devices) index as is
-returned by :ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>` and
-:ref:`VIDIOC_ENUMOUTPUT <VIDIOC_ENUMOUTPUT>` respectively. When used
+returned by :ref:`VIDIOC_ENUMINPUT` and
+:ref:`VIDIOC_ENUMOUTPUT` respectively. When used
 with subdevice nodes the ``pad`` field represents the input or output
 pad of the subdevice. If there is no EDID support for the given ``pad``
 value, then the EINVAL error code will be returned.

@@ -105,8 +105,8 @@ EDID is no longer available.
 
        -  Pad for which to get/set the EDID blocks. When used with a video
           device node the pad represents the input or output index as
-          returned by :ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>` and
-          :ref:`VIDIOC_ENUMOUTPUT <VIDIOC_ENUMOUTPUT>` respectively.
+          returned by :ref:`VIDIOC_ENUMINPUT` and
+          :ref:`VIDIOC_ENUMOUTPUT` respectively.
 
     -  .. row 2
 

index f800458d9dfe..cebaa6ea1ba9 100644
@@ -58,7 +58,7 @@ set ``size`` to a valid value and return an ENOSPC error code. You
 should re-allocate the memory to this new size and try again. For the
 string type it is possible that the same issue occurs again if the
 string has grown in the meantime. It is recommended to call
-:ref:`VIDIOC_QUERYCTRL <VIDIOC_QUERYCTRL>` first and use
+:ref:`VIDIOC_QUERYCTRL` first and use
 ``maximum``\ +1 as the new ``size`` value. It is guaranteed that that is
 sufficient memory.
 

@@ -367,7 +367,7 @@ still cause this situation.
        -  The class containing user controls. These controls are described
           in :ref:`control`. All controls that can be set using the
           :ref:`VIDIOC_S_CTRL <VIDIOC_G_CTRL>` and
-          :ref:`VIDIOC_G_CTRL <VIDIOC_G_CTRL>` ioctl belong to this
+          :ref:`VIDIOC_G_CTRL` ioctl belong to this
           class.
 
     -  .. row 2

index f4703b3449b3..0d9b6972bc44 100644
@@ -39,7 +39,7 @@ to get and set the framebuffer parameters for a
 :ref:`Video Overlay <overlay>` or :ref:`Video Output Overlay <osd>`
 (OSD). The type of overlay is implied by the device type (capture or
 output device) and can be determined with the
-:ref:`VIDIOC_QUERYCAP <VIDIOC_QUERYCAP>` ioctl. One ``/dev/videoN``
+:ref:`VIDIOC_QUERYCAP` ioctl. One ``/dev/videoN``
 device must not support both kinds of overlay.
 
 The V4L2 API distinguishes destructive and non-destructive overlays. A

index 62990976ff9b..d0abf6231b7d 100644
@@ -47,7 +47,7 @@ applications must select an input before querying or negotiating any
 other parameters.
 
 Information about video inputs is available using the
-:ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>` ioctl.
+:ref:`VIDIOC_ENUMINPUT` ioctl.
 
 
 Return Value

index 3b9ea56e3b9e..a38d6a118cf4 100644
@@ -48,7 +48,7 @@ effects applications must select an output before querying or
 negotiating any other parameters.
 
 Information about video outputs is available using the
-:ref:`VIDIOC_ENUMOUTPUT <VIDIOC_ENUMOUTPUT>` ioctl.
+:ref:`VIDIOC_ENUMOUTPUT` ioctl.
 
 
 Return Value

index 9cbf2d2995c6..fa9da29e0657 100644
@@ -48,7 +48,7 @@ no flags are given or the current input does not support the requested
 standard the driver returns an EINVAL error code. When the standard set
 is ambiguous drivers may return EINVAL or choose any of the requested
 standards. If the current input or output does not support standard
-video timings (e.g. if :ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>`
+video timings (e.g. if :ref:`VIDIOC_ENUMINPUT`
 does not set the ``V4L2_IN_CAP_STD`` flag), then ENODATA error code is
 returned.
 

index 1ad5107a0ad5..1e01010fd2e2 100644
@@ -215,7 +215,7 @@ To change the radio frequency the
 
           The selected audio mode, see :ref:`tuner-audmode` for valid
           values. The audio mode does not affect audio subprogram detection,
-          and like a :ref:`control <control>` it does not automatically
+          and like a :ref:`control` it does not automatically
           change unless the requested mode is invalid or unsupported. See
           :ref:`tuner-matrix` for possible results when the selected and
           received audio programs do not match.

@@ -323,7 +323,7 @@ To change the radio frequency the
           determined from the frequency band.) The set of supported video
           standards is available from the struct
           :ref:`v4l2_input <v4l2-input>` pointing to this tuner, see the
-          description of ioctl :ref:`VIDIOC_ENUMINPUT <VIDIOC_ENUMINPUT>`
+          description of ioctl :ref:`VIDIOC_ENUMINPUT`
           for details. Only ``V4L2_TUNER_ANALOG_TV`` tuners can have this
           capability.
 

@@ -425,7 +425,7 @@ To change the radio frequency the
 
        -  0x0400
 
-       -  The :ref:`VIDIOC_ENUM_FREQ_BANDS <VIDIOC_ENUM_FREQ_BANDS>`
+       -  The :ref:`VIDIOC_ENUM_FREQ_BANDS`
           ioctl can be used to enumerate the available frequency bands.
 
     -  .. row 13

@@ -436,7 +436,7 @@ To change the radio frequency the
 
        -  The range to search when using the hardware seek functionality is
           programmable, see
-          :ref:`VIDIOC_S_HW_FREQ_SEEK <VIDIOC_S_HW_FREQ_SEEK>` for
+          :ref:`VIDIOC_S_HW_FREQ_SEEK` for
           details.
 
     -  .. row 14

index e0373a9d6f14..fe9084147b93 100644
@@ -36,7 +36,7 @@ Applications call ``VIDIOC_OVERLAY`` to start or stop the overlay. It
 takes a pointer to an integer which must be set to zero by the
 application to stop overlay, to one to start.
 
-Drivers do not support :ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` or
+Drivers do not support :ref:`VIDIOC_STREAMON` or
 :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` with
 ``V4L2_BUF_TYPE_VIDEO_OVERLAY``.
 

index 045fa53e0417..57a0bc470f36 100644
@@ -42,10 +42,10 @@ previously used with struct :ref:`v4l2_format <v4l2-format>` ``type``
 and struct :ref:`v4l2_requestbuffers <v4l2-requestbuffers>` ``type``.
 Applications must also set the ``index`` field. Valid index numbers
 range from zero to the number of buffers allocated with
-:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` (struct
+:ref:`VIDIOC_REQBUFS` (struct
 :ref:`v4l2_requestbuffers <v4l2-requestbuffers>` ``count``) minus
 one. The contents of the struct :c:type:`struct v4l2_buffer` returned
-by a :ref:`VIDIOC_QUERYBUF <VIDIOC_QUERYBUF>` ioctl will do as well.
+by a :ref:`VIDIOC_QUERYBUF` ioctl will do as well.
 When the buffer is intended for output (``type`` is
 ``V4L2_BUF_TYPE_VIDEO_OUTPUT``, ``V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE``,
 or ``V4L2_BUF_TYPE_VBI_OUTPUT``) applications must also initialize the

@@ -76,7 +76,7 @@ the driver sets the ``V4L2_BUF_FLAG_QUEUED`` flag and clears the
 memory pages of the buffer in physical memory, they cannot be swapped
 out to disk. Buffers remain locked until dequeued, until the
 :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` or
-:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl is called, or until the
+:ref:`VIDIOC_REQBUFS` ioctl is called, or until the
 device is closed.
 
 To enqueue a :ref:`DMABUF <dmabuf>` buffer applications set the

@@ -92,7 +92,7 @@ buffer. Locking a buffer means passing it to a driver for a hardware
 access (usually DMA). If an application accesses (reads/writes) a locked
 buffer then the result is undefined. Buffers remain locked until
 dequeued, until the :ref:`VIDIOC_STREAMOFF <VIDIOC_STREAMON>` or
-:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl is called, or until the
+:ref:`VIDIOC_REQBUFS` ioctl is called, or until the
 device is closed.
 
 Applications call the ``VIDIOC_DQBUF`` ioctl to dequeue a filled

index 88aedbd1fcae..ba78f7e5bbe8 100644
@@ -56,7 +56,7 @@ 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
 and returns ERANGE. In that case the application can call
-:ref:`VIDIOC_DV_TIMINGS_CAP <VIDIOC_DV_TIMINGS_CAP>` to compare the
+:ref:`VIDIOC_DV_TIMINGS_CAP` to compare the
 found timings with the hardware's capabilities in order to give more
 precise feedback to the user.
 

index baa3ad6591c7..744cd9da45a3 100644
@@ -33,7 +33,7 @@ Description
 
 This ioctl is part of the :ref:`streaming <mmap>` I/O method. It can
 be used to query the status of a buffer at any time after buffers have
-been allocated with the :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` ioctl.
+been allocated with the :ref:`VIDIOC_REQBUFS` ioctl.
 
 Applications set the ``type`` field of a struct
 :ref:`v4l2_buffer <v4l2-buffer>` to the same buffer type as was

@@ -41,7 +41,7 @@ previously used with struct :ref:`v4l2_format <v4l2-format>` ``type``
 and struct :ref:`v4l2_requestbuffers <v4l2-requestbuffers>` ``type``,
 and the ``index`` field. Valid index numbers range from zero to the
 number of buffers allocated with
-:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` (struct
+:ref:`VIDIOC_REQBUFS` (struct
 :ref:`v4l2_requestbuffers <v4l2-requestbuffers>` ``count``) minus
 one. The ``reserved`` and ``reserved2`` fields must be set to 0. When
 using the :ref:`multi-planar API <planar-apis>`, the ``m.planes``

index 3032a9ee1c6b..74589501b95d 100644
@@ -308,7 +308,7 @@ specification the ioctl returns an EINVAL error code.
        -  0x00000400
 
        -  The device supports the
-          :ref:`VIDIOC_S_HW_FREQ_SEEK <VIDIOC_S_HW_FREQ_SEEK>` ioctl
+          :ref:`VIDIOC_S_HW_FREQ_SEEK` ioctl
           for hardware frequency seeking.
 
     -  .. row 15

index 7d38a51c4f73..2b11efc3d257 100644
@@ -569,7 +569,7 @@ See also the examples in :ref:`control`.
           :ref:`VIDIOC_S_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` you need to
           set the ``size`` field of struct
           :ref:`v4l2_ext_control <v4l2-ext-control>` to 9. For
-          :ref:`VIDIOC_G_EXT_CTRLS <VIDIOC_G_EXT_CTRLS>` you can set
+          :ref:`VIDIOC_G_EXT_CTRLS` you can set
           the ``size`` field to ``maximum`` + 1. Which character encoding is
           used will depend on the string control itself and should be part
           of the control documentation.

index 19c2e0afd7de..cd59ba9ab1b0 100644
@@ -43,10 +43,10 @@ to tell the driver to search a specific band. If the struct
 :ref:`v4l2_tuner <v4l2-tuner>` ``capability`` field has the
 ``V4L2_TUNER_CAP_HWSEEK_PROG_LIM`` flag set, these values must fall
 within one of the bands returned by
-:ref:`VIDIOC_ENUM_FREQ_BANDS <VIDIOC_ENUM_FREQ_BANDS>`. If the
+:ref:`VIDIOC_ENUM_FREQ_BANDS`. If the
 ``V4L2_TUNER_CAP_HWSEEK_PROG_LIM`` flag is not set, then these values
 must exactly match those of one of the bands returned by
-:ref:`VIDIOC_ENUM_FREQ_BANDS <VIDIOC_ENUM_FREQ_BANDS>`. If the
+:ref:`VIDIOC_ENUM_FREQ_BANDS`. If the
 current frequency of the tuner does not fall within the selected band it
 will be clamped to fit in the band before the seek is started.
 

index 349204d81334..7663339d30be 100644
@@ -55,14 +55,14 @@ and it removes all buffers from the incoming and outgoing queues. That
 means all images captured but not dequeued yet will be lost, likewise
 all images enqueued for output but not transmitted yet. I/O returns to
 the same state as after calling
-:ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` and can be restarted
+:ref:`VIDIOC_REQBUFS` and can be restarted
 accordingly.
 
-If buffers have been queued with :ref:`VIDIOC_QBUF <VIDIOC_QBUF>` and
+If buffers have been queued with :ref:`VIDIOC_QBUF` and
 ``VIDIOC_STREAMOFF`` is called without ever having called
 ``VIDIOC_STREAMON``, then those queued buffers will also be removed from
 the incoming queue and all are returned to the same state as after
-calling :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>` and can be restarted
+calling :ref:`VIDIOC_REQBUFS` and can be restarted
 accordingly.
 
 Both ioctls take a pointer to an integer, the desired buffer or stream

index d9f27e32eb60..ab1368786038 100644
@@ -52,7 +52,7 @@ one until EINVAL is returned.
 
 Available frame intervals may depend on the current 'try' formats at
 other pads of the sub-device, as well as on the current active links.
-See :ref:`VIDIOC_SUBDEV_G_FMT <VIDIOC_SUBDEV_G_FMT>` for more
+See :ref:`VIDIOC_SUBDEV_G_FMT` for more
 information about the try formats.
 
 Sub-devices that support the frame interval enumeration ioctl should

index 49be2eefaa57..e08de6040757 100644
@@ -34,7 +34,7 @@ Description
 This ioctl allows applications to enumerate all frame sizes supported by
 a sub-device on the given pad for the given media bus format. Supported
 formats can be retrieved with the
-:ref:`VIDIOC_SUBDEV_ENUM_MBUS_CODE <VIDIOC_SUBDEV_ENUM_MBUS_CODE>`
+:ref:`VIDIOC_SUBDEV_ENUM_MBUS_CODE`
 ioctl.
 
 To enumerate frame sizes applications initialize the ``pad``, ``which``

@@ -58,7 +58,7 @@ sub-device for an exact supported frame size.
 Available frame sizes may depend on the current 'try' formats at other
 pads of the sub-device, as well as on the current active links and the
 current values of V4L2 controls. See
-:ref:`VIDIOC_SUBDEV_G_FMT <VIDIOC_SUBDEV_G_FMT>` for more
+:ref:`VIDIOC_SUBDEV_G_FMT` for more
 information about try formats.
 
 

index a9b0baba2633..0daf410c1546 100644
@@ -43,7 +43,7 @@ one until EINVAL is returned.
 
 Available media bus formats may depend on the current 'try' formats at
 other pads of the sub-device, as well as on the current active links.
-See :ref:`VIDIOC_SUBDEV_G_FMT <VIDIOC_SUBDEV_G_FMT>` for more
+See :ref:`VIDIOC_SUBDEV_G_FMT` for more
 information about the try formats.
 
 

index bef416cfe46c..6fb1ea143f9e 100644
@@ -36,7 +36,7 @@ Description
 
     **Note**
 
-    This is an :ref:`obsolete <obsolete>` interface and may be removed
+    This is an :ref:`obsolete` interface and may be removed
     in the future. It is superseded by
     :ref:`the selection API <VIDIOC_SUBDEV_G_SELECTION>`.
 

index 8d0e346461e9..182353f544eb 100644
@@ -33,7 +33,7 @@ Description
 ===========
 
 Subscribe or unsubscribe V4L2 event. Subscribed events are dequeued by
-using the :ref:`VIDIOC_DQEVENT <VIDIOC_DQEVENT>` ioctl.
+using the :ref:`VIDIOC_DQEVENT` ioctl.
 
 
 .. _v4l2-event-subscription:

index eb5c1522905d..c970a1fd1439 100644
@@ -75,23 +75,23 @@ To request different parameters applications set the ``type`` field of a
 struct :ref:`v4l2_format <v4l2-format>` as above and initialize all
 fields of the struct :ref:`v4l2_pix_format <v4l2-pix-format>`
 ``vbi`` member of the ``fmt`` union, or better just modify the results
-of ``VIDIOC_G_FMT``, and call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
+of :ref:`VIDIOC_G_FMT`, and call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
 ioctl with a pointer to this structure. Drivers may adjust the
-parameters and finally return the actual parameters as ``VIDIOC_G_FMT``
+parameters and finally return the actual parameters as :ref:`VIDIOC_G_FMT`
 does.
 
-Like ``VIDIOC_S_FMT`` the :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl
+Like :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` the :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl
 can be used to learn about hardware limitations without disabling I/O or
 possibly time consuming hardware preparations.
 
 The contents of struct :ref:`v4l2_pix_format <v4l2-pix-format>` and
 struct :ref:`v4l2_pix_format_mplane <v4l2-pix-format-mplane>` are
 discussed in :ref:`pixfmt`. See also the specification of the
-``VIDIOC_G_FMT``, ``VIDIOC_S_FMT`` and ``VIDIOC_TRY_FMT`` ioctls for
-details. Video capture devices must implement both the ``VIDIOC_G_FMT``
-and ``VIDIOC_S_FMT`` ioctl, even if ``VIDIOC_S_FMT`` ignores all
-requests and always returns default parameters as ``VIDIOC_G_FMT`` does.
-``VIDIOC_TRY_FMT`` is optional.
+:ref:`VIDIOC_G_FMT`, :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` and :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctls for
+details. Video capture devices must implement both the :ref:`VIDIOC_G_FMT`
+and :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, even if :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ignores all
+requests and always returns default parameters as :ref:`VIDIOC_G_FMT` does.
+:ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` is optional.
 
 
 Reading Images

index 27d2cfbf3d9c..4b668a3544b8 100644
@@ -124,10 +124,10 @@ struct :ref:`v4l2_format <v4l2-format>` to
 ``V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY``, initialize the ``win``
 substructure and call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl.
 The driver adjusts the parameters against hardware limits and returns
-the actual parameters as ``VIDIOC_G_FMT`` does. Like ``VIDIOC_S_FMT``,
+the actual parameters as :ref:`VIDIOC_G_FMT` does. Like :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`,
 the :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl can be used to learn
 about driver capabilities without actually changing driver state. Unlike
-``VIDIOC_S_FMT`` this also works after the overlay has been enabled.
+:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` this also works after the overlay has been enabled.
 
 A struct :ref:`v4l2_crop <v4l2-crop>` defines the size and position
 of the target rectangle. The scaling factor of the overlay is implied by

index 1ca0e5873a86..ee62d1a0fb87 100644
@@ -72,23 +72,23 @@ To request different parameters applications set the ``type`` field of a
 struct :ref:`v4l2_format <v4l2-format>` as above and initialize all
 fields of the struct :ref:`v4l2_pix_format <v4l2-pix-format>`
 ``vbi`` member of the ``fmt`` union, or better just modify the results
-of ``VIDIOC_G_FMT``, and call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
+of :ref:`VIDIOC_G_FMT`, and call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
 ioctl with a pointer to this structure. Drivers may adjust the
-parameters and finally return the actual parameters as ``VIDIOC_G_FMT``
+parameters and finally return the actual parameters as :ref:`VIDIOC_G_FMT`
 does.
 
-Like ``VIDIOC_S_FMT`` the :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl
+Like :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` the :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl
 can be used to learn about hardware limitations without disabling I/O or
 possibly time consuming hardware preparations.
 
 The contents of struct :ref:`v4l2_pix_format <v4l2-pix-format>` and
 struct :ref:`v4l2_pix_format_mplane <v4l2-pix-format-mplane>` are
 discussed in :ref:`pixfmt`. See also the specification of the
-``VIDIOC_G_FMT``, ``VIDIOC_S_FMT`` and ``VIDIOC_TRY_FMT`` ioctls for
-details. Video output devices must implement both the ``VIDIOC_G_FMT``
-and ``VIDIOC_S_FMT`` ioctl, even if ``VIDIOC_S_FMT`` ignores all
-requests and always returns default parameters as ``VIDIOC_G_FMT`` does.
-``VIDIOC_TRY_FMT`` is optional.
+:ref:`VIDIOC_G_FMT`, :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` and :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctls for
+details. Video output devices must implement both the :ref:`VIDIOC_G_FMT`
+and :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, even if :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ignores all
+requests and always returns default parameters as :ref:`VIDIOC_G_FMT` does.
+:ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` is optional.
 
 
 Writing Images

index acbcfb4cbe57..26bd4a15a125 100644
@@ -65,7 +65,7 @@ frame buffer parameters, namely the address and size of the frame buffer
 and the image format, for example RGB 5:6:5. The
 :ref:`VIDIOC_G_FBUF` and
 :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>` ioctls are available to get and
-set these parameters, respectively. The ``VIDIOC_S_FBUF`` ioctl is
+set these parameters, respectively. The :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>` ioctl is
 privileged because it allows to set up DMA into physical memory,
 bypassing the memory protection mechanisms of the kernel. Only the
 superuser can change the frame buffer address and size. Users are not

@@ -76,8 +76,8 @@ system and program the V4L2 driver at the appropriate time.
 Some devices add the video overlay to the output signal of the graphics
 card. In this case the frame buffer is not modified by the video device,
 and the frame buffer address and pixel format are not needed by the
-driver. The ``VIDIOC_S_FBUF`` ioctl is not privileged. An application
-can check for this type of device by calling the ``VIDIOC_G_FBUF``
+driver. The :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>` ioctl is not privileged. An application
+can check for this type of device by calling the :ref:`VIDIOC_G_FBUF`
 ioctl.
 
 A driver may support any (or none) of five clipping/blending methods:

@@ -130,10 +130,10 @@ struct :ref:`v4l2_format <v4l2-format>` to
 ``V4L2_BUF_TYPE_VIDEO_OVERLAY``, initialize the ``win`` substructure and
 call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl. The driver
 adjusts the parameters against hardware limits and returns the actual
-parameters as ``VIDIOC_G_FMT`` does. Like ``VIDIOC_S_FMT``, the
+parameters as :ref:`VIDIOC_G_FMT` does. Like :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`, the
 :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl can be used to learn
 about driver capabilities without actually changing driver state. Unlike
-``VIDIOC_S_FMT`` this also works after the overlay has been enabled.
+:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` this also works after the overlay has been enabled.
 
 The scaling factor of the overlaid image is implied by the width and
 height given in struct :ref:`v4l2_window <v4l2-window>` and the size

@@ -199,7 +199,7 @@ are undefined.
     When the application set the ``clips`` field, this field must
     contain the number of clipping rectangles in the list. When clip
     lists are not supported the driver ignores this field, its contents
-    after calling ``VIDIOC_S_FMT`` are undefined. When clip lists are
+    after calling :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` are undefined. When clip lists are
     supported but no clipping is desired this field must be set to zero.
 
 ``void * bitmap``

index ca61dde3ad38..2cd813a5b4e4 100644
@@ -80,7 +80,7 @@ To request different parameters applications set the ``type`` field of a
 struct :ref:`v4l2_format <v4l2-format>` as above and initialize all
 fields of the struct :ref:`v4l2_vbi_format <v4l2-vbi-format>`
 ``vbi`` member of the ``fmt`` union, or better just modify the results
-of ``VIDIOC_G_FMT``, and call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
+of :ref:`VIDIOC_G_FMT`, and call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
 ioctl with a pointer to this structure. Drivers return an EINVAL error
 code only when the given parameters are ambiguous, otherwise they modify
 the parameters according to the hardware capabilities and return the

@@ -94,10 +94,10 @@ expect other resource allocation points which may return EBUSY, at the
 :ref:`VIDIOC_STREAMON` ioctl and the first read(),
 write() and select() call.
 
-VBI devices must implement both the ``VIDIOC_G_FMT`` and
-``VIDIOC_S_FMT`` ioctl, even if ``VIDIOC_S_FMT`` ignores all requests
-and always returns default parameters as ``VIDIOC_G_FMT`` does.
-``VIDIOC_TRY_FMT`` is optional.
+VBI devices must implement both the :ref:`VIDIOC_G_FMT` and
+:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, even if :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ignores all requests
+and always returns default parameters as :ref:`VIDIOC_G_FMT` does.
+:ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` is optional.
 
 
 .. _v4l2-vbi-format:

index 46f740a0092e..0184b5931709 100644
@@ -31,10 +31,10 @@ format. The data formats supported by the V4L2 API are covered in the
 respective device section in :ref:`devices`. For a closer look at
 image formats see :ref:`pixfmt`.
 
-The ``VIDIOC_S_FMT`` ioctl is a major turning-point in the
+The :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl is a major turning-point in the
 initialization sequence. Prior to this point multiple panel applications
 can access the same device concurrently to select the current input,
-change controls or modify other properties. The first ``VIDIOC_S_FMT``
+change controls or modify other properties. The first :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
 assigns a logical stream (video data, VBI data etc.) exclusively to one
 file descriptor.
 

@@ -50,7 +50,7 @@ example video overlay is about to start or already in progress,
 simultaneous video capturing may be restricted to the same cropping and
 image size.
 
-When applications omit the ``VIDIOC_S_FMT`` ioctl its locking side
+When applications omit the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl its locking side
 effects are implied by the next step, the selection of an I/O method
 with the :ref:`VIDIOC_REQBUFS` ioctl or implicit
 with the first :ref:`read() <func-read>` or

@@ -61,11 +61,11 @@ the exception being drivers permitting simultaneous video capturing and
 overlay using the same file descriptor for compatibility with V4L and
 earlier versions of V4L2. Switching the logical stream or returning into
 "panel mode" is possible by closing and reopening the device. Drivers
-*may* support a switch using ``VIDIOC_S_FMT``.
+*may* support a switch using :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`.
 
 All drivers exchanging data with applications must support the
-``VIDIOC_G_FMT`` and ``VIDIOC_S_FMT`` ioctl. Implementation of the
-``VIDIOC_TRY_FMT`` is highly recommended but optional.
+:ref:`VIDIOC_G_FMT` and :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl. Implementation of the
+:ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` is highly recommended but optional.
 
 
 Image Format Enumeration

index 651d4530c703..77d13fdd1c28 100644
@@ -31,7 +31,7 @@ and drivers permitting simultaneous video capturing and overlay using
 the same file descriptor, for compatibility with V4L and earlier
 versions of V4L2.
 
-``VIDIOC_S_FMT`` and ``VIDIOC_REQBUFS`` would permit this to some
+:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` and :ref:`VIDIOC_REQBUFS` would permit this to some
 degree, but for simplicity drivers need not support switching the I/O
 method (after first switching away from read/write) other than by
 closing and reopening the device.

index 4890815e268e..1a8f4d09bff1 100644
@@ -50,7 +50,7 @@ The composing targets refer to a memory buffer. The limits of composing
 coordinates are obtained using ``V4L2_SEL_TGT_COMPOSE_BOUNDS``. All
 coordinates are expressed in pixels. The rectangle's top/left corner
 must be located at position ``(0,0)``. The width and height are equal to
-the image size set by ``VIDIOC_S_FMT``.
+the image size set by :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`.
 
 The part of a buffer into which the image is inserted by the hardware is
 controlled by the ``V4L2_SEL_TGT_COMPOSE`` target. The rectangle's

@@ -90,7 +90,7 @@ to be inserted into a video signal or graphical screen. The limits of
 cropping coordinates are obtained using ``V4L2_SEL_TGT_CROP_BOUNDS``.
 All coordinates are expressed in pixels. The top/left corner is always
 point ``(0,0)``. The width and height is equal to the image size
-specified using ``VIDIOC_S_FMT`` ioctl.
+specified using :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl.
 
 The top left corner, width and height of the source rectangle, that is
 the area from which image date are processed by the hardware, is given

index aefab87788db..6fdb0af2b13d 100644
@@ -19,7 +19,7 @@ setting the field struct
 :ref:`v4l2_pix_format <v4l2-pix-format>```::bytesperline``.
 Introducing an image offsets could be done by modifying field struct
 :ref:`v4l2_buffer <v4l2-buffer>```::m_userptr`` before calling
-``VIDIOC_QBUF``. Those operations should be avoided because they are not
+:ref:`VIDIOC_QBUF`. Those operations should be avoided because they are not
 portable (endianness), and do not work for macroblock and Bayer formats
 and mmap buffers. The selection API deals with configuration of buffer
 cropping/composing in a clear, intuitive and portable way. Next, with

index 3c0f6cb97f13..ec39b2b39e67 100644
@@ -56,8 +56,8 @@ output device which is:
 
 Here the driver shall set the ``std`` field of struct
 :ref:`v4l2_input <v4l2-input>` and struct
-:ref:`v4l2_output <v4l2-output>` to zero and the ``VIDIOC_G_STD``,
-``VIDIOC_S_STD``, ``VIDIOC_QUERYSTD`` and ``VIDIOC_ENUMSTD`` ioctls
+:ref:`v4l2_output <v4l2-output>` to zero and the :ref:`VIDIOC_G_STD`,
+:ref:`VIDIOC_S_STD <VIDIOC_G_STD>`, :ref:`VIDIOC_QUERYSTD` and :ref:`VIDIOC_ENUMSTD` ioctls
 shall return the ENOTTY error code or the EINVAL error code.
 
 Applications can make use of the :ref:`input-capabilities` and

index b1be27bd297e..67f4e24709b5 100644
@@ -24,9 +24,9 @@ inputs.
 To query and change tuner properties applications use the
 :ref:`VIDIOC_G_TUNER` and
 :ref:`VIDIOC_S_TUNER <VIDIOC_G_TUNER>` ioctls, respectively. The
-struct :ref:`v4l2_tuner <v4l2-tuner>` returned by ``VIDIOC_G_TUNER``
+struct :ref:`v4l2_tuner <v4l2-tuner>` returned by :ref:`VIDIOC_G_TUNER`
 also contains signal status information applicable when the tuner of the
-current video or radio input is queried. Note that ``VIDIOC_S_TUNER``
+current video or radio input is queried. Note that :ref:`VIDIOC_S_TUNER <VIDIOC_G_TUNER>`
 does not switch the current tuner, when there is more than one at all.
 The tuner is solely determined by the current video input. Drivers must
 support both ioctls and set the ``V4L2_CAP_TUNER`` flag in the struct

@@ -61,7 +61,7 @@ cannot specify whether the frequency is for a tuner or a modulator.
 To query and change modulator properties applications use the
 :ref:`VIDIOC_G_MODULATOR` and
 :ref:`VIDIOC_S_MODULATOR <VIDIOC_G_MODULATOR>` ioctl. Note that
-``VIDIOC_S_MODULATOR`` does not switch the current modulator, when there
+:ref:`VIDIOC_S_MODULATOR <VIDIOC_G_MODULATOR>` does not switch the current modulator, when there
 is more than one at all. The modulator is solely determined by the
 current video output. Drivers must support both ioctls and set the
 ``V4L2_CAP_MODULATOR`` flag in the struct

index 9220bcea1259..d269eab4d2b6 100644
@@ -94,10 +94,10 @@ than the number requested.
        -  ``count``
 
        -  The number of buffers requested or granted. If count == 0, then
-          ``VIDIOC_CREATE_BUFS`` will set ``index`` to the current number of
+          :ref:`VIDIOC_CREATE_BUFS` will set ``index`` to the current number of
           created buffers, and it will check the validity of ``memory`` and
           ``format.type``. If those are invalid -1 is returned and errno is
-          set to EINVAL error code, otherwise ``VIDIOC_CREATE_BUFS`` returns
+          set to EINVAL error code, otherwise :ref:`VIDIOC_CREATE_BUFS` returns
           0. It will never set errno to EBUSY error code in this particular
           case.
 

index 22b5efe1d2e4..25ad9b29b160 100644
@@ -34,7 +34,7 @@ Description
 Applications use this function to query the cropping limits, the pixel
 aspect of images and to calculate scale factors. They set the ``type``
 field of a v4l2_cropcap structure to the respective buffer (stream)
-type and call the ``VIDIOC_CROPCAP`` ioctl with a pointer to this
+type and call the :ref:`VIDIOC_CROPCAP` ioctl with a pointer to this
 structure. Drivers fill the rest of the structure. The results are
 constant except when switching the video standard. Remember this switch
 can occur implicit when switching the video input or output.

index 12c2e5df48ac..a1534a326bb3 100644
@@ -49,14 +49,14 @@ Additionally the Linux kernel must be compiled with the
 To query the driver applications must initialize the ``match.type`` and
 ``match.addr`` or ``match.name`` fields of a struct
 :ref:`v4l2_dbg_chip_info <v4l2-dbg-chip-info>` and call
-``VIDIOC_DBG_G_CHIP_INFO`` with a pointer to this structure. On success
+:ref:`VIDIOC_DBG_G_CHIP_INFO` with a pointer to this structure. On success
 the driver stores information about the selected chip in the ``name``
 and ``flags`` fields.
 
 When ``match.type`` is ``V4L2_CHIP_MATCH_BRIDGE``, ``match.addr``
 selects the nth bridge 'chip' on the TV card. You can enumerate all
 chips by starting at zero and incrementing ``match.addr`` by one until
-``VIDIOC_DBG_G_CHIP_INFO`` fails with an EINVAL error code. The number
+:ref:`VIDIOC_DBG_G_CHIP_INFO` fails with an EINVAL error code. The number
 zero always selects the bridge chip itself, e. g. the chip connected to
 the PCI or USB bus. Non-zero numbers identify specific parts of the
 bridge chip such as an AC97 register block.

index f4fc2723f01e..c838f3dbb808 100644
@@ -33,7 +33,7 @@ Description
 
 To enumerate image formats applications initialize the ``type`` and
 ``index`` field of struct :ref:`v4l2_fmtdesc <v4l2-fmtdesc>` and call
-the ``VIDIOC_ENUM_FMT`` ioctl with a pointer to this structure. Drivers
+the :ref:`VIDIOC_ENUM_FMT` ioctl with a pointer to this structure. Drivers
 fill the rest of the structure or return an EINVAL error code. All
 formats are enumerable by beginning at index zero and incrementing by
 one until EINVAL is returned.

index 2f5dbe0583b4..3999c419589a 100644
@@ -35,7 +35,7 @@ Enumerates the frequency bands that a tuner or modulator supports. To do
 this applications initialize the ``tuner``, ``type`` and ``index``
 fields, and zero out the ``reserved`` array of a struct
 :ref:`v4l2_frequency_band <v4l2-frequency-band>` and call the
-``VIDIOC_ENUM_FREQ_BANDS`` ioctl with a pointer to this structure.
+:ref:`VIDIOC_ENUM_FREQ_BANDS` ioctl with a pointer to this structure.
 
 This ioctl is supported if the ``V4L2_TUNER_CAP_FREQ_BANDS`` capability
 of the corresponding tuner/modulator is set.

index dcca0591864e..0fc0c3eeae5f 100644
@@ -33,7 +33,7 @@ Description
 
 To query the attributes of an audio input applications initialize the
 ``index`` field and zero out the ``reserved`` array of a struct
-:ref:`v4l2_audio <v4l2-audio>` and call the ``VIDIOC_ENUMAUDIO``
+:ref:`v4l2_audio <v4l2-audio>` and call the :ref:`VIDIOC_ENUMAUDIO`
 ioctl with a pointer to this structure. Drivers fill the rest of the
 structure or return an EINVAL error code when the index is out of
 bounds. To enumerate all audio inputs applications shall begin at index

index 644d50679aa2..131f331462b1 100644
@@ -33,7 +33,7 @@ Description
 
 To query the attributes of a video input applications initialize the
 ``index`` field of struct :ref:`v4l2_input <v4l2-input>` and call the
-``VIDIOC_ENUMINPUT`` ioctl with a pointer to this structure. Drivers
+:ref:`VIDIOC_ENUMINPUT` ioctl with a pointer to this structure. Drivers
 fill the rest of the structure or return an EINVAL error code when the
 index is out of bounds. To enumerate all inputs applications shall begin
 at index zero, incrementing by one until the driver returns EINVAL.

index 6ccb3d094dc8..cb0107b9c03b 100644
@@ -33,7 +33,7 @@ Description
 
 To query the attributes of a video outputs applications initialize the
 ``index`` field of struct :ref:`v4l2_output <v4l2-output>` and call
-the ``VIDIOC_ENUMOUTPUT`` ioctl with a pointer to this structure.
+the :ref:`VIDIOC_ENUMOUTPUT` ioctl with a pointer to this structure.
 Drivers fill the rest of the structure or return an EINVAL error code
 when the index is out of bounds. To enumerate all outputs applications
 shall begin at index zero, incrementing by one until the driver returns

index d16a9494d03b..e292b7d50cc3 100644
@@ -33,7 +33,7 @@ Description
 
 To query the attributes of a video standard, especially a custom (driver
 defined) one, applications initialize the ``index`` field of struct
-:ref:`v4l2_standard <v4l2-standard>` and call the ``VIDIOC_ENUMSTD``
+:ref:`v4l2_standard <v4l2-standard>` and call the :ref:`VIDIOC_ENUMSTD`
 ioctl with a pointer to this structure. Drivers fill the rest of the
 structure or return an EINVAL error code when the index is out of
 bounds. To enumerate all standards applications shall begin at index

@@ -401,7 +401,7 @@ ENODATA
 
 .. [1]
    The supported standards may overlap and we need an unambiguous set to
-   find the current standard returned by ``VIDIOC_G_STD``.
+   find the current standard returned by :ref:`VIDIOC_G_STD`.
 
 .. [2]
    Japan uses a standard similar to M/NTSC (V4L2_STD_NTSC_M_JP).

index e71925f3f13e..2933640e8c4e 100644
@@ -53,9 +53,9 @@ Additional flags may be posted in the ``flags`` field. Refer to a manual
 for open() for details. Currently only O_CLOEXEC, O_RDONLY, O_WRONLY,
 and O_RDWR are supported. All other fields must be set to zero. In the
 case of multi-planar API, every plane is exported separately using
-multiple ``VIDIOC_EXPBUF`` calls.
+multiple :ref:`VIDIOC_EXPBUF` calls.
 
-After calling ``VIDIOC_EXPBUF`` the ``fd`` field will be set by a
+After calling :ref:`VIDIOC_EXPBUF` the ``fd`` field will be set by a
 driver. This is a DMABUF file descriptor. The application may pass it to
 other DMABUF-aware devices. Refer to :ref:`DMABUF importing <dmabuf>`
 for details about importing DMABUF files into V4L2 nodes. It is

index 2a81d01a1c00..be8899d87e33 100644
@@ -36,14 +36,14 @@ Description
 
 To query the current audio input applications zero out the ``reserved``
 array of a struct :ref:`v4l2_audio <v4l2-audio>` and call the
-``VIDIOC_G_AUDIO`` ioctl with a pointer to this structure. Drivers fill
+:ref:`VIDIOC_G_AUDIO` ioctl with a pointer to this structure. Drivers fill
 the rest of the structure or return an EINVAL error code when the device
 has no audio inputs, or none which combine with the current video input.
 
 Audio inputs have one writable property, the audio mode. To select the
 current audio input *and* change the audio mode, applications initialize
 the ``index`` and ``mode`` fields, and the ``reserved`` array of a
-:c:type:`struct v4l2_audio` structure and call the ``VIDIOC_S_AUDIO``
+:c:type:`struct v4l2_audio` structure and call the :ref:`VIDIOC_S_AUDIO <VIDIOC_G_AUDIO>`
 ioctl. Drivers may switch to a different audio mode if the request
 cannot be satisfied. However, this is a write-only ioctl, it does not
 return the actual new audio mode.

@@ -90,7 +90,7 @@ return the actual new audio mode.
        -  ``mode``
 
        -  Audio mode flags set by drivers and applications (on
-          ``VIDIOC_S_AUDIO`` ioctl), see :ref:`audio-mode`.
+          :ref:`VIDIOC_S_AUDIO <VIDIOC_G_AUDIO>` ioctl), see :ref:`audio-mode`.
 
     -  .. row 5
 

index e66f8c213535..0a9ede92bc9f 100644
@@ -36,13 +36,13 @@ Description
 
 To query the cropping rectangle size and position applications set the
 ``type`` field of a :c:type:`struct v4l2_crop` structure to the
-respective buffer (stream) type and call the ``VIDIOC_G_CROP`` ioctl
+respective buffer (stream) type and call the :ref:`VIDIOC_G_CROP` ioctl
 with a pointer to this structure. The driver fills the rest of the
 structure or returns the EINVAL error code if cropping is not supported.
 
 To change the cropping rectangle applications initialize the ``type``
 and struct :ref:`v4l2_rect <v4l2-rect>` substructure named ``c`` of a
-v4l2_crop structure and call the ``VIDIOC_S_CROP`` ioctl with a pointer
+v4l2_crop structure and call the :ref:`VIDIOC_S_CROP <VIDIOC_G_CROP>` ioctl with a pointer
 to this structure.
 
 Do not use the multiplanar buffer types. Use

@@ -64,15 +64,15 @@ the closest size possible while maintaining the current horizontal and
 vertical scaling factor.
 
 Finally the driver programs the hardware with the actual cropping and
-image parameters. ``VIDIOC_S_CROP`` is a write-only ioctl, it does not
+image parameters. :ref:`VIDIOC_S_CROP <VIDIOC_G_CROP>` is a write-only ioctl, it does not
 return the actual parameters. To query them applications must call
-``VIDIOC_G_CROP`` and :ref:`VIDIOC_G_FMT`. When the
+:ref:`VIDIOC_G_CROP` and :ref:`VIDIOC_G_FMT`. When the
 parameters are unsuitable the application may modify the cropping or
 image parameters and repeat the cycle until satisfactory parameters have
 been negotiated.
 
 When cropping is not supported then no parameters are changed and
-``VIDIOC_S_CROP`` returns the EINVAL error code.
+:ref:`VIDIOC_S_CROP <VIDIOC_G_CROP>` returns the EINVAL error code.
 
 
 .. _v4l2-crop:

index 2c2677a76462..41561c5e444d 100644
@@ -34,15 +34,15 @@ Description
 
 To get the current value of a control applications initialize the ``id``
 field of a struct :c:type:`struct v4l2_control` and call the
-``VIDIOC_G_CTRL`` ioctl with a pointer to this structure. To change the
+:ref:`VIDIOC_G_CTRL` ioctl with a pointer to this structure. To change the
 value of a control applications initialize the ``id`` and ``value``
 fields of a struct :c:type:`struct v4l2_control` and call the
-``VIDIOC_S_CTRL`` ioctl.
+:ref:`VIDIOC_S_CTRL <VIDIOC_G_CTRL>` ioctl.
 
 When the ``id`` is invalid drivers return an EINVAL error code. When the
 ``value`` is out of bounds drivers can choose to take the closest valid
 value or return an ERANGE error code, whatever seems more appropriate.
-However, ``VIDIOC_S_CTRL`` is a write-only ioctl, it does not return the
+However, :ref:`VIDIOC_S_CTRL <VIDIOC_G_CTRL>` is a write-only ioctl, it does not return the
 actual new value. If the ``value`` is inappropriate for the control
 (e.g. if it refers to an unsupported menu index of a menu control), then
 EINVAL error code is returned as well.