Fix most of Sphinx warnings in nitpick mode

index 93721f3c91bf..3db6e6ac83f1 100755
@@ -1857,14 +1857,15 @@ sub output_function_rst(%) {
 	if ($count ne 0) {
 	    print ", ";
 	}
-	$count++;
 	$type = $args{'parametertypes'}{$parameter};
 
 	if ($type =~ m/([^\(]*\(\*)\s*\)\s*\(([^\)]*)\)/) {
 	    # pointer-to-function
 	    print $1 . $parameter . ") (" . $2;
-	} else {
+	    $count++;
+	} elsif ($type ne "") {
 	    print $type . " " . $parameter;
+	    $count++;
 	}
     }
     if ($args{'typedef'}) {

index 74089b0da798..531c710fc73f 100755
@@ -2,12 +2,18 @@
 use strict;
 use Text::Tabs;
 
-# Uncomment if debug is needed
-#use Data::Dumper;
-
-# change to 1 to generate some debug prints
 my $debug = 0;
 
+while ($ARGV[0] =~ m/^-(.*)/) {
+	my $cmd = shift @ARGV;
+	if ($cmd eq "--debug") {
+		require Data::Dumper;
+		$debug = 1;
+		next;
+	}
+	die "argument $cmd unknown";
+}
+
 if (scalar @ARGV < 2 || scalar @ARGV > 3) {
 	die "Usage:\n\t$0 <file in> <file out> [<exceptions file>]\n";
 }

index 531c710fc73f..db0186a7618f 100755
@@ -57,7 +57,7 @@ while (<IN>) {
 		$n =~ tr/A-Z/a-z/;
 		$n =~ tr/_/-/;
 
-		$enum_symbols{$s} = $n;
+		$enum_symbols{$s} =  "\\ :ref:`$s <$n>`\\ ";
 
 		$is_enum = 0 if ($is_enum && m/\}/);
 		next;

@@ -69,7 +69,7 @@ while (<IN>) {
 		my $n = $1;
 		$n =~ tr/A-Z/a-z/;
 
-		$ioctls{$s} = $n;
+		$ioctls{$s} = "\\ :ref:`$s <$n>`\\ ";
 		next;
 	}
 

@@ -79,17 +79,15 @@ while (<IN>) {
 		$n =~ tr/A-Z/a-z/;
 		$n =~ tr/_/-/;
 
-		$defines{$s} = $n;
+		$defines{$s} = "\\ :ref:`$s <$n>`\\ ";
 		next;
 	}
 
-	if ($ln =~ m/^\s*typedef\s+.*\s+([_\w][\w\d_]+);/) {
-		my $s = $1;
-		my $n = $1;
-		$n =~ tr/A-Z/a-z/;
-		$n =~ tr/_/-/;
+	if ($ln =~ m/^\s*typedef\s+([_\w][\w\d_]+)\s+(.*)\s+([_\w][\w\d_]+);/) {
+		my $s = $2;
+		my $n = $3;
 
-		$typedefs{$s} = $n;
+		$typedefs{$n} = "\\ :c:type:`$n <$s>`\\ ";
 		next;
 	}
 	if ($ln =~ m/^\s*enum\s+([_\w][\w\d_]+)\s+\{/

@@ -97,11 +95,8 @@ while (<IN>) {
 	    || $ln =~ m/^\s*typedef\s*enum\s+([_\w][\w\d_]+)\s+\{/
 	    || $ln =~ m/^\s*typedef\s*enum\s+([_\w][\w\d_]+)$/) {
 		my $s = $1;
-		my $n = $1;
-		$n =~ tr/A-Z/a-z/;
-		$n =~ tr/_/-/;
 
-		$enums{$s} = $n;
+		$enums{$s} =  "enum :c:type:`$s`\\ ";
 
 		$is_enum = $1;
 		next;

@@ -112,11 +107,8 @@ while (<IN>) {
 	    || $ln =~ m/^\s*typedef\s*struct\s+([[_\w][\w\d_]+)$/
 	    ) {
 		my $s = $1;
-		my $n = $1;
-		$n =~ tr/A-Z/a-z/;
-		$n =~ tr/_/-/;
 
-		$structs{$s} = $n;
+		$structs{$s} = "struct :c:type:`$s`\\ ";
 		next;
 	}
 }

@@ -129,12 +121,9 @@ close IN;
 my @matches = ($data =~ m/typedef\s+struct\s+\S+?\s*\{[^\}]+\}\s*(\S+)\s*\;/g,
 	       $data =~ m/typedef\s+enum\s+\S+?\s*\{[^\}]+\}\s*(\S+)\s*\;/g,);
 foreach my $m (@matches) {
-		my $s = $m;
-		my $n = $m;
-		$n =~ tr/A-Z/a-z/;
-		$n =~ tr/_/-/;
+	my $s = $m;
 
-		$typedefs{$s} = $n;
+	$typedefs{$s} = "\\ :c:type:`$s`\\ ";
 	next;
 }
 

@@ -142,6 +131,15 @@ foreach my $m (@matches) {
 # Handle exceptions, if any
 #
 
+my %def_reftype = (
+	"ioctl"   => ":ref",
+	"define"  => ":ref",
+	"symbol"  => ":ref",
+	"typedef" => ":c:type",
+	"enum"    => ":c:type",
+	"struct"  => ":c:type",
+);
+
 if ($file_exceptions) {
 	open IN, $file_exceptions or die "Can't read $file_exceptions";
 	while (<IN>) {

@@ -175,29 +173,49 @@ if ($file_exceptions) {
 		}
 
 		# Parsers to replace a symbol
+		my ($type, $old, $new, $reftype);
 
-		if (m/^replace\s+ioctl\s+(\S+)\s+(\S+)/) {
-			$ioctls{$1} = $2 if (exists($ioctls{$1}));
+		if (m/^replace\s+(\S+)\s+(\S+)\s+(\S+)/) {
+			$type = $1;
+			$old = $2;
+			$new = $3;
+		} else {
+			die "Can't parse $file_exceptions: $_";
+		}
+
+		if ($new =~ m/^\:c\:(data|func|macro|type)\:\`(.+)\`/) {
+			$reftype = ":c:$1";
+			$new = $2;
+		} elsif ($new =~ m/\:ref\:\`(.+)\`/) {
+			$reftype = ":ref";
+			$new = $1;
+		} else {
+			$reftype = $def_reftype{$type};
+		}
+		$new = "$reftype:`$old <$new>`";
+
+		if ($type eq "ioctl") {
+			$ioctls{$old} = $new if (exists($ioctls{$old}));
 			next;
 		}
-		if (m/^replace\s+define\s+(\S+)\s+(\S+)/) {
-			$defines{$1} = $2 if (exists($defines{$1}));
+		if ($type eq "define") {
+			$defines{$old} = $new if (exists($defines{$old}));
 			next;
 		}
-		if (m/^replace\s+typedef\s+(\S+)\s+(\S+)/) {
-			$typedefs{$1} = $2 if (exists($typedefs{$1}));
+		if ($type eq "symbol") {
+			$enum_symbols{$old} = $new if (exists($enum_symbols{$old}));
 			next;
 		}
-		if (m/^replace\s+enum\s+(\S+)\s+(\S+)/) {
-			$enums{$1} = $2 if (exists($enums{$1}));
+		if ($type eq "typedef") {
+			$typedefs{$old} = $new if (exists($typedefs{$old}));
 			next;
 		}
-		if (m/^replace\s+symbol\s+(\S+)\s+(\S+)/) {
-			$enum_symbols{$1} = $2 if (exists($enum_symbols{$1}));
+		if ($type eq "enum") {
+			$enums{$old} = $new if (exists($enums{$old}));
 			next;
 		}
-		if (m/^replace\s+struct\s+(\S+)\s+(\S+)/) {
-			$structs{$1} = $2 if (exists($structs{$1}));
+		if ($type eq "struct") {
+			$structs{$old} = $new if (exists($structs{$old}));
 			next;
 		}
 

@@ -238,9 +256,7 @@ my $start_delim = "[ \n\t\(\=\*\@]";
 my $end_delim = "(\\s|,|\\\\=|\\\\:|\\;|\\\)|\\}|\\{)";
 
 foreach my $r (keys %ioctls) {
-	my $n = $ioctls{$r};
-
-	my $s = "\\ :ref:`$r <$n>`\\ ";
+	my $s = $ioctls{$r};
 
 	$r =~ s,([\_\`\*\<\>\&\\\\:\/]),\\\\$1,g;
 

@@ -250,9 +266,7 @@ foreach my $r (keys %ioctls) {
 }
 
 foreach my $r (keys %defines) {
-	my $n = $defines{$r};
-
-	my $s = "\\ :ref:`$r <$n>`\\ ";
+	my $s = $defines{$r};
 
 	$r =~ s,([\_\`\*\<\>\&\\\\:\/]),\\\\$1,g;
 

@@ -262,9 +276,7 @@ foreach my $r (keys %defines) {
 }
 
 foreach my $r (keys %enum_symbols) {
-	my $n = $enum_symbols{$r};
-
-	my $s = "\\ :ref:`$r <$n>`\\ ";
+	my $s = $enum_symbols{$r};
 
 	$r =~ s,([\_\`\*\<\>\&\\\\:\/]),\\\\$1,g;
 

@@ -274,9 +286,7 @@ foreach my $r (keys %enum_symbols) {
 }
 
 foreach my $r (keys %enums) {
-	my $n = $enums{$r};
-
-	my $s = "\\ :ref:`enum $r <$n>`\\ ";
+	my $s = $enums{$r};
 
 	$r =~ s,([\_\`\*\<\>\&\\\\:\/]),\\\\$1,g;
 

@@ -286,9 +296,7 @@ foreach my $r (keys %enums) {
 }
 
 foreach my $r (keys %structs) {
-	my $n = $structs{$r};
-
-	my $s = "\\ :ref:`struct $r <$n>`\\ ";
+	my $s = $structs{$r};
 
 	$r =~ s,([\_\`\*\<\>\&\\\\:\/]),\\\\$1,g;
 

@@ -298,18 +306,15 @@ foreach my $r (keys %structs) {
 }
 
 foreach my $r (keys %typedefs) {
-	my $n = $typedefs{$r};
-
-	my $s = "\\ :ref:`$r <$n>`\\ ";
+	my $s = $typedefs{$r};
 
 	$r =~ s,([\_\`\*\<\>\&\\\\:\/]),\\\\$1,g;
 
 	print "$r -> $s\n" if ($debug);
-
 	$data =~ s/($start_delim)($r)$end_delim/$1$s$3/g;
 }
 
-$data =~ s/\\ \n/\n/g;
+$data =~ s/\\ ([\n\s])/\1/g;
 
 #
 # Generate output file

index 227deee68c88..4de9533ce361 100644
@@ -21,8 +21,11 @@ nitpick_ignore = [
     ("c:func", "clock_gettime"),
     ("c:func", "close"),
     ("c:func", "container_of"),
+    ("c:func", "copy_from_user"),
+    ("c:func", "copy_to_user"),
     ("c:func", "determine_valid_ioctls"),
     ("c:func", "ERR_PTR"),
+    ("c:func", "i2c_new_device"),
     ("c:func", "ioctl"),
     ("c:func", "IS_ERR"),
     ("c:func", "mmap"),

@@ -37,6 +40,7 @@ nitpick_ignore = [
     ("c:func", "struct pollfd"),
     ("c:func", "usb_make_path"),
     ("c:func", "write"),
+
     ("c:type", "atomic_t"),
     ("c:type", "bool"),
     ("c:type", "boolean"),

@@ -72,10 +76,10 @@ nitpick_ignore = [
     ("c:type", "spi_device"),
     ("c:type", "spi_master"),
     ("c:type", "ssize_t"),
-    ("c:type", "struct fb_fix_screeninfo"),
-    ("c:type", "struct pollfd"),
-    ("c:type", "struct timeval"),
-    ("c:type", "struct video_capability"),
+    ("c:type", "fb_fix_screeninfo"),
+    ("c:type", "pollfd"),
+    ("c:type", "timeval"),
+    ("c:type", "video_capability"),
     ("c:type", "timeval"),
     ("c:type", "__u16"),
     ("c:type", "u16"),

@@ -87,6 +91,7 @@ nitpick_ignore = [
     ("c:type", "uint16_t"),
     ("c:type", "uint32_t"),
     ("c:type", "union"),
+    ("c:type", "__user"),
     ("c:type", "usb_device"),
     ("c:type", "video_system_t"),
 ]

index 41df9f144fcb..a3c4642eabfc 100644
@@ -6,8 +6,6 @@ Digital TV Common functions
 
 .. kernel-doc:: drivers/media/dvb-core/dvb_math.h
 
-.. kernel-doc:: drivers/media/dvb-core/dvb_ringbuffer.h
-
 .. kernel-doc:: drivers/media/dvb-core/dvbdev.h
 
 

@@ -18,6 +16,42 @@ Digital TV Common functions
 .. kernel-doc:: drivers/media/dvb-core/dvbdev.h
    :export: drivers/media/dvb-core/dvbdev.c
 
+Digital TV Ring buffer
+----------------------
+
+Those routines implement ring buffers used to handle digital TV data and
+copy it from/to userspace.
+
+.. note::
+
+  1) For performance reasons read and write routines don't check buffer sizes
+     and/or number of bytes free/available. This has to be done before these
+     routines are called. For example:
+
+   .. code-block:: c
+
+        /* write @buflen: bytes */
+        free = dvb_ringbuffer_free(rbuf);
+        if (free >= buflen)
+                count = dvb_ringbuffer_write(rbuf, buffer, buflen);
+        else
+                /* do something */
+
+        /* read min. 1000, max. @bufsize: bytes */
+        avail = dvb_ringbuffer_avail(rbuf);
+        if (avail >= 1000)
+                count = dvb_ringbuffer_read(rbuf, buffer, min(avail, bufsize));
+        else
+                /* do something */
+
+  2) If there is exactly one reader and one writer, there is no need
+     to lock read or write operations.
+     Two or more readers must be locked against each other.
+     Flushing the buffer counts as a read operation.
+     Resetting the buffer counts as a read and write operation.
+     Two or more writers must be locked against each other.
+
+.. kernel-doc:: drivers/media/dvb-core/dvb_ringbuffer.h
 
 
 Digital TV Frontend kABI

index 569cfc4f01cd..fb839a6c1f46 100644
@@ -85,8 +85,9 @@ a driver-specific structure.
 Pads are identified by their entity and their 0-based index in the pads
 array.
 
-Both information are stored in the :c:type:`struct media_pad`, making the
-:c:type:`media_pad` pointer the canonical way to store and pass link references.
+Both information are stored in the :c:type:`struct media_pad <media_pad>`,
+making the :c:type:`struct media_pad <media_pad>` pointer the canonical way
+to store and pass link references.
 
 Pads have flags that describe the pad capabilities and state.
 

index 4de9533ce361..1c7928abace5 100644
@@ -28,6 +28,7 @@ nitpick_ignore = [
     ("c:func", "i2c_new_device"),
     ("c:func", "ioctl"),
     ("c:func", "IS_ERR"),
+    ("c:func", "KERNEL_VERSION"),
     ("c:func", "mmap"),
     ("c:func", "open"),
     ("c:func", "pci_name"),

@@ -66,6 +67,7 @@ nitpick_ignore = [
     ("c:type", "off_t"),
     ("c:type", "pci_dev"),
     ("c:type", "pdvbdev"),
+    ("c:type", "platform_device"),
     ("c:type", "pollfd"),
     ("c:type", "poll_table_struct"),
     ("c:type", "s32"),

@@ -93,5 +95,6 @@ nitpick_ignore = [
     ("c:type", "union"),
     ("c:type", "__user"),
     ("c:type", "usb_device"),
+    ("c:type", "usb_interface"),
     ("c:type", "video_system_t"),
 ]

index f962686a7b63..9a5e31546ae3 100644
@@ -40,7 +40,7 @@ A good example of these ``replace``/``merge`` callbacks is in v4l2-event.c:
 In order to queue events to video device, drivers should call:
 
 	:c:func:`v4l2_event_queue <v4l2_event_queue>`
-	(:c:type:`vdev <video_device>`, :ref:`ev <v4l2-event>`)
+	(:c:type:`vdev <video_device>`, :c:type:`ev <v4l2_event>`)
 
 The driver's only responsibility is to fill in the type and the data fields.
 The other fields will be filled in by V4L2.

@@ -51,7 +51,7 @@ Event subscription
 Subscribing to an event is via:
 
 	:c:func:`v4l2_event_subscribe <v4l2_event_subscribe>`
-	(:c:type:`fh <v4l2_fh>`, :ref:`sub <v4l2-event-subscription>` ,
+	(:c:type:`fh <v4l2_fh>`, :c:type:`sub <v4l2_event_subscription>` ,
 	elems, :c:type:`ops <v4l2_subscribed_event_ops>`)
 
 

@@ -86,7 +86,7 @@ Unsubscribing an event
 Unsubscribing to an event is via:
 
 	:c:func:`v4l2_event_unsubscribe <v4l2_event_unsubscribe>`
-	(:c:type:`fh <v4l2_fh>`, :ref:`sub <v4l2-event-subscription>`)
+	(:c:type:`fh <v4l2_fh>`, :c:type:`sub <v4l2_event_subscription>`)
 
 This function is used to implement :c:type:`video_device`->
 :c:type:`ioctl_ops <v4l2_ioctl_ops>`-> ``vidioc_unsubscribe_event``.

index 14d7f6a19455..a35dca281178 100644
@@ -36,12 +36,12 @@ Description
 
 All cec devices must support :ref:`ioctl CEC_ADAP_G_CAPS <CEC_ADAP_G_CAPS>`. To query
 device information, applications call the ioctl with a pointer to a
-struct :ref:`cec_caps <cec-caps>`. The driver fills the structure and
+struct :c:type:`cec_caps`. The driver fills the structure and
 returns the information to the application. The ioctl never fails.
 
 .. tabularcolumns:: |p{1.2cm}|p{2.5cm}|p{13.8cm}|
 
-.. _cec-caps:
+.. c:type:: cec_caps
 
 .. flat-table:: struct cec_caps
     :header-rows:  0

index 1a920109072c..bd0756ff022e 100644
@@ -68,7 +68,7 @@ logical address types are already defined will return with error ``EBUSY``.
 
 .. tabularcolumns:: |p{1.0cm}|p{7.5cm}|p{8.0cm}|
 
-.. _cec-log-addrs:
+.. c:type:: cec_log_addrs
 
 .. cssclass:: longtable
 

index b7f104802045..10228eb0fd4a 100644
@@ -105,7 +105,7 @@ it is guaranteed that the state did change in between the two events.
 
 .. tabularcolumns:: |p{1.0cm}|p{4.2cm}|p{2.5cm}|p{8.8cm}|
 
-.. _cec-event:
+.. c:type:: cec_event
 
 .. flat-table:: struct cec_event
     :header-rows:  0

index 025a3851ab76..f015f1259b27 100644
@@ -76,7 +76,7 @@ result.
 
 .. tabularcolumns:: |p{1.0cm}|p{3.5cm}|p{13.0cm}|
 
-.. _cec-msg:
+.. c:type:: cec_msg
 
 .. cssclass:: longtable
 

index 4a53127eb13a..0b14c2dfc98c 100644
@@ -71,7 +71,7 @@ the following values.
     } audio_channel_select_t;
 
 
-.. _audio-status:
+.. c:type:: audio_status
 
 struct audio_status
 ===================

@@ -93,7 +93,7 @@ about various states of the playback operation.
     } audio_status_t;
 
 
-.. _audio-mixer:
+.. c:type:: audio_mixer
 
 struct audio_mixer
 ==================

@@ -132,7 +132,7 @@ following bits set according to the hardwares capabilities.
      #define AUDIO_CAP_AC3  256
 
 
-.. _audio-karaoke:
+.. c:type:: audio_karaoke
 
 struct audio_karaoke
 ====================

index 025f910ae945..d9e27c77426c 100644
@@ -7,7 +7,7 @@ CA Data Types
 *************
 
 
-.. _ca-slot-info:
+.. c:type:: ca_slot_info
 
 ca_slot_info_t
 ==============

@@ -31,7 +31,7 @@ ca_slot_info_t
     } ca_slot_info_t;
 
 
-.. _ca-descr-info:
+.. c:type:: ca_descr_info
 
 ca_descr_info_t
 ===============

@@ -48,7 +48,7 @@ ca_descr_info_t
     } ca_descr_info_t;
 
 
-.. _ca-caps:
+.. c:type:: ca_caps
 
 ca_caps_t
 =========

@@ -64,7 +64,7 @@ ca_caps_t
      } ca_cap_t;
 
 
-.. _ca-msg:
+.. c:type:: ca_msg
 
 ca_msg_t
 ========

@@ -81,7 +81,7 @@ ca_msg_t
     } ca_msg_t;
 
 
-.. _ca-descr:
+.. c:type:: ca_descr
 
 ca_descr_t
 ==========

@@ -96,7 +96,7 @@ ca_descr_t
     } ca_descr_t;
 
 
-.. _ca-pid:
+.. c:type:: ca_pid
 
 ca-pid
 ======

index efd564035958..65de705fa1ef 100644
@@ -120,7 +120,7 @@ dmx_pes_type_t
     } dmx_pes_type_t;
 
 
-.. _dmx-filter:
+.. c:type:: dmx_filter
 
 struct dmx_filter
 =================

@@ -136,7 +136,7 @@ struct dmx_filter
     } dmx_filter_t;
 
 
-.. _dmx-sct-filter-params:
+.. c:type:: dmx_sct_filter_params
 
 struct dmx_sct_filter_params
 ============================

@@ -157,7 +157,7 @@ struct dmx_sct_filter_params
     };
 
 
-.. _dmx-pes-filter-params:
+.. c:type:: dmx_pes_filter_params
 
 struct dmx_pes_filter_params
 ============================

@@ -194,7 +194,7 @@ struct dmx_event
      };
 
 
-.. _dmx-stc:
+.. c:type:: dmx_stc
 
 struct dmx_stc
 ==============

@@ -209,7 +209,7 @@ struct dmx_stc
     };
 
 
-.. _dmx-caps:
+.. c:type:: dmx_caps
 
 struct dmx_caps
 ===============

index 7c105e2ab27e..e8a02a1f138d 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _dtv-fe-stats:
+.. c:type:: dtv_fe_stats
 
 *******************
 struct dtv_fe_stats

index c13be5de4302..48c4e834ad11 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _dtv-properties:
+.. c:type:: dtv_properties
 
 *********************
 struct dtv_properties

index 5073a49def2a..3ddc3474b00e 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _dtv-property:
+.. c:type:: dtv_property
 
 *******************
 struct dtv_property

index 2cfdca00f164..35239e72bf74 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _dtv-stats:
+.. c:type:: dtv_stats
 
 ****************
 struct dtv_stats

index 78e72feaa178..2088bc6cacd8 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _dvb-frontend-event:
+.. c:type:: dvb_frontend_event
 
 ***************
 frontend events

index 16cb581d5cff..bf31411fc9df 100644
@@ -1,6 +1,6 @@
 .. -*- coding: utf-8; mode: rst -*-
 
-.. _dvb-frontend-parameters:
+.. c:type:: dvb_frontend_parameters
 
 *******************
 frontend parameters

@@ -49,7 +49,7 @@ frontends the ``frequency`` specifies the absolute frequency and is
 given in Hz.
 
 
-.. _dvb-qpsk-parameters:
+.. c:type:: dvb_qpsk_parameters
 
 QPSK parameters
 ===============

@@ -66,7 +66,7 @@ structure:
      };
 
 
-.. _dvb-qam-parameters:
+.. c:type:: dvb_qam_parameters
 
 QAM parameters
 ==============

@@ -83,7 +83,7 @@ for cable QAM frontend you use the ``dvb_qam_parameters`` structure:
      };
 
 
-.. _dvb-vsb-parameters:
+.. c:type:: dvb_vsb_parameters
 
 VSB parameters
 ==============

@@ -98,7 +98,7 @@ ATSC frontends are supported by the ``dvb_vsb_parameters`` structure:
     };
 
 
-.. _dvb-ofdm-parameters:
+.. c:type:: dvb_ofdm_parameters
 
 OFDM parameters
 ===============

index a5a859a45381..906f3e651e10 100644
@@ -23,7 +23,7 @@ union/struct based approach, in favor of a properties set approach.
 .. note::
 
    On Linux DVB API version 3, setting a frontend were done via
-   :ref:`struct dvb_frontend_parameters <dvb-frontend-parameters>`.
+   :c:type:`struct dvb_frontend_parameters <dvb_frontend_parameters>`.
    This got replaced on version 5 (also called "S2API", as this API were
    added originally_enabled to provide support for DVB-S2), because the
    old API has a very limited support to new standards and new hardware.

index e1b6da08b3a1..9fda5546d8c1 100644
@@ -27,7 +27,7 @@ Arguments
 
 ``argp``
     pointer to struct
-    :ref:`dvb_diseqc_slave_reply <dvb-diseqc-slave-reply>`
+    :c:type:`dvb_diseqc_slave_reply`
 
 
 Description

@@ -35,7 +35,7 @@ Description
 
 Receives reply from a DiSEqC 2.0 command.
 
-.. _dvb-diseqc-slave-reply:
+.. c:type:: dvb_diseqc_slave_reply
 
 struct dvb_diseqc_slave_reply
 -----------------------------

index ea090cbeaae0..72cb4ebd95c0 100644
@@ -27,7 +27,7 @@ Arguments
 
 ``argp``
     pointer to struct
-    :ref:`dvb_diseqc_master_cmd <dvb-diseqc-master-cmd>`
+    :c:type:`dvb_diseqc_master_cmd`
 
 
 Description

@@ -35,7 +35,7 @@ Description
 
 Sends a DiSEqC command to the antenna subsystem.
 
-.. _dvb-diseqc-master-cmd:
+.. c:type:: dvb_diseqc_master_cmd
 
 struct dvb_diseqc_master_cmd
 ============================

index c367b5ab023c..3557b756ef27 100644
@@ -27,7 +27,7 @@ Arguments
 
 ``argp``
     pointer to struct struct
-    :ref:`dvb_frontend_info <dvb-frontend-info>`
+    :c:type:`dvb_frontend_info`
 
 
 Description

@@ -40,7 +40,7 @@ takes a pointer to dvb_frontend_info which is filled by the driver.
 When the driver is not compatible with this specification the ioctl
 returns an error.
 
-.. _dvb-frontend-info:
+.. c:type:: dvb_frontend_info
 
 struct dvb_frontend_info
 ========================

index 51daf016a8eb..015d4db597b5 100644
@@ -29,7 +29,7 @@ Arguments
     File descriptor returned by :ref:`open() <frontend_f_open>`.
 
 ``argp``
-    pointer to struct :ref:`dtv_properties <dtv-properties>`
+    pointer to struct :c:type:`dtv_properties`
 
 
 Description

index fa377fe9e104..03a6c75bf5de 100644
@@ -78,7 +78,7 @@ at the above, as they're supported via the new
 ioctl's, using the :ref:`DTV_DELIVERY_SYSTEM <DTV-DELIVERY-SYSTEM>`
 parameter.
 
-In the old days, struct :ref:`dvb_frontend_info <dvb-frontend-info>`
+In the old days, struct :c:type:`dvb_frontend_info`
 used to contain ``fe_type_t`` field to indicate the delivery systems,
 filled with either FE_QPSK, FE_QAM, FE_OFDM or FE_ATSC. While this
 is still filled to keep backward compatibility, the usage of this field

@@ -87,7 +87,7 @@ devices support multiple delivery systems. Please use
 :ref:`DTV_ENUM_DELSYS <DTV-ENUM-DELSYS>` instead.
 
 On devices that support multiple delivery systems, struct
-:ref:`dvb_frontend_info <dvb-frontend-info>`::``fe_type_t`` is
+:c:type:`dvb_frontend_info`::``fe_type_t`` is
 filled with the currently standard, as selected by the last call to
 :ref:`FE_SET_PROPERTY <FE_GET_PROPERTY>` using the
 :ref:`DTV_DELIVERY_SYSTEM <DTV-DELIVERY-SYSTEM>` property.

index 0fc4aaa304ff..e73754fd0631 100644
@@ -20,7 +20,7 @@ standards, up to 3 groups of statistics can be provided, and
 plus one metric per each carrier group (called "layer" on ISDB).
 
 So, in order to be consistent with other delivery systems, the first
-value at :ref:`dtv_property.stat.dtv_stats <dtv-stats>` array refers
+value at :c:type:`dtv_property.stat.dtv_stats <dtv_stats>` array refers
 to the global metric. The other elements of the array represent each
 layer, starting from layer A(index 1), layer B (index 2) and so on.
 

index dfb4509f816c..dbe80c91bdb0 100644
@@ -26,7 +26,7 @@ Arguments
     File descriptor returned by :ref:`open() <frontend_f_open>`.
 
 ``net_if``
-    pointer to struct :ref:`dvb_net_if <dvb-net-if>`
+    pointer to struct :c:type:`dvb_net_if`
 
 
 Description

@@ -38,7 +38,7 @@ ULE) and the interface number for the new interface to be created. When
 the system call successfully returns, a new virtual network interface is
 created.
 
-The struct :ref:`dvb_net_if <dvb-net-if>`::ifnum field will be
+The struct :c:type:`dvb_net_if`::ifnum field will be
 filled with the number of the created interface.
 
 

@@ -47,7 +47,7 @@ filled with the number of the created interface.
 struct dvb_net_if description
 =============================
 
-.. _dvb-net-if:
+.. c:type:: dvb_net_if
 
 .. flat-table:: struct dvb_net_if
     :header-rows:  1

index dd9d6a3c4a2b..1bb8ee0cbced 100644
@@ -26,15 +26,15 @@ Arguments
     File descriptor returned by :ref:`open() <frontend_f_open>`.
 
 ``net_if``
-    pointer to struct :ref:`dvb_net_if <dvb-net-if>`
+    pointer to struct :c:type:`dvb_net_if`
 
 
 Description
 ===========
 
 The NET_GET_IF ioctl uses the interface number given by the struct
-:ref:`dvb_net_if <dvb-net-if>`::ifnum field and fills the content of
-struct :ref:`dvb_net_if <dvb-net-if>` with the packet ID and
+:c:type:`dvb_net_if`::ifnum field and fills the content of
+struct :c:type:`dvb_net_if` with the packet ID and
 encapsulation type used on such interface. If the interface was not
 created yet with :ref:`NET_ADD_IF <net>`, it will return -1 and fill
 the ``errno`` with ``EINVAL`` error code.

index 671f365ceeb4..640a21de6b8a 100644
@@ -95,7 +95,7 @@ representing the state of video playback.
     } video_play_state_t;
 
 
-.. _video-command:
+.. c:type:: video_command
 
 struct video_command
 ====================

@@ -146,7 +146,7 @@ video_size_t
     } video_size_t;
 
 
-.. _video-event:
+.. c:type:: video_event
 
 struct video_event
 ==================

@@ -172,7 +172,7 @@ VIDEO_GET_EVENT call.
     };
 
 
-.. _video-status:
+.. c:type:: video_status
 
 struct video_status
 ===================

@@ -203,7 +203,7 @@ case the source video format is not the same as the format of the output
 device.
 
 
-.. _video-still-picture:
+.. c:type:: video_still_picture
 
 struct video_still_picture
 ==========================

@@ -271,7 +271,7 @@ output. The following system types can be set:
     } video_system_t;
 
 
-.. _video-highlight:
+.. c:type:: video_highlight
 
 struct video_highlight
 ======================

@@ -302,7 +302,7 @@ information. The call expects the following format for that information:
      } video_highlight_t;
 
 
-.. _video-spu:
+.. c:type:: video_spu
 
 struct video_spu
 ================

@@ -320,7 +320,7 @@ to the following format:
      } video_spu_t;
 
 
-.. _video-spu-palette:
+.. c:type:: video_spu_palette
 
 struct video_spu_palette
 ========================

@@ -338,7 +338,7 @@ VIDEO_SPU_PALETTE:
      } video_spu_palette_t;
 
 
-.. _video-navi-pack:
+.. c:type:: video_navi_pack
 
 struct video_navi_pack
 ======================

index 412014110570..f690f9afc470 100644
@@ -33,12 +33,12 @@ Description
 
 All media devices must support the ``MEDIA_IOC_DEVICE_INFO`` ioctl. To
 query device information, applications call the ioctl with a pointer to
-a struct :ref:`media_device_info <media-device-info>`. The driver
+a struct :c:type:`media_device_info`. The driver
 fills the structure and returns the information to the application. The
 ioctl never fails.
 
 
-.. _media-device-info:
+.. c:type:: media_device_info
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 

index 628e91aeda97..0fd329279bef 100644
@@ -32,7 +32,7 @@ Description
 ===========
 
 To query the attributes of an entity, applications set the id field of a
-struct :ref:`media_entity_desc <media-entity-desc>` structure and
+struct :c:type:`media_entity_desc` structure and
 call the MEDIA_IOC_ENUM_ENTITIES ioctl with a pointer to this
 structure. The driver fills the rest of the structure or returns an
 EINVAL error code when the id is invalid.

@@ -49,7 +49,7 @@ enumerate entities by calling MEDIA_IOC_ENUM_ENTITIES with increasing
 id's until they get an error.
 
 
-.. _media-entity-desc:
+.. c:type:: media_entity_desc
 
 .. tabularcolumns:: |p{1.5cm}|p{1.5cm}|p{1.5cm}|p{1.5cm}|p{11.5cm}|
 

@@ -195,5 +195,5 @@ appropriately. The generic error codes are described at the
 :ref:`Generic Error Codes <gen-errors>` chapter.
 
 EINVAL
-    The struct :ref:`media_entity_desc <media-entity-desc>` ``id``
+    The struct :c:type:`media_entity_desc` ``id``
     references a non-existing entity.

index c81765f14b9f..d05be16ffaf6 100644
@@ -32,10 +32,10 @@ Description
 ===========
 
 To enumerate pads and/or links for a given entity, applications set the
-entity field of a struct :ref:`media_links_enum <media-links-enum>`
+entity field of a struct :c:type:`media_links_enum`
 structure and initialize the struct
-:ref:`media_pad_desc <media-pad-desc>` and struct
-:ref:`media_link_desc <media-link-desc>` structure arrays pointed by
+:c:type:`media_pad_desc` and struct
+:c:type:`media_link_desc` structure arrays pointed by
 the ``pads`` and ``links`` fields. They then call the
 MEDIA_IOC_ENUM_LINKS ioctl with a pointer to this structure.
 

@@ -53,7 +53,7 @@ Only forward links that originate at one of the entity's source pads are
 returned during the enumeration process.
 
 
-.. _media-links-enum:
+.. c:type:: media_links_enum
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 

@@ -73,7 +73,7 @@ returned during the enumeration process.
 
     -  .. row 2
 
-       -  struct :ref:`media_pad_desc <media-pad-desc>`
+       -  struct :c:type:`media_pad_desc`
 
        -  \*\ ``pads``
 

@@ -82,7 +82,7 @@ returned during the enumeration process.
 
     -  .. row 3
 
-       -  struct :ref:`media_link_desc <media-link-desc>`
+       -  struct :c:type:`media_link_desc`
 
        -  \*\ ``links``
 

@@ -91,7 +91,7 @@ returned during the enumeration process.
 
 
 
-.. _media-pad-desc:
+.. c:type:: media_pad_desc
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 

@@ -127,7 +127,7 @@ returned during the enumeration process.
 
 
 
-.. _media-link-desc:
+.. c:type:: media_link_desc
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 

@@ -139,7 +139,7 @@ returned during the enumeration process.
 
     -  .. row 1
 
-       -  struct :ref:`media_pad_desc <media-pad-desc>`
+       -  struct :c:type:`media_pad_desc`
 
        -  ``source``
 

@@ -147,7 +147,7 @@ returned during the enumeration process.
 
     -  .. row 2
 
-       -  struct :ref:`media_pad_desc <media-pad-desc>`
+       -  struct :c:type:`media_pad_desc`
 
        -  ``sink``
 

@@ -170,5 +170,5 @@ appropriately. The generic error codes are described at the
 :ref:`Generic Error Codes <gen-errors>` chapter.
 
 EINVAL
-    The struct :ref:`media_links_enum <media-links-enum>` ``id``
+    The struct :c:type:`media_links_enum` ``id``
     references a non-existing entity.

index c246df06ff7f..0b26fd865b72 100644
@@ -33,7 +33,7 @@ Description
 
 The typical usage of this ioctl is to call it twice. On the first call,
 the structure defined at struct
-:ref:`media_v2_topology <media-v2-topology>` should be zeroed. At
+:c:type:`media_v2_topology` should be zeroed. At
 return, if no errors happen, this ioctl will return the
 ``topology_version`` and the total number of entities, interfaces, pads
 and links.

@@ -48,7 +48,7 @@ desired arrays with the media graph elements.
 
 .. tabularcolumns:: |p{1.6cm}|p{3.2cm}|p{12.7cm}|
 
-.. _media-v2-topology:
+.. c:type:: media_v2_topology
 
 .. flat-table:: struct media_v2_topology
     :header-rows:  0

@@ -143,7 +143,7 @@ desired arrays with the media graph elements.
 
 .. tabularcolumns:: |p{1.6cm}|p{3.2cm}|p{12.7cm}|
 
-.. _media-v2-entity:
+.. c:type:: media_v2_entity
 
 .. flat-table:: struct media_v2_entity
     :header-rows:  0

@@ -187,7 +187,7 @@ desired arrays with the media graph elements.
 
 .. tabularcolumns:: |p{1.6cm}|p{3.2cm}|p{12.7cm}|
 
-.. _media-v2-interface:
+.. c:type:: media_v2_interface
 
 .. flat-table:: struct media_v2_interface
     :header-rows:  0

@@ -239,7 +239,7 @@ desired arrays with the media graph elements.
 
 .. tabularcolumns:: |p{1.6cm}|p{3.2cm}|p{12.7cm}|
 
-.. _media-v2-intf-devnode:
+.. c:type:: media_v2_intf_devnode
 
 .. flat-table:: struct media_v2_interface
     :header-rows:  0

@@ -266,7 +266,7 @@ desired arrays with the media graph elements.
 
 .. tabularcolumns:: |p{1.6cm}|p{3.2cm}|p{12.7cm}|
 
-.. _media-v2-pad:
+.. c:type:: media_v2_pad
 
 .. flat-table:: struct media_v2_pad
     :header-rows:  0

@@ -310,7 +310,7 @@ desired arrays with the media graph elements.
 
 .. tabularcolumns:: |p{1.6cm}|p{3.2cm}|p{12.7cm}|
 
-.. _media-v2-link:
+.. c:type:: media_v2_link
 
 .. flat-table:: struct media_v2_pad
     :header-rows:  0

index 35a189e19962..ae5194940100 100644
@@ -32,7 +32,7 @@ Description
 ===========
 
 To change link properties applications fill a struct
-:ref:`media_link_desc <media-link-desc>` with link identification
+:c:type:`media_link_desc` with link identification
 information (source and sink pad) and the new requested link flags. They
 then call the MEDIA_IOC_SETUP_LINK ioctl with a pointer to that
 structure.

@@ -61,6 +61,6 @@ appropriately. The generic error codes are described at the
 :ref:`Generic Error Codes <gen-errors>` chapter.
 
 EINVAL
-    The struct :ref:`media_link_desc <media-link-desc>` references a
+    The struct :c:type:`media_link_desc` references a
     non-existing link, or the link is immutable and an attempt to modify
     its configuration was made.

index b8059fb05372..5ec99a2809fe 100644
@@ -21,15 +21,15 @@ more than one video input or output. Assumed two composite video inputs
 and two audio inputs exist, there may be up to four valid combinations.
 The relation of video and audio connectors is defined in the
 ``audioset`` field of the respective struct
-:ref:`v4l2_input <v4l2-input>` or struct
-:ref:`v4l2_output <v4l2-output>`, where each bit represents the index
+:c:type:`v4l2_input` or struct
+:c:type:`v4l2_output`, where each bit represents the index
 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` and
 :ref:`VIDIOC_ENUMAUDOUT <VIDIOC_ENUMAUDOUT>` ioctl, respectively.
-The struct :ref:`v4l2_audio <v4l2-audio>` returned by the
+The struct :c:type:`v4l2_audio` returned by the
 :ref:`VIDIOC_ENUMAUDIO` ioctl also contains signal
 :status information applicable when the current audio input is queried.
 

@@ -53,7 +53,7 @@ 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
+in the struct :c:type:`v4l2_capability` returned by
 the :ref:`VIDIOC_QUERYCAP` ioctl.
 
 

@@ -91,7 +91,7 @@ Example: Switching to the first audio input
     }
 
 .. [#f1]
-   Actually struct :ref:`v4l2_audio <v4l2-audio>` ought to have a
-   ``tuner`` field like struct :ref:`v4l2_input <v4l2-input>`, not
+   Actually struct :c:type:`v4l2_audio` ought to have a
+   ``tuner`` field like struct :c:type:`v4l2_input`, not
    only making the API more consistent but also permitting radio devices
    with multiple tuners.

index 7bab30b59eae..a52a586b0b41 100644
@@ -11,14 +11,14 @@ the Streaming I/O methods. In the multi-planar API, the data is held in
 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 :ref:`struct v4l2_buffer <v4l2-buffer>`,
+or field parity, are stored in a struct :c:type:`struct v4l2_buffer <v4l2_buffer>`,
 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 :ref:`struct v4l2_buffer <v4l2-buffer>`,
+some plane-specific members of struct :c:type:`struct v4l2_buffer <v4l2_buffer>`,
 such as pointers and sizes for each plane, are stored in struct
-:ref:`struct v4l2_plane <v4l2-plane>` instead. In that case, struct
-:ref:`struct v4l2_buffer <v4l2-buffer>` contains an array of plane structures.
+:c:type:`struct v4l2_plane <v4l2_plane>` instead. In that case, struct
+:c:type:`struct v4l2_buffer <v4l2_buffer>` contains an array of plane structures.
 
 Dequeued video buffers come with timestamps. The driver decides at which
 part of the frame and with which clock the timestamp is taken. Please

@@ -34,7 +34,7 @@ flags are copied from the OUTPUT video buffer to the CAPTURE video
 buffer.
 
 
-.. _v4l2-buffer:
+.. c:type:: v4l2_buffer
 
 struct v4l2_buffer
 ==================

@@ -60,7 +60,7 @@ struct v4l2_buffer
 	  :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` ioctl
-	  (struct :ref:`v4l2_requestbuffers <v4l2-requestbuffers>`
+	  (struct :c:type:`v4l2_requestbuffers`
 	  ``count``), plus any buffers allocated with
 	  :ref:`VIDIOC_CREATE_BUFS` minus one.
 

@@ -72,8 +72,8 @@ struct v4l2_buffer
 
        -
        -  Type of the buffer, same as struct
-	  :ref:`v4l2_format <v4l2-format>` ``type`` or struct
-	  :ref:`v4l2_requestbuffers <v4l2-requestbuffers>` ``type``, set
+	  :c:type:`v4l2_format` ``type`` or struct
+	  :c:type:`v4l2_requestbuffers` ``type``, set
 	  by the application. See :ref:`v4l2-buf-type`
 
     -  .. row 3

@@ -134,7 +134,7 @@ struct v4l2_buffer
 
     -  .. row 7
 
-       -  struct :ref:`v4l2_timecode <v4l2-timecode>`
+       -  struct :c:type:`v4l2_timecode`
 
        -  ``timecode``
 

@@ -229,9 +229,9 @@ struct v4l2_buffer
        -  ``*planes``
 
        -  When using the multi-planar API, contains a userspace pointer to
-	  an array of struct :ref:`v4l2_plane <v4l2-plane>`. The size of
+	  an array of struct :c:type:`v4l2_plane`. The size of
 	  the array should be put in the ``length`` field of this
-	  :ref:`struct v4l2_buffer <v4l2-buffer>` structure.
+	  :c:type:`struct v4l2_buffer <v4l2_buffer>` structure.
 
     -  .. row 15
 

@@ -281,7 +281,7 @@ struct v4l2_buffer
 
 
 
-.. _v4l2-plane:
+.. c:type:: v4l2_plane
 
 struct v4l2_plane
 =================

@@ -344,10 +344,10 @@ struct v4l2_plane
        -  ``mem_offset``
 
        -  When the memory type in the containing struct
-	  :ref:`v4l2_buffer <v4l2-buffer>` is ``V4L2_MEMORY_MMAP``, this
+	  :c:type:`v4l2_buffer` is ``V4L2_MEMORY_MMAP``, this
 	  is the value that should be passed to :ref:`mmap() <func-mmap>`,
 	  similar to the ``offset`` field in struct
-	  :ref:`v4l2_buffer <v4l2-buffer>`.
+	  :c:type:`v4l2_buffer`.
 
     -  .. row 5
 

@@ -357,7 +357,7 @@ struct v4l2_plane
        -  ``userptr``
 
        -  When the memory type in the containing struct
-	  :ref:`v4l2_buffer <v4l2-buffer>` is ``V4L2_MEMORY_USERPTR``,
+	  :c:type:`v4l2_buffer` is ``V4L2_MEMORY_USERPTR``,
 	  this is a userspace pointer to the memory allocated for this plane
 	  by an application.
 

@@ -369,9 +369,9 @@ struct v4l2_plane
        -  ``fd``
 
        -  When the memory type in the containing struct
-	  :ref:`v4l2_buffer <v4l2-buffer>` is ``V4L2_MEMORY_DMABUF``,
+	  :c:type:`v4l2_buffer` is ``V4L2_MEMORY_DMABUF``,
 	  this is a file descriptor associated with a DMABUF buffer, similar
-	  to the ``fd`` field in struct :ref:`v4l2_buffer <v4l2-buffer>`.
+	  to the ``fd`` field in struct :c:type:`v4l2_buffer`.
 
     -  .. row 7
 

@@ -823,13 +823,13 @@ enum v4l2_memory
 Timecodes
 =========
 
-The :ref:`struct v4l2_timecode <v4l2-timecode>` structure is designed to hold a
+The :c:type:`struct v4l2_timecode <v4l2_timecode>` structure is designed to hold a
 :ref:`smpte12m` or similar timecode. (struct
 :c:type:`struct timeval` timestamps are stored in struct
-:ref:`v4l2_buffer <v4l2-buffer>` field ``timestamp``.)
+:c:type:`v4l2_buffer` field ``timestamp``.)
 
 
-.. _v4l2-timecode:
+.. c:type:: v4l2_timecode
 
 struct v4l2_timecode
 --------------------

index 4622884b06ea..3ea733a8eef8 100644
@@ -65,7 +65,7 @@ Cropping Structures
 
 For capture devices the coordinates of the top left corner, width and
 height of the area which can be sampled is given by the ``bounds``
-substructure of the struct :ref:`v4l2_cropcap <v4l2-cropcap>` returned
+substructure of the struct :c:type:`v4l2_cropcap` returned
 by the :ref:`VIDIOC_CROPCAP <VIDIOC_CROPCAP>` ioctl. To support a wide
 range of hardware this specification does not define an origin or units.
 However by convention drivers should horizontally count unscaled samples

@@ -77,8 +77,8 @@ can capture both fields.
 
 The top left corner, width and height of the source rectangle, that is
 the area actually sampled, is given by struct
-:ref:`v4l2_crop <v4l2-crop>` using the same coordinate system as
-struct :ref:`v4l2_cropcap <v4l2-cropcap>`. Applications can use the
+:c:type:`v4l2_crop` using the same coordinate system as
+struct :c:type:`v4l2_cropcap`. Applications can use the
 :ref:`VIDIOC_G_CROP <VIDIOC_G_CROP>` and :ref:`VIDIOC_S_CROP <VIDIOC_G_CROP>`
 ioctls to get and set this rectangle. It must lie completely within the
 capture boundaries and the driver may further adjust the requested size

@@ -86,7 +86,7 @@ and/or position according to hardware limitations.
 
 Each capture device has a default source rectangle, given by the
 ``defrect`` substructure of struct
-:ref:`v4l2_cropcap <v4l2-cropcap>`. The center of this rectangle
+:c:type:`v4l2_cropcap`. The center of this rectangle
 shall align with the center of the active picture area of the video
 signal, and cover what the driver writer considers the complete picture.
 Drivers shall reset the source rectangle to the default when the driver

@@ -104,11 +104,11 @@ Video hardware can have various cropping, insertion and scaling
 limitations. It may only scale up or down, support only discrete scaling
 factors, or have different scaling abilities in horizontal and vertical
 direction. Also it may not support scaling at all. At the same time the
-struct :ref:`v4l2_crop <v4l2-crop>` rectangle may have to be aligned,
+struct :c:type:`v4l2_crop` rectangle may have to be aligned,
 and both the source and target rectangles may have arbitrary upper and
 lower size limits. In particular the maximum ``width`` and ``height`` in
-struct :ref:`v4l2_crop <v4l2-crop>` may be smaller than the struct
-:ref:`v4l2_cropcap <v4l2-cropcap>`. ``bounds`` area. Therefore, as
+struct :c:type:`v4l2_crop` may be smaller than the struct
+:c:type:`v4l2_cropcap`. ``bounds`` area. Therefore, as
 usual, drivers are expected to adjust the requested parameters and
 return the actual values selected.
 

index 8d049471e1c2..32b32055d070 100644
@@ -26,7 +26,7 @@ Querying Capabilities
 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
+:c:type:`v4l2_capability` returned by the
 :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>`

@@ -64,18 +64,18 @@ Cropping initialization at minimum requires to reset the parameters to
 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
+a struct :c:type:`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
 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``
+:c:type:`v4l2_pix_format` ``pix`` or the struct
+:c:type:`v4l2_pix_format_mplane` ``pix_mp``
 member of the ``fmt`` union.
 
 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>`
+struct :c:type:`v4l2_format` as above and initialize all
+fields of the struct :c:type:`v4l2_pix_format`
 ``vbi`` member of the ``fmt`` union, or better just modify the results
 of :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`, and call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
 ioctl with a pointer to this structure. Drivers may adjust the

@@ -86,8 +86,8 @@ Like :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` the :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>`
 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
+The contents of struct :c:type:`v4l2_pix_format` and
+struct :c:type:`v4l2_pix_format_mplane` are
 discussed in :ref:`pixfmt`. See also the specification of the
 :ref:`VIDIOC_G_FMT <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 <VIDIOC_G_FMT>`

index 4e1ee79ec334..a6aaf28807a4 100644
@@ -28,7 +28,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
+struct :c:type:`v4l2_capability` returned by the
 :ref:`VIDIOC_QUERYCAP` ioctl.
 
 

@@ -41,7 +41,7 @@ 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
 other information, the physical address of the framebuffer in the
-``base`` field of struct :ref:`v4l2_framebuffer <v4l2-framebuffer>`.
+``base`` field of struct :c:type:`v4l2_framebuffer`.
 The framebuffer device ioctl ``FBIOGET_FSCREENINFO`` returns the same
 address in the ``smem_start`` field of struct
 :c:type:`struct fb_fix_screeninfo`. The ``FBIOGET_FSCREENINFO``

@@ -114,18 +114,18 @@ sizes and positions of these rectangles. Further drivers may support any
 (or none) of the clipping/blending methods defined for the
 :ref:`Video Overlay <overlay>` interface.
 
-A struct :ref:`v4l2_window <v4l2-window>` defines the size of the
+A struct :c:type:`v4l2_window` defines the size of the
 source rectangle, its position in the framebuffer and the
 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
+:c:type:`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:`struct v4l2_window <v4l2-window>` substructure named ``win``. It is not
+:c:type:`struct v4l2_window <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
+struct :c:type:`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

@@ -134,10 +134,10 @@ the :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>` ioctl can be used to learn
 about driver capabilities without actually changing driver state. Unlike
 :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
+A struct :c:type:`v4l2_crop` defines the size and position
 of the target rectangle. The scaling factor of the overlay is implied by
-the width and height given in struct :ref:`v4l2_window <v4l2-window>`
-and struct :ref:`v4l2_crop <v4l2-crop>`. The cropping API applies to
+the width and height given in struct :c:type:`v4l2_window`
+and struct :c:type:`v4l2_crop`. The cropping API applies to
 *Video Output* and *Video Output Overlay* devices in the same way as to
 *Video Capture* and *Video Overlay* devices, merely reversing the
 direction of the data flow. For more information see :ref:`crop`.

index dfb8207c21cc..25ae8ec96fdf 100644
@@ -25,7 +25,7 @@ Querying Capabilities
 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
+:c:type:`v4l2_capability` returned by the
 :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

@@ -62,17 +62,17 @@ Cropping initialization at minimum requires to reset the parameters to
 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
+a struct :c:type:`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
 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``
+:c:type:`v4l2_pix_format` ``pix`` or the struct
+:c:type:`v4l2_pix_format_mplane` ``pix_mp``
 member of the ``fmt`` union.
 
 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>`
+struct :c:type:`v4l2_format` as above and initialize all
+fields of the struct :c:type:`v4l2_pix_format`
 ``vbi`` member of the ``fmt`` union, or better just modify the results
 of :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>`, and call the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
 ioctl with a pointer to this structure. Drivers may adjust the

@@ -83,8 +83,8 @@ Like :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` the :ref:`VIDIOC_TRY_FMT <VIDIOC_G_FMT>`
 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
+The contents of struct :c:type:`v4l2_pix_format` and
+struct :c:type:`v4l2_pix_format_mplane` are
 discussed in :ref:`pixfmt`. See also the specification of the
 :ref:`VIDIOC_G_FMT <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 <VIDIOC_G_FMT>`

index 50e2d52fcae6..4962947bd8a2 100644
@@ -43,7 +43,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
+:c:type:`v4l2_capability` returned by the
 :ref:`VIDIOC_QUERYCAP` ioctl. The overlay I/O
 method specified below must be supported. Tuners and audio inputs are
 optional.

@@ -119,17 +119,17 @@ at minimum requires to reset the parameters to defaults. An example is
 given in :ref:`crop`.
 
 The overlay window is described by a struct
-:ref:`v4l2_window <v4l2-window>`. It defines the size of the image,
+:c:type:`v4l2_window`. It defines the size of the image,
 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
+struct :c:type:`v4l2_format` to
 ``V4L2_BUF_TYPE_VIDEO_OVERLAY`` and call the
 :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` ioctl. The driver fills the
-:ref:`struct v4l2_window <v4l2-window>` substructure named ``win``. It is not
+:c:type:`struct v4l2_window <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
+struct :c:type:`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

@@ -139,7 +139,7 @@ about driver capabilities without actually changing driver state. Unlike
 :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
+height given in struct :c:type:`v4l2_window` and the size
 of the cropping rectangle. For more information see :ref:`crop`.
 
 When simultaneous capturing and overlay is supported and the hardware

@@ -149,7 +149,7 @@ takes precedence. The attempt to capture or overlay as well
 code or return accordingly modified parameters.
 
 
-.. _v4l2-window:
+.. c:type:: v4l2_window
 
 struct v4l2_window
 ------------------

@@ -175,7 +175,7 @@ struct v4l2_window
     :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``
+    :c:type:`v4l2_framebuffer` ``fmt.pixelformat``
     field), with bytes in host order. E. g. for
     :ref:`V4L2_PIX_FMT_BGR24 <V4L2-PIX-FMT-BGR32>` the value should
     be 0xRRGGBB on a little endian, 0xBBGGRR on a big endian host.

@@ -242,11 +242,11 @@ exceeded are undefined. [#f3]_
 
    This field was added in Linux 2.6.23, extending the
    structure. However the :ref:`VIDIOC_[G|S|TRY]_FMT <VIDIOC_G_FMT>`
-   ioctls, which take a pointer to a :ref:`v4l2_format <v4l2-format>`
+   ioctls, which take a pointer to a :c:type:`v4l2_format`
    parent structure with padding bytes at the end, are not affected.
 
 
-.. _v4l2-clip:
+.. c:type:: v4l2_clip
 
 struct v4l2_clip [#f4]_
 -----------------------

@@ -262,7 +262,7 @@ struct v4l2_clip [#f4]_
     linked list of clipping rectangles.
 
 
-.. _v4l2-rect:
+.. c:type:: v4l2_rect
 
 struct v4l2_rect
 ----------------

index 5ff7cded2591..2b5b836574eb 100644
@@ -20,7 +20,7 @@ Querying Capabilities
 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
+:c:type:`v4l2_capability` returned by the
 :ref:`VIDIOC_QUERYCAP` ioctl. Other combinations of
 capability flags are reserved for future extensions.
 

index 3cf44869a425..26ec24a94103 100644
@@ -39,7 +39,7 @@ Querying Capabilities
 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
+:c:type:`v4l2_capability` returned by 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.

@@ -69,16 +69,16 @@ always ensure they really get what they want, requesting reasonable
 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
+``type`` field of a struct :c:type:`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
 structure. Drivers fill the struct
-:ref:`v4l2_vbi_format <v4l2-vbi-format>` ``vbi`` member of the
+:c:type:`v4l2_vbi_format` ``vbi`` member of the
 ``fmt`` union.
 
 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>`
+struct :c:type:`v4l2_format` as above and initialize all
+fields of the struct :c:type:`v4l2_vbi_format`
 ``vbi`` member of the ``fmt`` union, or better just modify the results
 of :ref:`VIDIOC_G_FMT <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

@@ -101,7 +101,7 @@ and always returns default parameters as :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` does
 
 .. tabularcolumns:: |p{2.4cm}|p{4.4cm}|p{10.7cm}|
 
-.. _v4l2-vbi-format:
+.. c:type:: v4l2_vbi_format
 
 .. cssclass:: longtable
 

@@ -204,7 +204,7 @@ and always returns default parameters as :ref:`VIDIOC_G_FMT <VIDIOC_G_FMT>` does
 	  To initialize the ``start`` and ``count`` fields, applications
 	  must first determine the current video standard selection. The
 	  :ref:`v4l2_std_id <v4l2-std-id>` or the ``framelines`` field
-	  of struct :ref:`v4l2_standard <v4l2-standard>` can be evaluated
+	  of struct :c:type:`v4l2_standard` can be evaluated
 	  for this purpose.
 
     -  .. row 8

index 841761a3ea59..4a8e1d2efd06 100644
@@ -34,10 +34,10 @@ 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
+:c:type:`v4l2_capability` returned by the
 :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
+``capability`` field of struct :c:type:`v4l2_tuner`. If the
 driver only passes RDS blocks without interpreting the data the
 ``V4L2_TUNER_CAP_RDS_BLOCK_IO`` flag has to be set, see
 :ref:`Reading RDS data <reading-rds-data>`. For future use the flag

@@ -48,19 +48,19 @@ linux-media mailing list:
 `https://linuxtv.org/lists.php <https://linuxtv.org/lists.php>`__.
 
 Whether an RDS signal is present can be detected by looking at the
-``rxsubchans`` field of struct :ref:`v4l2_tuner <v4l2-tuner>`: the
+``rxsubchans`` field of struct :c:type:`v4l2_tuner`: the
 ``V4L2_TUNER_SUB_RDS`` will be set if RDS data was detected.
 
 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
+:c:type:`v4l2_capability` returned by the
 :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
+:c:type:`v4l2_modulator`. In order to enable the RDS
 transmission one must set the ``V4L2_TUNER_SUB_RDS`` bit in the
 ``txsubchans`` field of struct
-:ref:`v4l2_modulator <v4l2-modulator>`. If the driver only passes RDS
+:c:type:`v4l2_modulator`. If the driver only passes RDS
 blocks without interpreting the data the ``V4L2_TUNER_CAP_RDS_BLOCK_IO``
 flag has to be set. If the tuner is capable of handling RDS entities
 like program identification codes and radio text, the flag

@@ -93,7 +93,7 @@ RDS datastructures
 ==================
 
 
-.. _v4l2-rds-data:
+.. c:type:: v4l2_rds_data
 
 .. tabularcolumns:: |p{2.5cm}|p{2.5cm}|p{12.5cm}|
 

index 3b6aa2a58430..5f82d760e188 100644
@@ -21,7 +21,7 @@ Querying Capabilities
 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
+:c:type:`v4l2_capability` returned by 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.

@@ -29,7 +29,7 @@ element for the SDR receiver.
 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
+:c:type:`v4l2_capability` returned by 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.

@@ -67,18 +67,18 @@ basic :ref:`format` ioctls, the
 well.
 
 To use the :ref:`format` ioctls applications set the ``type``
-field of a struct :ref:`v4l2_format <v4l2-format>` to
+field of a struct :c:type:`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
+the struct :c:type:`v4l2_sdr_format` ``sdr`` member
 of the ``fmt`` union as needed per the desired operation. Currently
 there is two fields, ``pixelformat`` and ``buffersize``, of struct
-struct :ref:`v4l2_sdr_format <v4l2-sdr-format>` which are used.
+struct :c:type:`v4l2_sdr_format` which are used.
 Content of the ``pixelformat`` is V4L2 FourCC code of the data format.
 The ``buffersize`` field is maximum buffer size in bytes required for
 data transfer, set by the driver in order to inform application.
 
 
-.. _v4l2-sdr-format:
+.. c:type:: v4l2_sdr_format
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 

index 86d2d698d2af..2a979aa138bd 100644
@@ -34,7 +34,7 @@ Querying Capabilities
 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
+:c:type:`v4l2_capability` returned by 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.

@@ -67,17 +67,17 @@ line 16 the hardware may be able to look for a VPS or Teletext signal,
 but not both at the same time.
 
 To determine the currently selected services applications set the
-``type`` field of struct :ref:`v4l2_format <v4l2-format>` to
+``type`` field of struct :c:type:`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``
 member, a struct
-:ref:`v4l2_sliced_vbi_format <v4l2-sliced-vbi-format>`.
+:c:type:`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:`struct v4l2_format <v4l2-format>` structure.
+:c:type:`struct v4l2_format <v4l2_format>` structure.
 
 The sliced VBI API is more complicated than the raw VBI API because the
 hardware must be told which VBI service to expect on each scan line. Not

@@ -100,7 +100,7 @@ which may return ``EBUSY`` can be the
 :ref:`select() <func-select>` call.
 
 
-.. _v4l2-sliced-vbi-format:
+.. c:type:: v4l2_sliced_vbi_format
 
 struct v4l2_sliced_vbi_format
 -----------------------------

@@ -233,7 +233,7 @@ struct v4l2_sliced_vbi_format
 	  :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
+	  :c:type:`v4l2_sliced_vbi_data` times the
 	  number of non-zero elements in the returned ``service_lines``
 	  array (that is the number of lines potentially carrying data).
 

@@ -376,14 +376,14 @@ Reading and writing sliced VBI data
 
 A single :ref:`read() <func-read>` or :ref:`write() <func-write>`
 call must pass all data belonging to one video frame. That is an array
-of :ref:`struct v4l2_sliced_vbi_data <v4l2-sliced-vbi-data>` structures with one or
+of :c:type:`struct v4l2_sliced_vbi_data <v4l2_sliced_vbi_data>` structures with one or
 more elements and a total size not exceeding ``io_size`` bytes. Likewise
 in streaming I/O mode one buffer of ``io_size`` bytes must contain data
 of one video frame. The ``id`` of unused
-:ref:`struct v4l2_sliced_vbi_data <v4l2-sliced-vbi-data>` elements must be zero.
+:c:type:`struct v4l2_sliced_vbi_data <v4l2_sliced_vbi_data>` elements must be zero.
 
 
-.. _v4l2-sliced-vbi-data:
+.. c:type:: v4l2_sliced_vbi_data
 
 struct v4l2_sliced_vbi_data
 ---------------------------

@@ -561,7 +561,7 @@ refer to the MPEG-2 specifications for details on those packet headers.)
 
 The payload of the MPEG-2 *Private Stream 1 PES* packets that contain
 sliced VBI data is specified by struct
-:ref:`v4l2_mpeg_vbi_fmt_ivtv <v4l2-mpeg-vbi-fmt-ivtv>`. The
+:c:type:`v4l2_mpeg_vbi_fmt_ivtv`. The
 payload is variable length, depending on the actual number of lines of
 sliced VBI data present in a video frame. The payload may be padded at
 the end with unspecified fill bytes to align the end of the payload to a

@@ -570,7 +570,7 @@ with 18 lines/field with 43 bytes of data/line and a 4 byte magic
 number).
 
 
-.. _v4l2-mpeg-vbi-fmt-ivtv:
+.. c:type:: v4l2_mpeg_vbi_fmt_ivtv
 
 struct v4l2_mpeg_vbi_fmt_ivtv
 -----------------------------

@@ -604,7 +604,7 @@ struct v4l2_mpeg_vbi_fmt_ivtv
     -  .. row 3
 
        -
-       -  struct :ref:`v4l2_mpeg_vbi_itv0 <v4l2-mpeg-vbi-itv0>`
+       -  struct :c:type:`v4l2_mpeg_vbi_itv0`
 
        -  ``itv0``
 

@@ -655,7 +655,7 @@ Magic Constants for struct v4l2_mpeg_vbi_fmt_ivtv magic field
        -  "itv0"
 
        -  Indicates the ``itv0`` member of the union in struct
-	  :ref:`v4l2_mpeg_vbi_fmt_ivtv <v4l2-mpeg-vbi-fmt-ivtv>` is
+	  :c:type:`v4l2_mpeg_vbi_fmt_ivtv` is
 	  valid.
 
     -  .. row 3

@@ -665,12 +665,12 @@ Magic Constants for struct v4l2_mpeg_vbi_fmt_ivtv magic field
        -  "ITV0"
 
        -  Indicates the ``ITV0`` member of the union in struct
-	  :ref:`v4l2_mpeg_vbi_fmt_ivtv <v4l2-mpeg-vbi-fmt-ivtv>` is
+	  :c:type:`v4l2_mpeg_vbi_fmt_ivtv` is
 	  valid and that 36 lines of sliced VBI data are present.
 
 
 
-.. _v4l2-mpeg-vbi-itv0:
+.. c:type:: v4l2_mpeg_vbi_itv0
 
 struct v4l2_mpeg_vbi_itv0
 -------------------------

@@ -711,7 +711,7 @@ struct v4l2_mpeg_vbi_itv0
     -  .. row 2
 
        -  struct
-	  :ref:`v4l2_mpeg_vbi_itv0_line <v4l2-mpeg-vbi-itv0-line>`
+	  :c:type:`v4l2_mpeg_vbi_itv0_line`
 
        -  ``line``\ [35]
 

@@ -745,7 +745,7 @@ struct v4l2_mpeg_vbi_ITV0
     -  .. row 1
 
        -  struct
-	  :ref:`v4l2_mpeg_vbi_itv0_line <v4l2-mpeg-vbi-itv0-line>`
+	  :c:type:`v4l2_mpeg_vbi_itv0_line`
 
        -  ``line``\ [36]
 

@@ -756,7 +756,7 @@ struct v4l2_mpeg_vbi_ITV0
 
 
 
-.. _v4l2-mpeg-vbi-itv0-line:
+.. c:type:: v4l2_mpeg_vbi_itv0_line
 
 struct v4l2_mpeg_vbi_itv0_line
 ------------------------------

index 1045b3c61031..6dc7f13780ba 100644
@@ -341,7 +341,7 @@ It can also be used as part of digital zoom implementations to select
 the area of the image that will be scaled up.
 
 Crop settings are defined by a crop rectangle and represented in a
-struct :ref:`v4l2_rect <v4l2-rect>` by the coordinates of the top
+struct :c:type:`v4l2_rect` by the coordinates of the top
 left corner and the rectangle size. Both the coordinates and sizes are
 expressed in pixels.
 

@@ -357,7 +357,7 @@ sub-device for processing.
 The scaling operation changes the size of the image by scaling it to new
 dimensions. The scaling ratio isn't specified explicitly, but is implied
 from the original and scaled image sizes. Both sizes are represented by
-struct :ref:`v4l2_rect <v4l2-rect>`.
+struct :c:type:`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

index 1f4e75243a47..98797f255ce0 100644
@@ -41,7 +41,7 @@ Querying Capabilities
 
 Devices supporting the touch interface set the ``V4L2_CAP_VIDEO_CAPTURE`` flag
 and the ``V4L2_CAP_TOUCH`` flag in the ``capabilities`` field of
-:ref:`v4l2_capability <v4l2-capability>` returned by the
+:c:type:`v4l2_capability` returned by the
 :ref:`VIDIOC_QUERYCAP` ioctl.
 
 At least one of the read/write or streaming I/O methods must be

225 lines not on this page · raw message

index 675768f7c66a..4e980a7e9c9c 100644
@@ -19,7 +19,7 @@ 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
+:c:type:`v4l2_capability` returned by the
 :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>`

@@ -31,8 +31,8 @@ DRM). Buffers (planes) are allocated by a driver on behalf of an
 application. Next, these buffers are exported to the application as file
 descriptors using an API which is specific for an allocator driver. Only
 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
+are passed in struct :c:type:`v4l2_buffer` (or in struct
+:c:type:`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.
 

@@ -151,7 +151,7 @@ To start and stop capturing or displaying applications call the
    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 with another event it should examine
-   the struct :ref:`v4l2_buffer <v4l2-buffer>` ``timestamp`` of captured or
+   the struct :c:type:`v4l2_buffer` ``timestamp`` of captured or
    outputted buffers.
 
 Drivers implementing DMABUF importing I/O must support the

index 1f1518e4859d..75359739eb52 100644
@@ -49,7 +49,7 @@ control). This is needed since it is often required to atomically change
 several controls at once.
 
 Each of the new ioctls expects a pointer to a struct
-:ref:`v4l2_ext_controls <v4l2-ext-controls>`. This structure
+:c:type:`v4l2_ext_controls`. This structure
 contains a pointer to the control array, a count of the number of
 controls in that array and a control class. Control classes are used to
 group similar controls into a single class. For example, control class

@@ -65,12 +65,12 @@ It is also possible to use an empty control array (``count`` == 0) to check
 whether the specified control class is supported.
 
 The control array is a struct
-:ref:`v4l2_ext_control <v4l2-ext-control>` array. The
-:ref:`struct v4l2_ext_control <v4l2-ext-control>` structure is very similar to
-struct :ref:`v4l2_control <v4l2-control>`, except for the fact that
+:c:type:`v4l2_ext_control` array. The
+:c:type:`struct v4l2_ext_control <v4l2_ext_control>` structure is very similar to
+struct :c:type:`v4l2_control`, except for the fact that
 it also allows for 64-bit values and pointers to be passed.
 
-Since the struct :ref:`v4l2_ext_control <v4l2-ext-control>` supports
+Since the struct :c:type:`v4l2_ext_control` supports
 pointers it is now also possible to have controls with compound types
 such as N-dimensional arrays and/or structures. You need to specify the
 ``V4L2_CTRL_FLAG_NEXT_COMPOUND`` when enumerating controls to actually

index 95e9d2a41f1d..1fa082f34c6f 100644
@@ -47,7 +47,7 @@ clearer.
 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
+:c:type:`v4l2_pix_format` before calling the
 :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl. If this is not desired it
 should have the value ``V4L2_FIELD_ANY`` (0).
 

@@ -80,7 +80,7 @@ enum v4l2_field
 	  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:`v4l2_buffer <v4l2-buffer>` ``field`` can never be
+	  :c:type:`v4l2_buffer` ``field`` can never be
 	  ``V4L2_FIELD_ANY``.
 
     -  .. row 2

@@ -156,12 +156,12 @@ enum v4l2_field
 	  temporal order, i. e. the older one first. To indicate the field
 	  parity (whether the current field is a top or bottom field) the
 	  driver or application, depending on data direction, must set
-	  struct :ref:`v4l2_buffer <v4l2-buffer>` ``field`` to
+	  struct :c:type:`v4l2_buffer` ``field`` to
 	  ``V4L2_FIELD_TOP`` or ``V4L2_FIELD_BOTTOM``. Any two successive
 	  fields pair to build a frame. If fields are successive, without
 	  any dropped fields between them (fields can drop individually),
 	  can be determined from the struct
-	  :ref:`v4l2_buffer <v4l2-buffer>` ``sequence`` field. This
+	  :c:type:`v4l2_buffer` ``sequence`` field. This
 	  format cannot be selected when using the read/write I/O method
 	  since there is no way to communicate if a field was a top or
 	  bottom field.

index 7c73278849ca..452c6d59cad5 100644
@@ -22,7 +22,7 @@ to satisfy the request. Of course applications can also just query the
 current selection.
 
 A single mechanism exists to negotiate all data formats using the
-aggregate struct :ref:`v4l2_format <v4l2-format>` and the
+aggregate struct :c:type:`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

index bd19cef952f5..6d2ce539bd72 100644
@@ -37,9 +37,9 @@ Arguments
 ``length``
     Length of the memory area to map. This must be the same value as
     returned by the driver in the struct
-    :ref:`v4l2_buffer <v4l2-buffer>` ``length`` field for the
+    :c:type:`v4l2_buffer` ``length`` field for the
     single-planar API, and the same value as returned by the driver in
-    the struct :ref:`v4l2_plane <v4l2-plane>` ``length`` field for
+    the struct :c:type:`v4l2_plane` ``length`` field for
     the multi-planar API.
 
 ``prot``

@@ -92,9 +92,9 @@ Arguments
 ``offset``
     Offset of the buffer in device memory. This must be the same value
     as returned by the driver in the struct
-    :ref:`v4l2_buffer <v4l2-buffer>` ``m`` union ``offset`` field for
+    :c:type:`v4l2_buffer` ``m`` union ``offset`` field for
     the single-planar API, and the same value as returned by the driver
-    in the struct :ref:`v4l2_plane <v4l2-plane>` ``m`` union
+    in the struct :c:type:`v4l2_plane` ``m`` union
     ``mem_offset`` field for the multi-planar API.
 
 

index a1a4d8cb6c4b..c2f4043d7d2b 100644
@@ -34,9 +34,9 @@ Arguments
 ``length``
     Length of the mapped buffer. This must be the same value as given to
     :ref:`mmap() <func-mmap>` and returned by the driver in the struct
-    :ref:`v4l2_buffer <v4l2-buffer>` ``length`` field for the
+    :c:type:`v4l2_buffer` ``length`` field for the
     single-planar API and in the struct
-    :ref:`v4l2_plane <v4l2-plane>` ``length`` field for the
+    :c:type:`v4l2_plane` ``length`` field for the
     multi-planar API.
 
 

342 lines not on this page · raw message

index 7ad5d5e76163..670596c1a4f7 100644
@@ -8,7 +8,7 @@ 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
+:c:type:`v4l2_capability` returned by the
 :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` ioctl

@@ -39,10 +39,10 @@ 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` 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
+:c:type:`v4l2_buffer` are passed as sixth and second
 parameter to the :ref:`mmap() <func-mmap>` function. When using the
-multi-planar API, struct :ref:`v4l2_buffer <v4l2-buffer>` contains an
-array of struct :ref:`v4l2_plane <v4l2-plane>` structures, each
+multi-planar API, struct :c:type:`v4l2_buffer` contains an
+array of struct :c:type:`v4l2_plane` structures, each
 containing its own ``m.offset`` and ``length``. When using the
 multi-planar API, every plane of every buffer has to be mapped
 separately, so the number of calls to :ref:`mmap() <func-mmap>` should

@@ -218,7 +218,7 @@ to function, apart of this no limit exists on the number of buffers
 applications can enqueue in advance, or dequeue and process. They can
 also enqueue in a different order than buffers have been dequeued, and
 the driver can *fill* enqueued *empty* buffers in any order.  [#f2]_ The
-index number of a buffer (struct :ref:`v4l2_buffer <v4l2-buffer>`
+index number of a buffer (struct :c:type:`v4l2_buffer`
 ``index``) plays no role here, it only identifies the buffer.
 
 Initially all mapped buffers are in dequeued state, inaccessible by the

@@ -251,7 +251,7 @@ To start and stop capturing or output applications call the
    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 event it should examine
-   the struct ::ref:`v4l2_buffer <v4l2-buffer>` ``timestamp`` of captured
+   the struct ::c:type:`v4l2_buffer` ``timestamp`` of captured
    or outputted buffers.
 
 Drivers implementing memory mapping I/O must support the

index 58e872f66a07..789937900d14 100644
@@ -6,7 +6,7 @@ Single-planar format structure
 
 .. tabularcolumns:: |p{4.0cm}|p{2.5cm}|p{11.0cm}|
 
-.. _v4l2-pix-format:
+.. c:type:: v4l2_pix_format
 
 .. cssclass:: longtable
 

@@ -136,7 +136,7 @@ Single-planar format structure
        -  ``priv``
 
        -  This field indicates whether the remaining fields of the
-	  :ref:`struct v4l2_pix_format <v4l2-pix-format>` structure, also called the
+	  :c:type:`struct v4l2_pix_format <v4l2_pix_format>` structure, also called the
 	  extended fields, are valid. When set to
 	  ``V4L2_PIX_FMT_PRIV_MAGIC``, it indicates that the extended fields
 	  have been correctly initialized. When set to any other value it

@@ -152,7 +152,7 @@ Single-planar format structure
 	  To use the extended fields, applications must set the ``priv``
 	  field to ``V4L2_PIX_FMT_PRIV_MAGIC``, initialize all the extended
 	  fields and zero the unused bytes of the
-	  :ref:`struct v4l2_format <v4l2-format>` ``raw_data`` field.
+	  :c:type:`struct v4l2_format <v4l2_format>` ``raw_data`` field.
 
 	  When the ``priv`` field isn't set to ``V4L2_PIX_FMT_PRIV_MAGIC``
 	  drivers must act as if all the extended fields were set to zero.

index 6ec8ce639764..b214b818baa7 100644
@@ -4,17 +4,17 @@
 Multi-planar format structures
 ******************************
 
-The :ref:`struct v4l2_plane_pix_format <v4l2-plane-pix-format>` structures define size
+The :c:type:`struct v4l2_plane_pix_format <v4l2_plane_pix_format>` structures define size
 and layout for each of the planes in a multi-planar format. The
-:ref:`struct v4l2_pix_format_mplane <v4l2-pix-format-mplane>` structure contains
+:c:type:`struct v4l2_pix_format_mplane <v4l2_pix_format_mplane>` structure contains
 information common to all planes (such as image width and height) and an
-array of :ref:`struct v4l2_plane_pix_format <v4l2-plane-pix-format>` structures,
+array of :c:type:`struct v4l2_plane_pix_format <v4l2_plane_pix_format>` structures,
 describing all planes of that format.
 
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 
-.. _v4l2-plane-pix-format:
+.. c:type:: v4l2_plane_pix_format
 
 .. flat-table:: struct v4l2_plane_pix_format
     :header-rows:  0

@@ -37,7 +37,7 @@ describing all planes of that format.
        -  ``bytesperline``
 
        -  Distance in bytes between the leftmost pixels in two adjacent
-	  lines. See struct :ref:`v4l2_pix_format <v4l2-pix-format>`.
+	  lines. See struct :c:type:`v4l2_pix_format`.
 
     -  .. row 3
 

@@ -51,7 +51,7 @@ describing all planes of that format.
 
 .. tabularcolumns:: |p{4.4cm}|p{5.6cm}|p{7.5cm}|
 
-.. _v4l2-pix-format-mplane:
+.. c:type:: v4l2_pix_format_mplane
 
 .. flat-table:: struct v4l2_pix_format_mplane
     :header-rows:  0

@@ -66,7 +66,7 @@ describing all planes of that format.
        -  ``width``
 
        -  Image width in pixels. See struct
-	  :ref:`v4l2_pix_format <v4l2-pix-format>`.
+	  :c:type:`v4l2_pix_format`.
 
     -  .. row 2
 

@@ -75,7 +75,7 @@ describing all planes of that format.
        -  ``height``
 
        -  Image height in pixels. See struct
-	  :ref:`v4l2_pix_format <v4l2-pix-format>`.
+	  :c:type:`v4l2_pix_format`.
 
     -  .. row 3
 

@@ -92,7 +92,7 @@ describing all planes of that format.
 
        -  ``field``
 
-       -  See struct :ref:`v4l2_pix_format <v4l2-pix-format>`.
+       -  See struct :c:type:`v4l2_pix_format`.
 
     -  .. row 5
 

@@ -100,11 +100,11 @@ describing all planes of that format.
 
        -  ``colorspace``
 
-       -  See struct :ref:`v4l2_pix_format <v4l2-pix-format>`.
+       -  See struct :c:type:`v4l2_pix_format`.
 
     -  .. row 6
 
-       -  struct :ref:`v4l2_plane_pix_format <v4l2-plane-pix-format>`
+       -  struct :c:type:`v4l2_plane_pix_format`
 
        -  ``plane_fmt[VIDEO_MAX_PLANES]``
 

index 574294ec0a89..a97fc28e039d 100644
@@ -15,8 +15,8 @@ transfer functions. The third is the Y'CbCr encoding identifier (enum
 non-standard Y'CbCr encodings and the fourth is the quantization
 identifier (enum :ref:`v4l2_quantization <v4l2-quantization>`) to
 specify non-standard quantization methods. Most of the time only the
-colorspace field of struct :ref:`v4l2_pix_format <v4l2-pix-format>`
-or struct :ref:`v4l2_pix_format_mplane <v4l2-pix-format-mplane>`
+colorspace field of struct :c:type:`v4l2_pix_format`
+or struct :c:type:`v4l2_pix_format_mplane`
 needs to be filled in.
 
 .. note::

index 6866bcb7d229..a6b7871e39e7 100644
@@ -6,8 +6,8 @@
 Image Formats
 #############
 The V4L2 API was primarily designed for devices exchanging image data
-with applications. The :ref:`struct v4l2_pix_format <v4l2-pix-format>` and
-:ref:`struct v4l2_pix_format_mplane <v4l2-pix-format-mplane>` structures define the
+with applications. The :c:type:`struct v4l2_pix_format <v4l2_pix_format>` and
+:c:type:`struct v4l2_pix_format_mplane <v4l2_pix_format_mplane>` structures define the
 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

index 5fe2e1188230..bd0f88b01c9a 100644
@@ -46,16 +46,16 @@ Calls that distinguish between single and multi-planar APIs
 
 :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>`.
+    :c:type:`v4l2_pix_format_mplane` and
+    struct :c:type:`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>`
-    A new struct :ref:`v4l2_plane <v4l2-plane>` structure for
+    A new struct :c:type:`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>`.
+    :c:type:`v4l2_buffer`.
 
 :ref:`VIDIOC_REQBUFS <VIDIOC_REQBUFS>`
     Will allocate multi-planar buffers as requested.

index dcac379c484f..91596c0cc2f3 100644
@@ -9,7 +9,7 @@ Read/Write
 Input and output devices support the :ref:`read() <func-read>` and
 :ref:`write() <func-write>` function, respectively, when the
 ``V4L2_CAP_READWRITE`` flag in the ``capabilities`` field of struct
-:ref:`v4l2_capability <v4l2-capability>` returned by the
+:c:type:`v4l2_capability` returned by the
 :ref:`VIDIOC_QUERYCAP` ioctl is set.
 
 Drivers may need the CPU to copy the data, but they may also support DMA

index 94731a13efdb..5b47a28ac6d7 100644
@@ -16,19 +16,19 @@ cropping from an image inside a memory buffer. The application could
 configure a capture device to fill only a part of an image by abusing
 V4L2 API. Cropping a smaller image from a larger one is achieved by
 setting the field ``bytesperline`` at struct
-:ref:`v4l2_pix_format <v4l2-pix-format>`.
+:c:type:`v4l2_pix_format`.
 Introducing an image offsets could be done by modifying field ``m_userptr``
 at struct
-:ref:`v4l2_buffer <v4l2-buffer>` before calling
+:c:type:`v4l2_buffer` before calling
 :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
 the selection API the concepts of the padded target and constraints
-flags are introduced. Finally, struct :ref:`v4l2_crop <v4l2-crop>`
-and struct :ref:`v4l2_cropcap <v4l2-cropcap>` have no reserved
+flags are introduced. Finally, struct :c:type:`v4l2_crop`
+and struct :c:type:`v4l2_cropcap` have no reserved
 fields. Therefore there is no way to extend their functionality. The new
-struct :ref:`v4l2_selection <v4l2-selection>` provides a lot of place
+struct :c:type:`v4l2_selection` provides a lot of place
 for future extensions. Driver developers are encouraged to implement
 only selection API. The former cropping API would be simulated using the
 new one.

index 2320008f6063..75a14895aed7 100644
@@ -9,8 +9,8 @@ Video Standards
 Video devices typically support one or more different video standards or
 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
+:c:type:`v4l2_input` and struct
+:c:type:`v4l2_output` returned by the
 :ref:`VIDIOC_ENUMINPUT` and
 :ref:`VIDIOC_ENUMOUTPUT` ioctls, respectively.
 

@@ -58,8 +58,8 @@ output device which is:
 -  that does not support the video standard formats at all.
 
 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 :ref:`VIDIOC_G_STD <VIDIOC_G_STD>`,
+:c:type:`v4l2_input` and struct
+:c:type:`v4l2_output` to zero and the :ref:`VIDIOC_G_STD <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.
 

index b07b0f0b35d4..f9b93c53f75c 100644
@@ -25,7 +25,7 @@ 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
-a pointer to a struct :ref:`v4l2_streamparm <v4l2-streamparm>`, which
+a pointer to a struct :c:type:`v4l2_streamparm`, which
 contains a union holding separate parameters for input and output
 devices.
 

index c3df65c2e320..4064841d8963 100644
@@ -13,7 +13,7 @@ Tuners
 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>`
+field of the respective struct :c:type:`v4l2_input`
 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.

@@ -24,7 +24,7 @@ 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
-struct :ref:`v4l2_tuner <v4l2-tuner>` returned by :ref:`VIDIOC_G_TUNER <VIDIOC_G_TUNER>`
+struct :c:type:`v4l2_tuner` returned by :ref:`VIDIOC_G_TUNER <VIDIOC_G_TUNER>`
 also contains signal status information applicable when the tuner of the
 current video or radio input is queried.
 

@@ -46,7 +46,7 @@ video signal for radiation or connection to the antenna input of a TV
 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
+:c:type:`v4l2_output` returned by the
 :ref:`VIDIOC_ENUMOUTPUT` ioctl is set to
 ``V4L2_OUTPUT_TYPE_MODULATOR`` and its ``modulator`` field contains the
 index number of the modulator.

@@ -68,7 +68,7 @@ To query and change modulator properties applications use the
 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
+:c:type:`v4l2_capability` returned by the
 :ref:`VIDIOC_QUERYCAP` ioctl when the device has
 one or more modulators.
 

@@ -79,7 +79,7 @@ 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
-a pointer to a struct :ref:`v4l2_frequency <v4l2-frequency>`. These
+a pointer to a struct :c:type:`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
 the device is a radio device.

index 0371e068c50b..dc2893a60d65 100644
@@ -8,7 +8,7 @@ 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
+:c:type:`v4l2_capability` returned by 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` ioctl

@@ -18,8 +18,8 @@ This I/O method combines advantages of the read/write and memory mapping
 methods. Buffers (planes) are allocated by the application itself, and
 can reside for example in virtual or shared memory. Only pointers to
 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
+struct :c:type:`v4l2_buffer` (or in struct
+:c:type:`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` with the desired buffer type.
 No buffers (planes) are allocated beforehand, consequently they are not

@@ -94,7 +94,7 @@ To start and stop capturing or output applications call the
    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 with another event it should examine
-   the struct :ref:`v4l2_buffer <v4l2-buffer>` ``timestamp`` of captured or
+   the struct :c:type:`v4l2_buffer` ``timestamp`` of captured or
    outputted buffers.
 
 Drivers implementing user pointer I/O must support the

index 5e41a8505301..785d4cdd2f85 100644
@@ -114,14 +114,14 @@ DVB device nodes. Add support for Tuner sub-device.
 Rewrote Colorspace chapter, added new enum
 :ref:`v4l2_ycbcr_encoding <v4l2-ycbcr-encoding>` and enum
 :ref:`v4l2_quantization <v4l2-quantization>` fields to struct
-:ref:`v4l2_pix_format <v4l2-pix-format>`, struct
-:ref:`v4l2_pix_format_mplane <v4l2-pix-format-mplane>` and struct
+:c:type:`v4l2_pix_format`, struct
+:c:type:`v4l2_pix_format_mplane` and struct
 :ref:`v4l2_mbus_framefmt <v4l2-mbus-framefmt>`.
 
 
 :revision: 3.17 / 2014-08-04 (*lp, hv*)
 
-Extended struct :ref:`v4l2_pix_format <v4l2-pix-format>`. Added
+Extended struct :c:type:`v4l2_pix_format`. Added
 format flags. Added compound control types and VIDIOC_QUERY_EXT_CTRL.
 
 

index d3f00715fbc1..a205fb87d566 100644
@@ -16,7 +16,7 @@ To learn about the number and attributes of the available inputs and
 outputs applications can enumerate them with the
 :ref:`VIDIOC_ENUMINPUT` and
 :ref:`VIDIOC_ENUMOUTPUT` ioctl, respectively. The
-struct :ref:`v4l2_input <v4l2-input>` returned by the
+struct :c:type:`v4l2_input` returned by the
 :ref:`VIDIOC_ENUMINPUT` ioctl also contains signal
 :status information applicable when the current video input is queried.
 

index dc75f21e4b4c..c53fdcc3666a 100644
@@ -39,14 +39,14 @@ over buffers is required. This ioctl can be called multiple times to
 create buffers of different sizes.
 
 To allocate the device buffers applications must initialize the relevant
-fields of the :ref:`struct v4l2_create_buffers <v4l2-create-buffers>` structure. The
+fields of the :c:type:`struct v4l2_create_buffers <v4l2_create_buffers>` structure. The
 ``count`` field must be set to the number of requested buffers, the
 ``memory`` field specifies the requested I/O method and the ``reserved``
 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
+:c:type:`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
 requested format is supported by the driver. Based on the format's

@@ -71,7 +71,7 @@ the ``index`` fields respectively. On return ``count`` can be smaller
 than the number requested.
 
 
-.. _v4l2-create-buffers:
+.. c:type:: v4l2_create_buffers
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 

@@ -115,7 +115,7 @@ than the number requested.
 
     -  .. row 4
 
-       -  struct :ref:`v4l2_format <v4l2-format>`
+       -  struct :c:type:`v4l2_format`
 
        -  ``format``
 

index 9b7c99eef717..945596fcd65f 100644
@@ -50,7 +50,7 @@ support cropping and/or scaling and/or have non-square pixels, and for
 overlay devices.
 
 
-.. _v4l2-cropcap:
+.. c:type:: v4l2_cropcap
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 

@@ -98,7 +98,7 @@ overlay devices.
 
     -  .. row 4
 
-       -  struct :ref:`v4l2_fract <v4l2-fract>`
+       -  struct :c:type:`v4l2_fract`
 
        -  ``pixelaspect``
 

@@ -165,7 +165,7 @@ appropriately. The generic error codes are described at the
 :ref:`Generic Error Codes <gen-errors>` chapter.
 
 EINVAL
-    The struct :ref:`v4l2_cropcap <v4l2-cropcap>` ``type`` is
+    The struct :c:type:`v4l2_cropcap` ``type`` is
     invalid.
 
 ENODATA

index 9c97527dc2cf..f9d76f3d519d 100644
@@ -48,7 +48,7 @@ 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
+:c:type:`v4l2_dbg_chip_info` and call
 :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.

@@ -124,7 +124,7 @@ instructions.
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 
-.. _v4l2-dbg-chip-info:
+.. c:type:: v4l2_dbg_chip_info
 
 .. flat-table:: struct v4l2_dbg_chip_info
     :header-rows:  0

index 6eeb0de24b50..08f3c510e440 100644
@@ -49,7 +49,7 @@ superuser privileges. Additionally the Linux kernel must be compiled
 with the ``CONFIG_VIDEO_ADV_DEBUG`` option to enable these ioctls.
 
 To write a register applications must initialize all fields of a struct
-:ref:`v4l2_dbg_register <v4l2-dbg-register>` except for ``size`` and
+:c:type:`v4l2_dbg_register` except for ``size`` and
 call ``VIDIOC_DBG_S_REGISTER`` with a pointer to this structure. The
 ``match.type`` and ``match.addr`` or ``match.name`` fields select a chip
 on the TV card, the ``reg`` field specifies a register number and the

@@ -87,7 +87,7 @@ instructions.
 
 .. tabularcolumns:: |p{3.5cm}|p{3.5cm}|p{3.5cm}|p{7.0cm}|
 
-.. _v4l2-dbg-match:
+.. c:type:: v4l2_dbg_match
 
 .. flat-table:: struct v4l2_dbg_match
     :header-rows:  0

@@ -131,7 +131,7 @@ instructions.
 
 
 
-.. _v4l2-dbg-register:
+.. c:type:: v4l2_dbg_register
 
 .. flat-table:: struct v4l2_dbg_register
     :header-rows:  0

index 6077caac6086..cade4603e138 100644
@@ -30,7 +30,7 @@ Arguments
     File descriptor returned by :ref:`open() <func-open>`.
 
 ``argp``
-    pointer to struct :ref:`v4l2_decoder_cmd <v4l2-decoder-cmd>`.
+    pointer to struct :c:type:`v4l2_decoder_cmd`.
 
 
 Description

@@ -40,7 +40,7 @@ These ioctls control an audio/video (usually MPEG-) decoder.
 ``VIDIOC_DECODER_CMD`` sends a command to the decoder,
 ``VIDIOC_TRY_DECODER_CMD`` can be used to try a command without actually
 executing it. To send a command applications must initialize all fields
-of a struct :ref:`v4l2_decoder_cmd <v4l2-decoder-cmd>` and call
+of a struct :c:type:`v4l2_decoder_cmd` and call
 ``VIDIOC_DECODER_CMD`` or ``VIDIOC_TRY_DECODER_CMD`` with a pointer to
 this structure.
 

@@ -61,7 +61,7 @@ introduced in Linux 3.3.
 
 .. tabularcolumns:: |p{1.1cm}|p{2.4cm}|p{1.2cm}|p{1.6cm}|p{10.6cm}|
 
-.. _v4l2-decoder-cmd:
+.. c:type:: v4l2_decoder_cmd
 
 .. cssclass:: longtable
 

index 067e0aa27918..cf0e98f5112f 100644
@@ -32,7 +32,7 @@ Description
 ===========
 
 Dequeue an event from a video device. No input is required for this
-ioctl. All the fields of the struct :ref:`v4l2_event <v4l2-event>`
+ioctl. All the fields of the struct :c:type:`v4l2_event`
 structure are filled by the driver. The file handle will also receive
 exceptions which the application may get by e.g. using the select system
 call.

@@ -40,7 +40,7 @@ call.
 
 .. tabularcolumns:: |p{3.0cm}|p{4.3cm}|p{2.5cm}|p{7.7cm}|
 
-.. _v4l2-event:
+.. c:type:: v4l2_event
 
 .. cssclass: longtable
 

@@ -71,7 +71,7 @@ call.
     -  .. row 3
 
        -
-       -  struct :ref:`v4l2_event_vsync <v4l2-event-vsync>`
+       -  struct :c:type:`v4l2_event_vsync`
 
        -  ``vsync``
 

@@ -80,7 +80,7 @@ call.
     -  .. row 4
 
        -
-       -  struct :ref:`v4l2_event_ctrl <v4l2-event-ctrl>`
+       -  struct :c:type:`v4l2_event_ctrl`
 
        -  ``ctrl``
 

@@ -89,7 +89,7 @@ call.
     -  .. row 5
 
        -
-       -  struct :ref:`v4l2_event_frame_sync <v4l2-event-frame-sync>`
+       -  struct :c:type:`v4l2_event_frame_sync`
 
        -  ``frame_sync``
 

@@ -98,7 +98,7 @@ call.
     -  .. row 6
 
        -
-       -  struct :ref:`v4l2_event_motion_det <v4l2-event-motion-det>`
+       -  struct :c:type:`v4l2_event_motion_det`
 
        -  ``motion_det``
 

@@ -107,7 +107,7 @@ call.
     -  .. row 7
 
        -
-       -  struct :ref:`v4l2_event_src_change <v4l2-event-src-change>`
+       -  struct :c:type:`v4l2_event_src_change`
 
        -  ``src_change``
 

@@ -205,7 +205,7 @@ call.
        -  1
 
        -  This event is triggered on the vertical sync. This event has a
-	  struct :ref:`v4l2_event_vsync <v4l2-event-vsync>` associated
+	  struct :c:type:`v4l2_event_vsync` associated
 	  with it.
 
     -  .. row 3

@@ -228,10 +228,10 @@ call.
 	  which you want to receive events. This event is triggered if the
 	  control's value changes, if a button control is pressed or if the
 	  control's flags change. This event has a struct
-	  :ref:`v4l2_event_ctrl <v4l2-event-ctrl>` associated with it.
+	  :c:type:`v4l2_event_ctrl` associated with it.
 	  This struct contains much of the same information as struct
 	  :ref:`v4l2_queryctrl <v4l2-queryctrl>` and struct
-	  :ref:`v4l2_control <v4l2-control>`.
+	  :c:type:`v4l2_control`.
 
 	  If the event is generated due to a call to
 	  :ref:`VIDIOC_S_CTRL <VIDIOC_G_CTRL>` or

@@ -243,7 +243,7 @@ call.
 
 	  This event type will ensure that no information is lost when more
 	  events are raised than there is room internally. In that case the
-	  struct :ref:`v4l2_event_ctrl <v4l2-event-ctrl>` of the
+	  struct :c:type:`v4l2_event_ctrl` of the
 	  second-oldest event is kept, but the ``changes`` field of the
 	  second-oldest event is ORed with the ``changes`` field of the
 	  oldest event.

@@ -256,13 +256,13 @@ call.
 
        -  Triggered immediately when the reception of a frame has begun.
 	  This event has a struct
-	  :ref:`v4l2_event_frame_sync <v4l2-event-frame-sync>`
+	  :c:type:`v4l2_event_frame_sync`
 	  associated with it.
 
 	  If the hardware needs to be stopped in the case of a buffer
 	  underrun it might not be able to generate this event. In such
 	  cases the ``frame_sequence`` field in struct
-	  :ref:`v4l2_event_frame_sync <v4l2-event-frame-sync>` will not
+	  :c:type:`v4l2_event_frame_sync` will not
 	  be incremented. This causes two consecutive frame sequence numbers
 	  to have n times frame interval in between them.
 

@@ -281,7 +281,7 @@ call.
 	  receive events.
 
 	  This event has a struct
-	  :ref:`v4l2_event_src_change <v4l2-event-src-change>`
+	  :c:type:`v4l2_event_src_change`
 	  associated with it. The ``changes`` bitfield denotes what has
 	  changed for the subscribed pad. If multiple events occurred before
 	  application could dequeue them, then the changes will have the

@@ -295,7 +295,7 @@ call.
 
        -  Triggered whenever the motion detection state for one or more of
 	  the regions changes. This event has a struct
-	  :ref:`v4l2_event_motion_det <v4l2-event-motion-det>`
+	  :c:type:`v4l2_event_motion_det`
 	  associated with it.
 
     -  .. row 8

@@ -310,7 +310,7 @@ call.
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 
-.. _v4l2-event-vsync:
+.. c:type:: v4l2_event_vsync
 
 .. flat-table:: struct v4l2_event_vsync
     :header-rows:  0

@@ -330,7 +330,7 @@ call.
 
 .. tabularcolumns:: |p{3.5cm}|p{3.0cm}|p{1.8cm}|p{8.5cm}|
 
-.. _v4l2-event-ctrl:
+.. c:type:: v4l2_event_ctrl
 
 .. flat-table:: struct v4l2_event_ctrl
     :header-rows:  0

@@ -439,7 +439,7 @@ call.
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 
-.. _v4l2-event-frame-sync:
+.. c:type:: v4l2_event_frame_sync
 
 .. flat-table:: struct v4l2_event_frame_sync
     :header-rows:  0

@@ -459,7 +459,7 @@ call.
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 
-.. _v4l2-event-src-change:
+.. c:type:: v4l2_event_src_change
 
 .. flat-table:: struct v4l2_event_src_change
     :header-rows:  0

@@ -480,7 +480,7 @@ call.
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 
-.. _v4l2-event-motion-det:
+.. c:type:: v4l2_event_motion_det
 
 .. flat-table:: struct v4l2_event_motion_det
     :header-rows:  0

index 741718baf14b..7cb78a0067ac 100644
@@ -36,7 +36,7 @@ Description
 
 To query the capabilities of the DV receiver/transmitter applications
 initialize the ``pad`` field to 0, zero the reserved array of struct
-:ref:`v4l2_dv_timings_cap <v4l2-dv-timings-cap>` and call the
+:c:type:`v4l2_dv_timings_cap` and call the
 ``VIDIOC_DV_TIMINGS_CAP`` ioctl on a video node and the driver will fill
 in the structure.
 

@@ -50,14 +50,14 @@ queried by calling the ``VIDIOC_SUBDEV_DV_TIMINGS_CAP`` ioctl directly
 on a subdevice node. The capabilities are specific to inputs (for DV
 receivers) or outputs (for DV transmitters), applications must specify
 the desired pad number in the struct
-:ref:`v4l2_dv_timings_cap <v4l2-dv-timings-cap>` ``pad`` field and
+:c:type:`v4l2_dv_timings_cap` ``pad`` field and
 zero the ``reserved`` array. Attempts to query capabilities on a pad
 that doesn't support them will return an ``EINVAL`` error code.
 
 
 .. tabularcolumns:: |p{1.2cm}|p{3.0cm}|p{13.3cm}|
 
-.. _v4l2-bt-timings-cap:
+.. c:type:: v4l2_bt_timings_cap
 
 .. flat-table:: struct v4l2_bt_timings_cap
     :header-rows:  0

@@ -144,7 +144,7 @@ that doesn't support them will return an ``EINVAL`` error code.
 
 .. tabularcolumns:: |p{1.0cm}|p{3.5cm}|p{3.5cm}|p{9.5cm}|
 
-.. _v4l2-dv-timings-cap:
+.. c:type:: v4l2_dv_timings_cap
 
 .. flat-table:: struct v4l2_dv_timings_cap
     :header-rows:  0

@@ -190,7 +190,7 @@ that doesn't support them will return an ``EINVAL`` error code.
     -  .. row 5
 
        -
-       -  struct :ref:`v4l2_bt_timings_cap <v4l2-bt-timings-cap>`
+       -  struct :c:type:`v4l2_bt_timings_cap`
 
        -  ``bt``
 

index 802eac3ca9ec..b724ec36a25c 100644
@@ -40,7 +40,7 @@ These ioctls control an audio/video (usually MPEG-) encoder.
 executing it.
 
 To send a command applications must initialize all fields of a struct
-:ref:`v4l2_encoder_cmd <v4l2-encoder-cmd>` and call
+:c:type:`v4l2_encoder_cmd` and call
 ``VIDIOC_ENCODER_CMD`` or ``VIDIOC_TRY_ENCODER_CMD`` with a pointer to
 this structure.
 

@@ -67,7 +67,7 @@ introduced in Linux 2.6.21.
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 
-.. _v4l2-encoder-cmd:
+.. c:type:: v4l2_encoder_cmd
 
 .. flat-table:: struct v4l2_encoder_cmd
     :header-rows:  0

index db9613c9b4bd..dfe4d737b0aa 100644
@@ -43,7 +43,7 @@ this list.
 
 To query the available timings, applications initialize the ``index``
 field, set the ``pad`` field to 0, zero the reserved array of struct
-:ref:`v4l2_enum_dv_timings <v4l2-enum-dv-timings>` and call the
+:c:type:`v4l2_enum_dv_timings` and call the
 ``VIDIOC_ENUM_DV_TIMINGS`` ioctl on a video node 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 supported

@@ -60,12 +60,12 @@ by calling the ``VIDIOC_SUBDEV_ENUM_DV_TIMINGS`` ioctl directly on a
 subdevice node. The DV timings are specific to inputs (for DV receivers)
 or outputs (for DV transmitters), applications must specify the desired
 pad number in the struct
-:ref:`v4l2_enum_dv_timings <v4l2-enum-dv-timings>` ``pad`` field.
+:c:type:`v4l2_enum_dv_timings` ``pad`` field.
 Attempts to enumerate timings on a pad that doesn't support them will
 return an ``EINVAL`` error code.
 
 
-.. _v4l2-enum-dv-timings:
+.. c:type:: v4l2_enum_dv_timings
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 

@@ -104,7 +104,7 @@ return an ``EINVAL`` error code.
 
     -  .. row 4
 
-       -  struct :ref:`v4l2_dv_timings <v4l2-dv-timings>`
+       -  struct :c:type:`v4l2_dv_timings`
 
        -  ``timings``
 

@@ -119,7 +119,7 @@ appropriately. The generic error codes are described at the
 :ref:`Generic Error Codes <gen-errors>` chapter.
 
 EINVAL
-    The struct :ref:`v4l2_enum_dv_timings <v4l2-enum-dv-timings>`
+    The struct :c:type:`v4l2_enum_dv_timings`
     ``index`` is out of bounds or the ``pad`` number is invalid.
 
 ENODATA

index 1a4834934085..1df8fccf067f 100644
@@ -32,7 +32,7 @@ Description
 ===========
 
 To enumerate image formats applications initialize the ``type`` and
-``index`` field of struct :ref:`v4l2_fmtdesc <v4l2-fmtdesc>` and call
+``index`` field of struct :c:type:`v4l2_fmtdesc` and call
 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

@@ -46,7 +46,7 @@ one until ``EINVAL`` is returned.
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 
-.. _v4l2-fmtdesc:
+.. c:type:: v4l2_fmtdesc
 
 .. flat-table:: struct v4l2_fmtdesc
     :header-rows:  0

@@ -167,5 +167,5 @@ appropriately. The generic error codes are described at the
 :ref:`Generic Error Codes <gen-errors>` chapter.
 
 EINVAL
-    The struct :ref:`v4l2_fmtdesc <v4l2-fmtdesc>` ``type`` is not
+    The struct :c:type:`v4l2_fmtdesc` ``type`` is not
     supported or the ``index`` is out of bounds.

index f9bb6fb4ca8e..07e94420c4c5 100644
@@ -26,7 +26,7 @@ Arguments
     File descriptor returned by :ref:`open() <func-open>`.
 
 ``argp``
-    Pointer to a struct :ref:`v4l2_frmivalenum <v4l2-frmivalenum>`
+    Pointer to a struct :c:type:`v4l2_frmivalenum`
     structure that contains a pixel format and size and receives a frame
     interval.
 

@@ -101,7 +101,7 @@ the application, *OUT* denotes values that the driver fills in. The
 application should zero out all members except for the *IN* fields.
 
 
-.. _v4l2-frmival-stepwise:
+.. c:type:: v4l2_frmival_stepwise
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 

@@ -113,7 +113,7 @@ application should zero out all members except for the *IN* fields.
 
     -  .. row 1
 
-       -  struct :ref:`v4l2_fract <v4l2-fract>`
+       -  struct :c:type:`v4l2_fract`
 
        -  ``min``
 

@@ -121,7 +121,7 @@ application should zero out all members except for the *IN* fields.
 
     -  .. row 2
 
-       -  struct :ref:`v4l2_fract <v4l2-fract>`
+       -  struct :c:type:`v4l2_fract`
 
        -  ``max``
 

@@ -129,7 +129,7 @@ application should zero out all members except for the *IN* fields.
 
     -  .. row 3
 
-       -  struct :ref:`v4l2_fract <v4l2-fract>`
+       -  struct :c:type:`v4l2_fract`
 
        -  ``step``
 

@@ -137,7 +137,7 @@ application should zero out all members except for the *IN* fields.
 
 
 
-.. _v4l2-frmivalenum:
+.. c:type:: v4l2_frmivalenum
 
 .. flat-table:: struct v4l2_frmivalenum
     :header-rows:  0

@@ -200,7 +200,7 @@ application should zero out all members except for the *IN* fields.
     -  .. row 7
 
        -
-       -  struct :ref:`v4l2_fract <v4l2-fract>`
+       -  struct :c:type:`v4l2_fract`
 
        -  ``discrete``
 

@@ -209,7 +209,7 @@ application should zero out all members except for the *IN* fields.
     -  .. row 8
 
        -
-       -  struct :ref:`v4l2_frmival_stepwise <v4l2-frmival-stepwise>`
+       -  struct :c:type:`v4l2_frmival_stepwise`
 
        -  ``stepwise``
 

index 4fb19b75abf1..a4ddfe9f8956 100644
@@ -26,7 +26,7 @@ Arguments
     File descriptor returned by :ref:`open() <func-open>`.
 
 ``argp``
-    Pointer to a struct :ref:`v4l2_frmsizeenum <v4l2-frmsizeenum>`
+    Pointer to a struct :c:type:`v4l2_frmsizeenum`
     that contains an index and pixel format and receives a frame width
     and height.
 

@@ -90,7 +90,7 @@ the application, *OUT* denotes values that the driver fills in. The
 application should zero out all members except for the *IN* fields.
 
 
-.. _v4l2-frmsize-discrete:
+.. c:type:: v4l2_frmsize_discrete
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 

@@ -118,7 +118,7 @@ application should zero out all members except for the *IN* fields.
 
 
 
-.. _v4l2-frmsize-stepwise:
+.. c:type:: v4l2_frmsize_stepwise
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 

@@ -178,7 +178,7 @@ application should zero out all members except for the *IN* fields.
 
 
 
-.. _v4l2-frmsizeenum:
+.. c:type:: v4l2_frmsizeenum
 
 .. flat-table:: struct v4l2_frmsizeenum
     :header-rows:  0

@@ -223,7 +223,7 @@ application should zero out all members except for the *IN* fields.
     -  .. row 5
 
        -
-       -  struct :ref:`v4l2_frmsize_discrete <v4l2-frmsize-discrete>`
+       -  struct :c:type:`v4l2_frmsize_discrete`
 
        -  ``discrete``
 

@@ -232,7 +232,7 @@ application should zero out all members except for the *IN* fields.
     -  .. row 6
 
        -
-       -  struct :ref:`v4l2_frmsize_stepwise <v4l2-frmsize-stepwise>`
+       -  struct :c:type:`v4l2_frmsize_stepwise`
 
        -  ``stepwise``
 

index 60ae938d5ef8..c38478227031 100644
@@ -34,7 +34,7 @@ Description
 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
+:c:type:`v4l2_frequency_band` and call the
 :ref:`VIDIOC_ENUM_FREQ_BANDS` ioctl with a pointer to this structure.
 
 This ioctl is supported if the ``V4L2_TUNER_CAP_FREQ_BANDS`` capability

@@ -43,7 +43,7 @@ of the corresponding tuner/modulator is set.
 
 .. tabularcolumns:: |p{2.9cm}|p{2.9cm}|p{5.8cm}|p{2.9cm}|p{3.0cm}|
 
-.. _v4l2-frequency-band:
+.. c:type:: v4l2_frequency_band
 
 .. flat-table:: struct v4l2_frequency_band
     :header-rows:  0

@@ -58,10 +58,10 @@ of the corresponding tuner/modulator is set.
        -  ``tuner``
 
        -  The tuner or modulator index number. This is the same value as in
-	  the struct :ref:`v4l2_input <v4l2-input>` ``tuner`` field and
-	  the struct :ref:`v4l2_tuner <v4l2-tuner>` ``index`` field, or
-	  the struct :ref:`v4l2_output <v4l2-output>` ``modulator`` field
-	  and the struct :ref:`v4l2_modulator <v4l2-modulator>` ``index``
+	  the struct :c:type:`v4l2_input` ``tuner`` field and
+	  the struct :c:type:`v4l2_tuner` ``index`` field, or
+	  the struct :c:type:`v4l2_output` ``modulator`` field
+	  and the struct :c:type:`v4l2_modulator` ``index``
 	  field.
 
     -  .. row 2

@@ -71,7 +71,7 @@ of the corresponding tuner/modulator is set.
        -  ``type``
 
        -  The tuner type. This is the same value as in the struct
-	  :ref:`v4l2_tuner <v4l2-tuner>` ``type`` field. The type must be
+	  :c:type:`v4l2_tuner` ``type`` field. The type must be
 	  set to ``V4L2_TUNER_RADIO`` for ``/dev/radioX`` device nodes, and
 	  to ``V4L2_TUNER_ANALOG_TV`` for all others. Set this field to
 	  ``V4L2_TUNER_RADIO`` for modulators (currently only radio

index c9d9eb60551e..74bc3ed0bdd8 100644
@@ -33,14 +33,14 @@ 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 :ref:`VIDIOC_ENUMAUDIO`
+:c:type:`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
 zero, incrementing by one until the driver returns ``EINVAL``.
 
 See :ref:`VIDIOC_G_AUDIO <VIDIOC_G_AUDIO>` for a description of struct
-:ref:`v4l2_audio <v4l2-audio>`.
+:c:type:`v4l2_audio`.
 
 
 Return Value

index a7a27327fe88..4470a1ece5cf 100644
@@ -33,7 +33,7 @@ Description
 
 To query the attributes of an audio output applications initialize the
 ``index`` field and zero out the ``reserved`` array of a struct
-:ref:`v4l2_audioout <v4l2-audioout>` and call the ``VIDIOC_G_AUDOUT``
+:c:type:`v4l2_audioout` and call the ``VIDIOC_G_AUDOUT``
 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 outputs applications shall begin at index

@@ -45,7 +45,7 @@ zero, incrementing by one until the driver returns ``EINVAL``.
     to a sound card are not audio outputs in this sense.
 
 See :ref:`VIDIOC_G_AUDIOout <VIDIOC_G_AUDOUT>` for a description of struct
-:ref:`v4l2_audioout <v4l2-audioout>`.
+:c:type:`v4l2_audioout`.
 
 
 Return Value

index 8f6c603819d8..be03e04e3dac 100644
@@ -32,7 +32,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
+``index`` field of struct :c:type:`v4l2_input` and call the
 :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

@@ -41,7 +41,7 @@ at index zero, incrementing by one until the driver returns ``EINVAL``.
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 
-.. _v4l2-input:
+.. c:type:: v4l2_input
 
 .. flat-table:: struct v4l2_input
     :header-rows:  0

@@ -104,7 +104,7 @@ at index zero, incrementing by one until the driver returns ``EINVAL``.
        -  Capture devices can have zero or more tuners (RF demodulators).
 	  When the ``type`` is set to ``V4L2_INPUT_TYPE_TUNER`` this is an
 	  RF connector and this field identifies the tuner. It corresponds
-	  to struct :ref:`v4l2_tuner <v4l2-tuner>` field ``index``. For
+	  to struct :c:type:`v4l2_tuner` field ``index``. For
 	  details on tuners see :ref:`tuner`.
 
     -  .. row 6

@@ -377,5 +377,5 @@ appropriately. The generic error codes are described at the
 :ref:`Generic Error Codes <gen-errors>` chapter.
 
 EINVAL
-    The struct :ref:`v4l2_input <v4l2-input>` ``index`` is out of
+    The struct :c:type:`v4l2_input` ``index`` is out of
     bounds.

index d660c37d3516..763066ab99b6 100644
@@ -32,7 +32,7 @@ Description
 ===========
 
 To query the attributes of a video outputs applications initialize the
-``index`` field of struct :ref:`v4l2_output <v4l2-output>` and call
+``index`` field of struct :c:type:`v4l2_output` and call
 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

@@ -42,7 +42,7 @@ EINVAL.
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 
-.. _v4l2-output:
+.. c:type:: v4l2_output
 
 .. flat-table:: struct v4l2_output
     :header-rows:  0

@@ -105,7 +105,7 @@ EINVAL.
        -  Output devices can have zero or more RF modulators. When the
 	  ``type`` is ``V4L2_OUTPUT_TYPE_MODULATOR`` this is an RF connector
 	  and this field identifies the modulator. It corresponds to struct
-	  :ref:`v4l2_modulator <v4l2-modulator>` field ``index``. For
+	  :c:type:`v4l2_modulator` field ``index``. For
 	  details on modulators see :ref:`tuner`.
 
     -  .. row 6

@@ -222,5 +222,5 @@ appropriately. The generic error codes are described at the
 :ref:`Generic Error Codes <gen-errors>` chapter.
 
 EINVAL
-    The struct :ref:`v4l2_output <v4l2-output>` ``index`` is out of
+    The struct :c:type:`v4l2_output` ``index`` is out of
     bounds.

index 5bd85932d33b..eaac7a2e14c4 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 :ref:`VIDIOC_ENUMSTD`
+:c:type:`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

@@ -42,7 +42,7 @@ enumerate a different set of standards after switching the video input
 or output. [#f1]_
 
 
-.. _v4l2-standard:
+.. c:type:: v4l2_standard
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 

@@ -71,7 +71,7 @@ or output. [#f1]_
 	  set as custom standards. Multiple bits can be set if the hardware
 	  does not distinguish between these standards, however separate
 	  indices do not indicate the opposite. The ``id`` must be unique.
-	  No other enumerated :ref:`struct v4l2_standard <v4l2-standard>` structure,
+	  No other enumerated :c:type:`struct v4l2_standard <v4l2_standard>` structure,
 	  for this input or output anyway, can contain the same set of bits.
 
     -  .. row 3

@@ -86,7 +86,7 @@ or output. [#f1]_
 
     -  .. row 4
 
-       -  struct :ref:`v4l2_fract <v4l2-fract>`
+       -  struct :c:type:`v4l2_fract`
 
        -  ``frameperiod``
 

@@ -112,7 +112,7 @@ or output. [#f1]_
 
 
 
-.. _v4l2-fract:
+.. c:type:: v4l2_fract
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 

@@ -411,7 +411,7 @@ appropriately. The generic error codes are described at the
 :ref:`Generic Error Codes <gen-errors>` chapter.
 
[… more lines in the raw message]

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

index f7b8d643fd28..650757ad8aed 100644

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

index 224a09c2c53d..ebf2514464fc 100644

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

index da8db3b42262..b21794300efd 100644

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

index 1689b0c523d7..b99032e59ebe 100644

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

index 6ced76016246..53a6ebe6f744 100644

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

index f143a6b3d927..379f2be0bc92 100644

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

index 3decb810c8bb..6b5727439db2 100644

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

index ee72c69f902a..01561ddfe73b 100644

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

index 00f783692752..7ade2f7d62be 100644

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

index ebeb7e9a48ea..dd6c062d267c 100644

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

index d517c7bb2182..9cbe70098b2b 100644

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

index 32735d20066c..1364a918fbce 100644

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

index 387c71c209bc..c56c5bc7beb5 100644

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

index c7729e67e8d9..5d209efa0965 100644

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

index e0613e2d667f..7750948fc61b 100644

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

index 9e9af1dd4f29..021b96ee641d 100644

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

index 85b5afa48474..af38b2568e3b 100644

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

index abda04b07999..4df7227e0490 100644

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

index 91162f5ea6b2..c351eb9f6b0e 100644

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

index 4658a4715a5e..01b7f26bf22f 100644

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

index c3f6c1c615f6..c20e1c7d5f89 100644

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

index dd3f2e069fcb..727238fc2337 100644

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

index 230ebcb8aa4b..0d16853b1b51 100644

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

index 8edfc7931ec6..1edd76c06e0a 100644

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

index 97a394bbcc9c..2824ead350b9 100644

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

index db3ad928ec1c..ef32e28e57c7 100644

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

index 39c9bf8af47a..195f0a3d783c 100644

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

index efbe3a1f1134..e33969b9d3da 100644

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

index 25dfaa44af3b..972d5b3c74aa 100644

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

index 3df2099ceeb9..db7145016571 100644

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

index b0fb5203e65f..80517ec8a847 100644

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

index f8405bf344fa..7580174a6ed1 100644

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

index 697fc40434cc..d581ff6cf458 100644

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

index 04eee095952b..0202a78cbeb0 100644

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

index 93794e015e7c..0419e2051759 100644
@@ -87,7 +87,7 @@ Querying Capabilities
 The V4L ``VIDIOCGCAP`` ioctl is equivalent to V4L2's
 :ref:`VIDIOC_QUERYCAP`.
 
-The ``name`` field in struct :c:type:`struct video_capability` became
+The ``name`` field in struct ``video_capability`` became
 ``card`` in struct :c:type:`v4l2_capability`, ``type``
 was replaced by ``capabilities``. Note V4L2 does not distinguish between
 device types like this, better think of basic video input, video output

@@ -264,7 +264,7 @@ Video Sources
 =============
 
 V4L provides the ``VIDIOCGCHAN`` and ``VIDIOCSCHAN`` ioctl using struct
-:c:type:`struct video_channel` to enumerate the video inputs of a V4L
+``video_channel`` to enumerate the video inputs of a V4L
 device. The equivalent V4L2 ioctls are
 :ref:`VIDIOC_ENUMINPUT`,
 :ref:`VIDIOC_G_INPUT <VIDIOC_G_INPUT>` and

@@ -283,7 +283,7 @@ video input types were renamed as follows:
 
     -  .. row 1
 
-       -  struct :c:type:`struct video_channel` ``type``
+       -  struct ``video_channel`` ``type``
 
        -  struct :c:type:`v4l2_input` ``type``
 

@@ -328,7 +328,7 @@ Tuning
 ======
 
 The V4L ``VIDIOCGTUNER`` and ``VIDIOCSTUNER`` ioctl and struct
-:c:type:`struct video_tuner` can be used to enumerate the tuners of a
+``video_tuner`` can be used to enumerate the tuners of a
 V4L TV or radio device. The equivalent V4L2 ioctls are
 :ref:`VIDIOC_G_TUNER <VIDIOC_G_TUNER>` and
 :ref:`VIDIOC_S_TUNER <VIDIOC_G_TUNER>` using struct

@@ -374,7 +374,7 @@ Image Properties
 ================
 
 V4L2 has no equivalent of the ``VIDIOCGPICT`` and ``VIDIOCSPICT`` ioctl
-and struct :c:type:`struct video_picture`. The following fields where
+and struct ``video_picture``. The following fields where
 replaced by V4L2 controls accessible with the
 :ref:`VIDIOC_QUERYCTRL`,
 :ref:`VIDIOC_G_CTRL <VIDIOC_G_CTRL>` and

@@ -389,7 +389,7 @@ replaced by V4L2 controls accessible with the
 
     -  .. row 1
 
-       -  struct :c:type:`struct video_picture`
+       -  struct ``video_picture``
 
        -  V4L2 Control ID
 

@@ -445,7 +445,7 @@ into the struct :c:type:`v4l2_pix_format`:
 
     -  .. row 1
 
-       -  struct :c:type:`struct video_picture` ``palette``
+       -  struct ``video_picture`` ``palette``
 
        -  struct :c:type:`v4l2_pix_format` ``pixfmt``
 

@@ -554,7 +554,7 @@ Audio
 =====
 
 The ``VIDIOCGAUDIO`` and ``VIDIOCSAUDIO`` ioctl and struct
-:c:type:`struct video_audio` are used to enumerate the audio inputs
+``video_audio`` are used to enumerate the audio inputs
 of a V4L device. The equivalent V4L2 ioctls are
 :ref:`VIDIOC_G_AUDIO <VIDIOC_G_AUDIO>` and
 :ref:`VIDIOC_S_AUDIO <VIDIOC_G_AUDIO>` using struct

@@ -591,7 +591,7 @@ The following fields where replaced by V4L2 controls accessible with the
 
     -  .. row 1
 
-       -  struct :c:type:`struct video_audio`
+       -  struct ``video_audio``
 
        -  V4L2 Control ID
 

@@ -629,7 +629,7 @@ and ``VIDEO_AUDIO_MUTE`` flags where replaced by the boolean
 ``V4L2_CID_AUDIO_MUTE`` control.
 
 All V4L2 controls have a ``step`` attribute replacing the struct
-:c:type:`struct video_audio` ``step`` field. The V4L audio controls
+``video_audio`` ``step`` field. The V4L audio controls
 are assumed to range from 0 to 65535 with no particular reset value. The
 V4L2 API permits arbitrary limits and defaults which can be queried with
 the :ref:`VIDIOC_QUERYCTRL` ioctl. For general

@@ -642,7 +642,7 @@ Frame Buffer Overlay
 The V4L2 ioctls equivalent to ``VIDIOCGFBUF`` and ``VIDIOCSFBUF`` are
 :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` and
 :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>`. The ``base`` field of struct
-:c:type:`struct video_buffer` remained unchanged, except V4L2 defines
+``video_buffer`` remained unchanged, except V4L2 defines
 a flag to indicate non-destructive overlays instead of a ``NULL``
 pointer. All other fields moved into the struct
 :c:type:`v4l2_pix_format` ``fmt`` substructure of

@@ -659,13 +659,13 @@ of the ``fmt`` union is used, a struct
 :c:type:`v4l2_window`.
 
 The ``x``, ``y``, ``width`` and ``height`` fields of struct
-:c:type:`struct video_window` moved into struct
+``video_window`` moved into struct
 :c:type:`v4l2_rect` substructure ``w`` of struct
-:c:type:`struct v4l2_window`. The ``chromakey``, ``clips``, and
+:c:type:`v4l2_window`. The ``chromakey``, ``clips``, and
 ``clipcount`` fields remained unchanged. Struct
-:c:type:`struct video_clip` was renamed to struct
+``video_clip`` was renamed to struct
 :c:type:`v4l2_clip`, also containing a struct
-:c:type:`struct v4l2_rect`, but the semantics are still the same.
+:c:type:`v4l2_rect`, but the semantics are still the same.
 
 The ``VIDEO_WINDOW_INTERLACE`` flag was dropped. Instead applications
 must set the ``field`` field to ``V4L2_FIELD_ANY`` or

@@ -675,7 +675,7 @@ name ``V4L2_FBUF_FLAG_CHROMAKEY``.
 
 In V4L, storing a bitmap pointer in ``clips`` and setting ``clipcount``
 to ``VIDEO_CLIP_BITMAP`` (-1) requests bitmap clipping, using a fixed
-size bitmap of 1024 × 625 bits. Struct :c:type:`struct v4l2_window`
+size bitmap of 1024 × 625 bits. Struct :c:type:`v4l2_window`
 has a separate ``bitmap`` pointer field for this purpose and the bitmap
 size is determined by ``w.width`` and ``w.height``.
 

@@ -688,7 +688,7 @@ Cropping
 
 To capture only a subsection of the full picture V4L defines the
 ``VIDIOCGCAPTURE`` and ``VIDIOCSCAPTURE`` ioctls using struct
-:c:type:`struct video_capture`. The equivalent V4L2 ioctls are
+``video_capture``. The equivalent V4L2 ioctls are
 :ref:`VIDIOC_G_CROP <VIDIOC_G_CROP>` and
 :ref:`VIDIOC_S_CROP <VIDIOC_G_CROP>` using struct
 :c:type:`v4l2_crop`, and the related

@@ -697,7 +697,7 @@ complex matter, see :ref:`crop` for details.
 
 The ``x``, ``y``, ``width`` and ``height`` fields moved into struct
 :c:type:`v4l2_rect` substructure ``c`` of struct
-:c:type:`struct v4l2_crop`. The ``decimation`` field was dropped. In
+:c:type:`v4l2_crop`. The ``decimation`` field was dropped. In
 the V4L2 API the scaling factor is implied by the size of the cropping
 rectangle and the size of the captured or overlaid image.
 

@@ -889,7 +889,7 @@ with the following parameters:
 
 Undocumented in the V4L specification, in Linux 2.3 the
 ``VIDIOCGVBIFMT`` and ``VIDIOCSVBIFMT`` ioctls using struct
-:c:type:`struct vbi_format` were added to determine the VBI image
+``vbi_format`` were added to determine the VBI image
 parameters. These ioctls are only partially compatible with the V4L2 VBI
 interface specified in :ref:`raw-vbi`.
 

index a84895968349..bd45431ed00e 100644
@@ -1361,7 +1361,7 @@ V4L2 in Linux 3.19
    :ref:`v4l2_quantization <v4l2-quantization>` fields to struct
    :c:type:`v4l2_pix_format`, struct
    :c:type:`v4l2_pix_format_mplane` and
-   struct :ref:`v4l2_mbus_framefmt <v4l2-mbus-framefmt>`.
+   struct :c:type:`v4l2_mbus_framefmt`.
 
 
 V4L2 in Linux 4.4

index 52013b55ea80..f0d7754f1906 100644
@@ -7,7 +7,7 @@ Media Bus Formats
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 
-.. _v4l2-mbus-framefmt:
+.. c:type:: v4l2_mbus_framefmt
 
 .. flat-table:: struct v4l2_mbus_framefmt
     :header-rows:  0

index 785d4cdd2f85..e020c57f98d4 100644
@@ -116,7 +116,7 @@ Rewrote Colorspace chapter, added new enum
 :ref:`v4l2_quantization <v4l2-quantization>` fields to struct
 :c:type:`v4l2_pix_format`, struct
 :c:type:`v4l2_pix_format_mplane` and struct
-:ref:`v4l2_mbus_framefmt <v4l2-mbus-framefmt>`.
+:c:type:`v4l2_mbus_framefmt`.
 
 
 :revision: 3.17 / 2014-08-04 (*lp, hv*)

index cf0e98f5112f..3038f349049c 100644
@@ -356,7 +356,7 @@ call.
 
        -
        -  The type of the control. See enum
-	  :ref:`v4l2_ctrl_type <v4l2-ctrl-type>`.
+	  :c:type:`v4l2_ctrl_type`.
 
     -  .. row 3
 

index d6a07c076837..cbd2a3cbb18e 100644
@@ -44,7 +44,7 @@ an enum v4l2_priority variable and call :ref:`VIDIOC_S_PRIORITY <VIDIOC_G_PRIORI
 with a pointer to this variable.
 
 
-.. _v4l2-priority:
+.. c:type:: v4l2_priority
 
 .. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
 

index ef32e28e57c7..1a798be69e10 100644
@@ -142,7 +142,7 @@ See also the examples in :ref:`control`.
        -  ``minimum``
 
        -  Minimum value, inclusive. This field gives a lower bound for the
-	  control. See enum :ref:`v4l2_ctrl_type <v4l2-ctrl-type>` how
+	  control. See enum :c:type:`v4l2_ctrl_type` how
 	  the minimum value is to be used for each possible control type.
 	  Note that this a signed 32-bit value.
 

@@ -153,7 +153,7 @@ See also the examples in :ref:`control`.
        -  ``maximum``
 
        -  Maximum value, inclusive. This field gives an upper bound for the
-	  control. See enum :ref:`v4l2_ctrl_type <v4l2-ctrl-type>` how
+	  control. See enum :c:type:`v4l2_ctrl_type` how
 	  the maximum value is to be used for each possible control type.
 	  Note that this a signed 32-bit value.
 

@@ -164,7 +164,7 @@ See also the examples in :ref:`control`.
        -  ``step``
 
        -  This field gives a step size for the control. See enum
-	  :ref:`v4l2_ctrl_type <v4l2-ctrl-type>` how the step value is
+	  :c:type:`v4l2_ctrl_type` how the step value is
 	  to be used for each possible control type. Note that this an
 	  unsigned 32-bit value.
 

@@ -269,7 +269,7 @@ See also the examples in :ref:`control`.
        -  ``minimum``
 
        -  Minimum value, inclusive. This field gives a lower bound for the
-	  control. See enum :ref:`v4l2_ctrl_type <v4l2-ctrl-type>` how
+	  control. See enum :c:type:`v4l2_ctrl_type` how
 	  the minimum value is to be used for each possible control type.
 	  Note that this a signed 64-bit value.
 

@@ -280,7 +280,7 @@ See also the examples in :ref:`control`.
        -  ``maximum``
 
        -  Maximum value, inclusive. This field gives an upper bound for the
-	  control. See enum :ref:`v4l2_ctrl_type <v4l2-ctrl-type>` how
+	  control. See enum :c:type:`v4l2_ctrl_type` how
 	  the maximum value is to be used for each possible control type.
 	  Note that this a signed 64-bit value.
 

@@ -291,7 +291,7 @@ See also the examples in :ref:`control`.
        -  ``step``
 
        -  This field gives a step size for the control. See enum
-	  :ref:`v4l2_ctrl_type <v4l2-ctrl-type>` how the step value is
+	  :c:type:`v4l2_ctrl_type` how the step value is
 	  to be used for each possible control type. Note that this an
 	  unsigned 64-bit value.
 

@@ -456,7 +456,7 @@ See also the examples in :ref:`control`.
 
 .. tabularcolumns:: |p{5.8cm}|p{1.4cm}|p{1.0cm}|p{1.4cm}|p{6.9cm}|
 
-.. _v4l2-ctrl-type:
+.. c:type:: v4l2_ctrl_type
 
 .. cssclass:: longtable
 

index 2df1342ac6ea..90d876faa5b9 100644
@@ -38,7 +38,7 @@ These ioctls are used to negotiate the frame format at specific subdev
 pads in the image pipeline.
 
 To retrieve the current format applications set the ``pad`` field of a
-struct :ref:`v4l2_subdev_format <v4l2-subdev-format>` to the desired
+struct :c:type:`v4l2_subdev_format` to the desired
 pad number as reported by the media API and the ``which`` field to
 ``V4L2_SUBDEV_FORMAT_ACTIVE``. When they call the
 ``VIDIOC_SUBDEV_G_FMT`` ioctl with a pointer to this structure the

@@ -49,7 +49,7 @@ To change the current format applications set both the ``pad`` and
 the ``VIDIOC_SUBDEV_S_FMT`` ioctl with a pointer to this structure the
 driver verifies the requested format, adjusts it based on the hardware
 capabilities and configures the device. Upon return the struct
-:ref:`v4l2_subdev_format <v4l2-subdev-format>` contains the current
+:c:type:`v4l2_subdev_format` contains the current
 format as would be returned by a ``VIDIOC_SUBDEV_G_FMT`` call.
 
 Applications can query the device capabilities by setting the ``which``

@@ -78,7 +78,7 @@ should be as close as possible to the original request.
 
 .. tabularcolumns:: |p{4.4cm}|p{4.4cm}|p{8.7cm}|
 
-.. _v4l2-subdev-format:
+.. c:type:: v4l2_subdev_format
 
 .. flat-table:: struct v4l2_subdev_format
     :header-rows:  0

@@ -105,7 +105,7 @@ should be as close as possible to the original request.
 
     -  .. row 3
 
-       -  struct :ref:`v4l2_mbus_framefmt <v4l2-mbus-framefmt>`
+       -  struct :c:type:`v4l2_mbus_framefmt`
 
        -  ``format``
 

@@ -164,7 +164,7 @@ EBUSY
     fix the problem first. Only returned by ``VIDIOC_SUBDEV_S_FMT``
 
 EINVAL
-    The struct :ref:`v4l2_subdev_format <v4l2-subdev-format>`
+    The struct :c:type:`v4l2_subdev_format`
     ``pad`` references a non-existing pad, or the ``which`` field
     references a non-existing format.