diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2014-04-04 12:50:07 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2014-04-04 12:50:07 -0400 |
commit | 3c83e61e67256e0bb08c46cc2db43b58fd617251 (patch) | |
tree | 0233e1e04e6449c60b01ff5dea8bea85bcf22f08 /Documentation/DocBook | |
parent | 4a4389abdd9822fdf3cc2ac6ed87eb811fd43acc (diff) | |
parent | a83b93a7480441a47856dc9104bea970e84cda87 (diff) |
Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media updates from Mauro Carvalho Chehab:
"The main set of series of patches for media subsystem, including:
- document RC sysfs class
- added an API to setup scancode to allow waking up systems using the
Remote Controller
- add API for SDR devices. Drivers are still on staging
- some API improvements for getting EDID data from media
inputs/outputs
- new DVB frontend driver for drx-j (ATSC)
- one driver (it913x/it9137) got removed, in favor of an improvement
on another driver (af9035)
- added a skeleton V4L2 PCI driver at documentation
- added a dual flash driver (lm3646)
- added a new IR driver (img-ir)
- added an IR scancode decoder for the Sharp protocol
- some improvements at the usbtv driver, to allow its core to be
reused.
- added a new SDR driver (rtl2832u_sdr)
- added a new tuner driver (msi001)
- several improvements at em28xx driver to fix PM support, device
removal and to split the V4L2 specific bits into a separate
sub-driver
- one driver got converted to videobuf2 (s2255drv)
- the e4000 tuner driver now follows an improved binding model
- some fixes at V4L2 compat32 code
- several fixes and enhancements at videobuf2 code
- some cleanups at V4L2 API documentation
- usual driver enhancements, new board additions and misc fixups"
[ NOTE! This merge effective drops commit 4329b93b283c ("of: Reduce
indentation in of_graph_get_next_endpoint").
The of_graph_get_next_endpoint() function was moved and renamed by
commit fd9fdb78a9bf ("[media] of: move graph helpers from
drivers/media/v4l2-core to drivers/of"). It was originally called
v4l2_of_get_next_endpoint() and lived in the file
drivers/media/v4l2-core/v4l2-of.c.
In that original location, it was then fixed to support empty port
nodes by commit b9db140c1e46 ("[media] v4l: of: Support empty port
nodes"), and that commit clashes badly with the dropped "Reduce
intendation" commit. I had to choose one or the other, and decided
that the "Support empty port nodes" commit was more important ]
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (426 commits)
[media] em28xx-dvb: fix PCTV 461e tuner I2C binding
Revert "[media] em28xx-dvb: fix PCTV 461e tuner I2C binding"
[media] em28xx: fix PCTV 290e LNA oops
[media] em28xx-dvb: fix PCTV 461e tuner I2C binding
[media] m88ds3103: fix bug on .set_tone()
[media] saa7134: fix WARN_ON during resume
[media] v4l2-dv-timings: add module name, description, license
[media] videodev2.h: add parenthesis around macro arguments
[media] saa6752hs: depends on CRC32
[media] si4713: fix Kconfig dependencies
[media] Sensoray 2255 uses videobuf2
[media] adv7180: free an interrupt on failure paths in init_device()
[media] e4000: make VIDEO_V4L2 dependency optional
[media] af9033: Don't export functions for the hardware filter
[media] af9035: use af9033 PID filters
[media] af9033: implement PID filter
[media] rtl2832_sdr: do not use dynamic stack allocation
[media] e4000: fix 32-bit build error
[media] em28xx-audio: make sure audio is unmuted on open()
[media] DocBook media: v4l2_format_sdr was renamed to v4l2_sdr_format
...
Diffstat (limited to 'Documentation/DocBook')
27 files changed, 1055 insertions, 931 deletions
diff --git a/Documentation/DocBook/media/dvb/demux.xml b/Documentation/DocBook/media/dvb/demux.xml index 86de89cfbd67..c8683d66f059 100644 --- a/Documentation/DocBook/media/dvb/demux.xml +++ b/Documentation/DocBook/media/dvb/demux.xml | |||
@@ -1042,7 +1042,14 @@ role="subsection"><title>DMX_ADD_PID</title> | |||
1042 | </para> | 1042 | </para> |
1043 | <informaltable><tgroup cols="1"><tbody><row><entry | 1043 | <informaltable><tgroup cols="1"><tbody><row><entry |
1044 | align="char"> | 1044 | align="char"> |
1045 | <para>This ioctl is undocumented. Documentation is welcome.</para> | 1045 | <para>This ioctl call allows to add multiple PIDs to a transport stream filter |
1046 | previously set up with DMX_SET_PES_FILTER and output equal to DMX_OUT_TSDEMUX_TAP. | ||
1047 | </para></entry></row><row><entry align="char"><para> | ||
1048 | It is used by readers of /dev/dvb/adapterX/demuxY. | ||
1049 | </para></entry></row><row><entry align="char"><para> | ||
1050 | It may be called at any time, i.e. before or after the first filter on the | ||
1051 | shared file descriptor was started. It makes it possible to record multiple | ||
1052 | services without the need to de-multiplex or re-multiplex TS packets.</para> | ||
1046 | </entry> | 1053 | </entry> |
1047 | </row></tbody></tgroup></informaltable> | 1054 | </row></tbody></tgroup></informaltable> |
1048 | <para>SYNOPSIS | 1055 | <para>SYNOPSIS |
@@ -1075,7 +1082,7 @@ role="subsection"><title>DMX_ADD_PID</title> | |||
1075 | </para> | 1082 | </para> |
1076 | </entry><entry | 1083 | </entry><entry |
1077 | align="char"> | 1084 | align="char"> |
1078 | <para>Undocumented.</para> | 1085 | <para>PID number to be filtered.</para> |
1079 | </entry> | 1086 | </entry> |
1080 | </row></tbody></tgroup></informaltable> | 1087 | </row></tbody></tgroup></informaltable> |
1081 | &return-value-dvb; | 1088 | &return-value-dvb; |
@@ -1087,7 +1094,15 @@ role="subsection"><title>DMX_REMOVE_PID</title> | |||
1087 | </para> | 1094 | </para> |
1088 | <informaltable><tgroup cols="1"><tbody><row><entry | 1095 | <informaltable><tgroup cols="1"><tbody><row><entry |
1089 | align="char"> | 1096 | align="char"> |
1090 | <para>This ioctl is undocumented. Documentation is welcome.</para> | 1097 | <para>This ioctl call allows to remove a PID when multiple PIDs are set on a |
1098 | transport stream filter, e. g. a filter previously set up with output equal to | ||
1099 | DMX_OUT_TSDEMUX_TAP, created via either DMX_SET_PES_FILTER or DMX_ADD_PID. | ||
1100 | </para></entry></row><row><entry align="char"><para> | ||
1101 | It is used by readers of /dev/dvb/adapterX/demuxY. | ||
1102 | </para></entry></row><row><entry align="char"><para> | ||
1103 | It may be called at any time, i.e. before or after the first filter on the | ||
1104 | shared file descriptor was started. It makes it possible to record multiple | ||
1105 | services without the need to de-multiplex or re-multiplex TS packets.</para> | ||
1091 | </entry> | 1106 | </entry> |
1092 | </row></tbody></tgroup></informaltable> | 1107 | </row></tbody></tgroup></informaltable> |
1093 | <para>SYNOPSIS | 1108 | <para>SYNOPSIS |
@@ -1120,7 +1135,7 @@ role="subsection"><title>DMX_REMOVE_PID</title> | |||
1120 | </para> | 1135 | </para> |
1121 | </entry><entry | 1136 | </entry><entry |
1122 | align="char"> | 1137 | align="char"> |
1123 | <para>Undocumented.</para> | 1138 | <para>PID of the PES filter to be removed.</para> |
1124 | </entry> | 1139 | </entry> |
1125 | </row></tbody></tgroup></informaltable> | 1140 | </row></tbody></tgroup></informaltable> |
1126 | &return-value-dvb; | 1141 | &return-value-dvb; |
diff --git a/Documentation/DocBook/media/dvb/dvbapi.xml b/Documentation/DocBook/media/dvb/dvbapi.xml index 0197bcc7842d..4c15396c67e5 100644 --- a/Documentation/DocBook/media/dvb/dvbapi.xml +++ b/Documentation/DocBook/media/dvb/dvbapi.xml | |||
@@ -18,7 +18,7 @@ | |||
18 | <firstname>Mauro</firstname> | 18 | <firstname>Mauro</firstname> |
19 | <othername role="mi">Carvalho</othername> | 19 | <othername role="mi">Carvalho</othername> |
20 | <surname>Chehab</surname> | 20 | <surname>Chehab</surname> |
21 | <affiliation><address><email>mchehab@redhat.com</email></address></affiliation> | 21 | <affiliation><address><email>m.chehab@samsung.com</email></address></affiliation> |
22 | <contrib>Ported document to Docbook XML.</contrib> | 22 | <contrib>Ported document to Docbook XML.</contrib> |
23 | </author> | 23 | </author> |
24 | </authorgroup> | 24 | </authorgroup> |
@@ -28,7 +28,7 @@ | |||
28 | <holder>Convergence GmbH</holder> | 28 | <holder>Convergence GmbH</holder> |
29 | </copyright> | 29 | </copyright> |
30 | <copyright> | 30 | <copyright> |
31 | <year>2009-2012</year> | 31 | <year>2009-2014</year> |
32 | <holder>Mauro Carvalho Chehab</holder> | 32 | <holder>Mauro Carvalho Chehab</holder> |
33 | </copyright> | 33 | </copyright> |
34 | 34 | ||
diff --git a/Documentation/DocBook/media/dvb/frontend.xml b/Documentation/DocBook/media/dvb/frontend.xml index 0d6e81bd9ed2..8a6a6ff27af5 100644 --- a/Documentation/DocBook/media/dvb/frontend.xml +++ b/Documentation/DocBook/media/dvb/frontend.xml | |||
@@ -744,7 +744,7 @@ typedef enum fe_hierarchy { | |||
744 | </para> | 744 | </para> |
745 | <informaltable><tgroup cols="1"><tbody><row><entry | 745 | <informaltable><tgroup cols="1"><tbody><row><entry |
746 | align="char"> | 746 | align="char"> |
747 | <para>int ioctl(int fd, int request = <link linkend="FE_READ_SNR">FE_READ_SNR</link>, int16_t | 747 | <para>int ioctl(int fd, int request = <link linkend="FE_READ_SNR">FE_READ_SNR</link>, uint16_t |
748 | ⋆snr);</para> | 748 | ⋆snr);</para> |
749 | </entry> | 749 | </entry> |
750 | </row></tbody></tgroup></informaltable> | 750 | </row></tbody></tgroup></informaltable> |
@@ -766,7 +766,7 @@ typedef enum fe_hierarchy { | |||
766 | </entry> | 766 | </entry> |
767 | </row><row><entry | 767 | </row><row><entry |
768 | align="char"> | 768 | align="char"> |
769 | <para>int16_t *snr</para> | 769 | <para>uint16_t *snr</para> |
770 | </entry><entry | 770 | </entry><entry |
771 | align="char"> | 771 | align="char"> |
772 | <para>The signal-to-noise ratio is stored into *snr.</para> | 772 | <para>The signal-to-noise ratio is stored into *snr.</para> |
@@ -791,7 +791,7 @@ typedef enum fe_hierarchy { | |||
791 | <informaltable><tgroup cols="1"><tbody><row><entry | 791 | <informaltable><tgroup cols="1"><tbody><row><entry |
792 | align="char"> | 792 | align="char"> |
793 | <para>int ioctl( int fd, int request = | 793 | <para>int ioctl( int fd, int request = |
794 | <link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link>, int16_t ⋆strength);</para> | 794 | <link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link>, uint16_t ⋆strength);</para> |
795 | </entry> | 795 | </entry> |
796 | </row></tbody></tgroup></informaltable> | 796 | </row></tbody></tgroup></informaltable> |
797 | 797 | ||
@@ -814,7 +814,7 @@ typedef enum fe_hierarchy { | |||
814 | </entry> | 814 | </entry> |
815 | </row><row><entry | 815 | </row><row><entry |
816 | align="char"> | 816 | align="char"> |
817 | <para>int16_t *strength</para> | 817 | <para>uint16_t *strength</para> |
818 | </entry><entry | 818 | </entry><entry |
819 | align="char"> | 819 | align="char"> |
820 | <para>The signal strength value is stored into *strength.</para> | 820 | <para>The signal strength value is stored into *strength.</para> |
diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml index 1ddf354aa997..71f6bf9e735e 100644 --- a/Documentation/DocBook/media/v4l/common.xml +++ b/Documentation/DocBook/media/v4l/common.xml | |||
@@ -38,70 +38,41 @@ the basic concepts applicable to all devices.</para> | |||
38 | 38 | ||
39 | <para>V4L2 drivers are implemented as kernel modules, loaded | 39 | <para>V4L2 drivers are implemented as kernel modules, loaded |
40 | manually by the system administrator or automatically when a device is | 40 | manually by the system administrator or automatically when a device is |
41 | first opened. The driver modules plug into the "videodev" kernel | 41 | first discovered. The driver modules plug into the "videodev" kernel |
42 | module. It provides helper functions and a common application | 42 | module. It provides helper functions and a common application |
43 | interface specified in this document.</para> | 43 | interface specified in this document.</para> |
44 | 44 | ||
45 | <para>Each driver thus loaded registers one or more device nodes | 45 | <para>Each driver thus loaded registers one or more device nodes |
46 | with major number 81 and a minor number between 0 and 255. Assigning | 46 | with major number 81 and a minor number between 0 and 255. Minor numbers |
47 | minor numbers to V4L2 devices is entirely up to the system administrator, | 47 | are allocated dynamically unless the kernel is compiled with the kernel |
48 | this is primarily intended to solve conflicts between devices.<footnote> | 48 | option CONFIG_VIDEO_FIXED_MINOR_RANGES. In that case minor numbers are |
49 | <para>Access permissions are associated with character | 49 | allocated in ranges depending on the device node type (video, radio, etc.).</para> |
50 | device special files, hence we must ensure device numbers cannot | 50 | |
51 | change with the module load order. To this end minor numbers are no | 51 | <para>Many drivers support "video_nr", "radio_nr" or "vbi_nr" |
52 | longer automatically assigned by the "videodev" module as in V4L but | 52 | module options to select specific video/radio/vbi node numbers. This allows |
53 | requested by the driver. The defaults will suffice for most people | 53 | the user to request that the device node is named e.g. /dev/video5 instead |
54 | unless two drivers compete for the same minor numbers.</para> | 54 | of leaving it to chance. When the driver supports multiple devices of the same |
55 | </footnote> The module options to select minor numbers are named | 55 | type more than one device node number can be assigned, separated by commas: |
56 | after the device special file with a "_nr" suffix. For example "video_nr" | 56 | <informalexample> |
57 | for <filename>/dev/video</filename> video capture devices. The number is | ||
58 | an offset to the base minor number associated with the device type. | ||
59 | <footnote> | ||
60 | <para>In earlier versions of the V4L2 API the module options | ||
61 | where named after the device special file with a "unit_" prefix, expressing | ||
62 | the minor number itself, not an offset. Rationale for this change is unknown. | ||
63 | Lastly the naming and semantics are just a convention among driver writers, | ||
64 | the point to note is that minor numbers are not supposed to be hardcoded | ||
65 | into drivers.</para> | ||
66 | </footnote> When the driver supports multiple devices of the same | ||
67 | type more than one minor number can be assigned, separated by commas: | ||
68 | <informalexample> | ||
69 | <screen> | 57 | <screen> |
70 | > insmod mydriver.o video_nr=0,1 radio_nr=0,1</screen> | 58 | > modprobe mydriver video_nr=0,1 radio_nr=0,1</screen> |
71 | </informalexample></para> | 59 | </informalexample></para> |
72 | 60 | ||
73 | <para>In <filename>/etc/modules.conf</filename> this may be | 61 | <para>In <filename>/etc/modules.conf</filename> this may be |
74 | written as: <informalexample> | 62 | written as: <informalexample> |
75 | <screen> | 63 | <screen> |
76 | alias char-major-81-0 mydriver | 64 | options mydriver video_nr=0,1 radio_nr=0,1 |
77 | alias char-major-81-1 mydriver | ||
78 | alias char-major-81-64 mydriver <co id="alias" /> | ||
79 | options mydriver video_nr=0,1 radio_nr=0,1 <co id="options" /> | ||
80 | </screen> | 65 | </screen> |
81 | <calloutlist> | 66 | </informalexample> When no device node number is given as module |
82 | <callout arearefs="alias"> | 67 | option the driver supplies a default.</para> |
83 | <para>When an application attempts to open a device | 68 | |
84 | special file with major number 81 and minor number 0, 1, or 64, load | 69 | <para>Normally udev will create the device nodes in /dev automatically |
85 | "mydriver" (and the "videodev" module it depends upon).</para> | 70 | for you. If udev is not installed, then you need to enable the |
86 | </callout> | 71 | CONFIG_VIDEO_FIXED_MINOR_RANGES kernel option in order to be able to correctly |
87 | <callout arearefs="options"> | 72 | relate a minor number to a device node number. I.e., you need to be certain |
88 | <para>Register the first two video capture devices with | 73 | that minor number 5 maps to device node name video5. With this kernel option |
89 | minor number 0 and 1 (base number is 0), the first two radio device | 74 | different device types have different minor number ranges. These ranges are |
90 | with minor number 64 and 65 (base 64).</para> | 75 | listed in <xref linkend="devices" />. |
91 | </callout> | ||
92 | </calloutlist> | ||
93 | </informalexample> When no minor number is given as module | ||
94 | option the driver supplies a default. <xref linkend="devices" /> | ||
95 | recommends the base minor numbers to be used for the various device | ||
96 | types. Obviously minor numbers must be unique. When the number is | ||
97 | already in use the <emphasis>offending device</emphasis> will not be | ||
98 | registered. <!-- Blessed by Linus Torvalds on | ||
99 | linux-kernel@vger.kernel.org, 2002-11-20. --></para> | ||
100 | |||
101 | <para>By convention system administrators create various | ||
102 | character device special files with these major and minor numbers in | ||
103 | the <filename>/dev</filename> directory. The names recommended for the | ||
104 | different V4L2 device types are listed in <xref linkend="devices" />. | ||
105 | </para> | 76 | </para> |
106 | 77 | ||
107 | <para>The creation of character special files (with | 78 | <para>The creation of character special files (with |
@@ -110,85 +81,66 @@ devices cannot be opened by major and minor number. That means | |||
110 | applications cannot <emphasis>reliable</emphasis> scan for loaded or | 81 | applications cannot <emphasis>reliable</emphasis> scan for loaded or |
111 | installed drivers. The user must enter a device name, or the | 82 | installed drivers. The user must enter a device name, or the |
112 | application can try the conventional device names.</para> | 83 | application can try the conventional device names.</para> |
113 | |||
114 | <para>Under the device filesystem (devfs) the minor number | ||
115 | options are ignored. V4L2 drivers (or by proxy the "videodev" module) | ||
116 | automatically create the required device files in the | ||
117 | <filename>/dev/v4l</filename> directory using the conventional device | ||
118 | names above.</para> | ||
119 | </section> | 84 | </section> |
120 | 85 | ||
121 | <section id="related"> | 86 | <section id="related"> |
122 | <title>Related Devices</title> | 87 | <title>Related Devices</title> |
123 | 88 | ||
124 | <para>Devices can support several related functions. For example | 89 | <para>Devices can support several functions. For example |
125 | video capturing, video overlay and VBI capturing are related because | 90 | video capturing, VBI capturing and radio support.</para> |
126 | these functions share, amongst other, the same video input and tuner | 91 | |
127 | frequency. V4L and earlier versions of V4L2 used the same device name | 92 | <para>The V4L2 API creates different nodes for each of these functions.</para> |
128 | and minor number for video capturing and overlay, but different ones | 93 | |
129 | for VBI. Experience showed this approach has several problems<footnote> | 94 | <para>The V4L2 API was designed with the idea that one device node could support |
130 | <para>Given a device file name one cannot reliable find | 95 | all functions. However, in practice this never worked: this 'feature' |
131 | related devices. For once names are arbitrary and in a system with | 96 | was never used by applications and many drivers did not support it and if |
132 | multiple devices, where only some support VBI capturing, a | 97 | they did it was certainly never tested. In addition, switching a device |
133 | <filename>/dev/video2</filename> is not necessarily related to | 98 | node between different functions only works when using the streaming I/O |
134 | <filename>/dev/vbi2</filename>. The V4L | 99 | API, not with the read()/write() API.</para> |
135 | <constant>VIDIOCGUNIT</constant> ioctl would require a search for a | 100 | |
136 | device file with a particular major and minor number.</para> | 101 | <para>Today each device node supports just one function.</para> |
137 | </footnote>, and to make things worse the V4L videodev module | ||
138 | used to prohibit multiple opens of a device.</para> | ||
139 | |||
140 | <para>As a remedy the present version of the V4L2 API relaxed the | ||
141 | concept of device types with specific names and minor numbers. For | ||
142 | compatibility with old applications drivers must still register different | ||
143 | minor numbers to assign a default function to the device. But if related | ||
144 | functions are supported by the driver they must be available under all | ||
145 | registered minor numbers. The desired function can be selected after | ||
146 | opening the device as described in <xref linkend="devices" />.</para> | ||
147 | |||
148 | <para>Imagine a driver supporting video capturing, video | ||
149 | overlay, raw VBI capturing, and FM radio reception. It registers three | ||
150 | devices with minor number 0, 64 and 224 (this numbering scheme is | ||
151 | inherited from the V4L API). Regardless if | ||
152 | <filename>/dev/video</filename> (81, 0) or | ||
153 | <filename>/dev/vbi</filename> (81, 224) is opened the application can | ||
154 | select any one of the video capturing, overlay or VBI capturing | ||
155 | functions. Without programming (e. g. reading from the device | ||
156 | with <application>dd</application> or <application>cat</application>) | ||
157 | <filename>/dev/video</filename> captures video images, while | ||
158 | <filename>/dev/vbi</filename> captures raw VBI data. | ||
159 | <filename>/dev/radio</filename> (81, 64) is invariable a radio device, | ||
160 | unrelated to the video functions. Being unrelated does not imply the | ||
161 | devices can be used at the same time, however. The &func-open; | ||
162 | function may very well return an &EBUSY;.</para> | ||
163 | 102 | ||
164 | <para>Besides video input or output the hardware may also | 103 | <para>Besides video input or output the hardware may also |
165 | support audio sampling or playback. If so, these functions are | 104 | support audio sampling or playback. If so, these functions are |
166 | implemented as OSS or ALSA PCM devices and eventually OSS or ALSA | 105 | implemented as ALSA PCM devices with optional ALSA audio mixer |
167 | audio mixer. The V4L2 API makes no provisions yet to find these | 106 | devices.</para> |
168 | related devices. If you have an idea please write to the linux-media | 107 | |
169 | mailing list: &v4l-ml;.</para> | 108 | <para>One problem with all these devices is that the V4L2 API |
109 | makes no provisions to find these related devices. Some really | ||
110 | complex devices use the Media Controller (see <xref linkend="media_controller" />) | ||
111 | which can be used for this purpose. But most drivers do not use it, | ||
112 | and while some code exists that uses sysfs to discover related devices | ||
113 | (see libmedia_dev in the <ulink url="http://git.linuxtv.org/v4l-utils/">v4l-utils</ulink> | ||
114 | git repository), there is no library yet that can provide a single API towards | ||
115 | both Media Controller-based devices and devices that do not use the Media Controller. | ||
116 | If you want to work on this please write to the linux-media mailing list: &v4l-ml;.</para> | ||
170 | </section> | 117 | </section> |
171 | 118 | ||
172 | <section> | 119 | <section> |
173 | <title>Multiple Opens</title> | 120 | <title>Multiple Opens</title> |
174 | 121 | ||
175 | <para>In general, V4L2 devices can be opened more than once. | 122 | <para>V4L2 devices can be opened more than once.<footnote><para> |
123 | There are still some old and obscure drivers that have not been updated to | ||
124 | allow for multiple opens. This implies that for such drivers &func-open; can | ||
125 | return an &EBUSY; when the device is already in use.</para></footnote> | ||
176 | When this is supported by the driver, users can for example start a | 126 | When this is supported by the driver, users can for example start a |
177 | "panel" application to change controls like brightness or audio | 127 | "panel" application to change controls like brightness or audio |
178 | volume, while another application captures video and audio. In other words, panel | 128 | volume, while another application captures video and audio. In other words, panel |
179 | applications are comparable to an OSS or ALSA audio mixer application. | 129 | applications are comparable to an ALSA audio mixer application. |
180 | When a device supports multiple functions like capturing and overlay | 130 | Just opening a V4L2 device should not change the state of the device.<footnote> |
181 | <emphasis>simultaneously</emphasis>, multiple opens allow concurrent | 131 | <para>Unfortunately, opening a radio device often switches the state of the |
182 | use of the device by forked processes or specialized applications.</para> | 132 | device to radio mode in many drivers. This behavior should be fixed eventually |
183 | 133 | as it violates the V4L2 specification.</para></footnote></para> | |
184 | <para>Multiple opens are optional, although drivers should | 134 | |
185 | permit at least concurrent accesses without data exchange, &ie; panel | 135 | <para>Once an application has allocated the memory buffers needed for |
186 | applications. This implies &func-open; can return an &EBUSY; when the | 136 | streaming data (by calling the &VIDIOC-REQBUFS; or &VIDIOC-CREATE-BUFS; ioctls, |
187 | device is already in use, as well as &func-ioctl; functions initiating | 137 | or implicitly by calling the &func-read; or &func-write; functions) that |
188 | data exchange (namely the &VIDIOC-S-FMT; ioctl), and the &func-read; | 138 | application (filehandle) becomes the owner of the device. It is no longer |
189 | and &func-write; functions.</para> | 139 | allowed to make changes that would affect the buffer sizes (e.g. by calling |
190 | 140 | the &VIDIOC-S-FMT; ioctl) and other applications are no longer allowed to allocate | |
191 | <para>Mere opening a V4L2 device does not grant exclusive | 141 | buffers or start or stop streaming. The &EBUSY; will be returned instead.</para> |
142 | |||
143 | <para>Merely opening a V4L2 device does not grant exclusive | ||
192 | access.<footnote> | 144 | access.<footnote> |
193 | <para>Drivers could recognize the | 145 | <para>Drivers could recognize the |
194 | <constant>O_EXCL</constant> open flag. Presently this is not required, | 146 | <constant>O_EXCL</constant> open flag. Presently this is not required, |
@@ -206,12 +158,7 @@ additional access privileges using the priority mechanism described in | |||
206 | <para>V4L2 drivers should not support multiple applications | 158 | <para>V4L2 drivers should not support multiple applications |
207 | reading or writing the same data stream on a device by copying | 159 | reading or writing the same data stream on a device by copying |
208 | buffers, time multiplexing or similar means. This is better handled by | 160 | buffers, time multiplexing or similar means. This is better handled by |
209 | a proxy application in user space. When the driver supports stream | 161 | a proxy application in user space.</para> |
210 | sharing anyway it must be implemented transparently. The V4L2 API does | ||
211 | not specify how conflicts are solved. <!-- For example O_EXCL when the | ||
212 | application does not want to be preempted, PROT_READ mmapped buffers | ||
213 | which can be mapped twice, what happens when image formats do not | ||
214 | match etc.--></para> | ||
215 | </section> | 162 | </section> |
216 | 163 | ||
217 | <section> | 164 | <section> |
@@ -240,15 +187,15 @@ methods</link> supported by the device.</para> | |||
240 | 187 | ||
241 | <para>Starting with kernel version 3.1, VIDIOC-QUERYCAP will return the | 188 | <para>Starting with kernel version 3.1, VIDIOC-QUERYCAP will return the |
242 | V4L2 API version used by the driver, with generally matches the Kernel version. | 189 | V4L2 API version used by the driver, with generally matches the Kernel version. |
243 | There's no need of using &VIDIOC-QUERYCAP; to check if an specific ioctl is | 190 | There's no need of using &VIDIOC-QUERYCAP; to check if a specific ioctl is |
244 | supported, the V4L2 core now returns ENOIOCTLCMD if a driver doesn't provide | 191 | supported, the V4L2 core now returns ENOTTY if a driver doesn't provide |
245 | support for an ioctl.</para> | 192 | support for an ioctl.</para> |
246 | 193 | ||
247 | <para>Other features can be queried | 194 | <para>Other features can be queried |
248 | by calling the respective ioctl, for example &VIDIOC-ENUMINPUT; | 195 | by calling the respective ioctl, for example &VIDIOC-ENUMINPUT; |
249 | to learn about the number, types and names of video connectors on the | 196 | to learn about the number, types and names of video connectors on the |
250 | device. Although abstraction is a major objective of this API, the | 197 | device. Although abstraction is a major objective of this API, the |
251 | ioctl also allows driver specific applications to reliable identify | 198 | &VIDIOC-QUERYCAP; ioctl also allows driver specific applications to reliably identify |
252 | the driver.</para> | 199 | the driver.</para> |
253 | 200 | ||
254 | <para>All V4L2 drivers must support | 201 | <para>All V4L2 drivers must support |
@@ -278,9 +225,7 @@ Applications requiring a different priority will usually call | |||
278 | the &VIDIOC-QUERYCAP; ioctl.</para> | 225 | the &VIDIOC-QUERYCAP; ioctl.</para> |
279 | 226 | ||
280 | <para>Ioctls changing driver properties, such as &VIDIOC-S-INPUT;, | 227 | <para>Ioctls changing driver properties, such as &VIDIOC-S-INPUT;, |
281 | return an &EBUSY; after another application obtained higher priority. | 228 | return an &EBUSY; after another application obtained higher priority.</para> |
282 | An event mechanism to notify applications about asynchronous property | ||
283 | changes has been proposed but not added yet.</para> | ||
284 | </section> | 229 | </section> |
285 | 230 | ||
286 | <section id="video"> | 231 | <section id="video"> |
@@ -288,9 +233,9 @@ changes has been proposed but not added yet.</para> | |||
288 | 233 | ||
289 | <para>Video inputs and outputs are physical connectors of a | 234 | <para>Video inputs and outputs are physical connectors of a |
290 | device. These can be for example RF connectors (antenna/cable), CVBS | 235 | device. These can be for example RF connectors (antenna/cable), CVBS |
291 | a.k.a. Composite Video, S-Video or RGB connectors. Only video and VBI | 236 | a.k.a. Composite Video, S-Video or RGB connectors. Video and VBI |
292 | capture devices have inputs, output devices have outputs, at least one | 237 | capture devices have inputs. Video and VBI output devices have outputs, |
293 | each. Radio devices have no video inputs or outputs.</para> | 238 | at least one each. Radio devices have no video inputs or outputs.</para> |
294 | 239 | ||
295 | <para>To learn about the number and attributes of the | 240 | <para>To learn about the number and attributes of the |
296 | available inputs and outputs applications can enumerate them with the | 241 | available inputs and outputs applications can enumerate them with the |
@@ -299,30 +244,13 @@ available inputs and outputs applications can enumerate them with the | |||
299 | ioctl also contains signal status information applicable when the | 244 | ioctl also contains signal status information applicable when the |
300 | current video input is queried.</para> | 245 | current video input is queried.</para> |
301 | 246 | ||
302 | <para>The &VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; ioctl return the | 247 | <para>The &VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; ioctls return the |
303 | index of the current video input or output. To select a different | 248 | index of the current video input or output. To select a different |
304 | input or output applications call the &VIDIOC-S-INPUT; and | 249 | input or output applications call the &VIDIOC-S-INPUT; and |
305 | &VIDIOC-S-OUTPUT; ioctl. Drivers must implement all the input ioctls | 250 | &VIDIOC-S-OUTPUT; ioctls. Drivers must implement all the input ioctls |
306 | when the device has one or more inputs, all the output ioctls when the | 251 | when the device has one or more inputs, all the output ioctls when the |
307 | device has one or more outputs.</para> | 252 | device has one or more outputs.</para> |
308 | 253 | ||
309 | <!-- | ||
310 | <figure id=io-tree> | ||
311 | <title>Input and output enumeration is the root of most device properties.</title> | ||
312 | <mediaobject> | ||
313 | <imageobject> | ||
314 | <imagedata fileref="links.pdf" format="ps" /> | ||
315 | </imageobject> | ||
316 | <imageobject> | ||
317 | <imagedata fileref="links.gif" format="gif" /> | ||
318 | </imageobject> | ||
319 | <textobject> | ||
320 | <phrase>Links between various device property structures.</phrase> | ||
321 | </textobject> | ||
322 | </mediaobject> | ||
323 | </figure> | ||
324 | --> | ||
325 | |||
326 | <example> | 254 | <example> |
327 | <title>Information about the current video input</title> | 255 | <title>Information about the current video input</title> |
328 | 256 | ||
@@ -330,20 +258,20 @@ device has one or more outputs.</para> | |||
330 | &v4l2-input; input; | 258 | &v4l2-input; input; |
331 | int index; | 259 | int index; |
332 | 260 | ||
333 | if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &index)) { | 261 | if (-1 == ioctl(fd, &VIDIOC-G-INPUT;, &index)) { |
334 | perror ("VIDIOC_G_INPUT"); | 262 | perror("VIDIOC_G_INPUT"); |
335 | exit (EXIT_FAILURE); | 263 | exit(EXIT_FAILURE); |
336 | } | 264 | } |
337 | 265 | ||
338 | memset (&input, 0, sizeof (input)); | 266 | memset(&input, 0, sizeof(input)); |
339 | input.index = index; | 267 | input.index = index; |
340 | 268 | ||
341 | if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &input)) { | 269 | if (-1 == ioctl(fd, &VIDIOC-ENUMINPUT;, &input)) { |
342 | perror ("VIDIOC_ENUMINPUT"); | 270 | perror("VIDIOC_ENUMINPUT"); |
343 | exit (EXIT_FAILURE); | 271 | exit(EXIT_FAILURE); |
344 | } | 272 | } |
345 | 273 | ||
346 | printf ("Current input: %s\n", input.name); | 274 | printf("Current input: %s\n", input.name); |
347 | </programlisting> | 275 | </programlisting> |
348 | </example> | 276 | </example> |
349 | 277 | ||
@@ -355,9 +283,9 @@ int index; | |||
355 | 283 | ||
356 | index = 0; | 284 | index = 0; |
357 | 285 | ||
358 | if (-1 == ioctl (fd, &VIDIOC-S-INPUT;, &index)) { | 286 | if (-1 == ioctl(fd, &VIDIOC-S-INPUT;, &index)) { |
359 | perror ("VIDIOC_S_INPUT"); | 287 | perror("VIDIOC_S_INPUT"); |
360 | exit (EXIT_FAILURE); | 288 | exit(EXIT_FAILURE); |
361 | } | 289 | } |
362 | </programlisting> | 290 | </programlisting> |
363 | </example> | 291 | </example> |
@@ -397,7 +325,7 @@ available inputs and outputs applications can enumerate them with the | |||
397 | also contains signal status information applicable when the current | 325 | also contains signal status information applicable when the current |
398 | audio input is queried.</para> | 326 | audio input is queried.</para> |
399 | 327 | ||
400 | <para>The &VIDIOC-G-AUDIO; and &VIDIOC-G-AUDOUT; ioctl report | 328 | <para>The &VIDIOC-G-AUDIO; and &VIDIOC-G-AUDOUT; ioctls report |
401 | the current audio input and output, respectively. Note that, unlike | 329 | the current audio input and output, respectively. Note that, unlike |
402 | &VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; these ioctls return a structure | 330 | &VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; these ioctls return a structure |
403 | as <constant>VIDIOC_ENUMAUDIO</constant> and | 331 | as <constant>VIDIOC_ENUMAUDIO</constant> and |
@@ -408,11 +336,11 @@ applications call the &VIDIOC-S-AUDIO; ioctl. To select an audio | |||
408 | output (which presently has no changeable properties) applications | 336 | output (which presently has no changeable properties) applications |
409 | call the &VIDIOC-S-AUDOUT; ioctl.</para> | 337 | call the &VIDIOC-S-AUDOUT; ioctl.</para> |
410 | 338 | ||
411 | <para>Drivers must implement all input ioctls when the device | 339 | <para>Drivers must implement all audio input ioctls when the device |
412 | has one or more inputs, all output ioctls when the device has one | 340 | has multiple selectable audio inputs, all audio output ioctls when the |
413 | or more outputs. When the device has any audio inputs or outputs the | 341 | device has multiple selectable audio outputs. When the device has any |
414 | driver must set the <constant>V4L2_CAP_AUDIO</constant> flag in the | 342 | audio inputs or outputs the driver must set the <constant>V4L2_CAP_AUDIO</constant> |
415 | &v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl.</para> | 343 | flag in the &v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl.</para> |
416 | 344 | ||
417 | <example> | 345 | <example> |
418 | <title>Information about the current audio input</title> | 346 | <title>Information about the current audio input</title> |
@@ -420,14 +348,14 @@ driver must set the <constant>V4L2_CAP_AUDIO</constant> flag in the | |||
420 | <programlisting> | 348 | <programlisting> |
421 | &v4l2-audio; audio; | 349 | &v4l2-audio; audio; |
422 | 350 | ||
423 | memset (&audio, 0, sizeof (audio)); | 351 | memset(&audio, 0, sizeof(audio)); |
424 | 352 | ||
425 | if (-1 == ioctl (fd, &VIDIOC-G-AUDIO;, &audio)) { | 353 | if (-1 == ioctl(fd, &VIDIOC-G-AUDIO;, &audio)) { |
426 | perror ("VIDIOC_G_AUDIO"); | 354 | perror("VIDIOC_G_AUDIO"); |
427 | exit (EXIT_FAILURE); | 355 | exit(EXIT_FAILURE); |
428 | } | 356 | } |
429 | 357 | ||
430 | printf ("Current input: %s\n", audio.name); | 358 | printf("Current input: %s\n", audio.name); |
431 | </programlisting> | 359 | </programlisting> |
432 | </example> | 360 | </example> |
433 | 361 | ||
@@ -437,13 +365,13 @@ printf ("Current input: %s\n", audio.name); | |||
437 | <programlisting> | 365 | <programlisting> |
438 | &v4l2-audio; audio; | 366 | &v4l2-audio; audio; |
439 | 367 | ||
440 | memset (&audio, 0, sizeof (audio)); /* clear audio.mode, audio.reserved */ | 368 | memset(&audio, 0, sizeof(audio)); /* clear audio.mode, audio.reserved */ |
441 | 369 | ||
442 | audio.index = 0; | 370 | audio.index = 0; |
443 | 371 | ||
444 | if (-1 == ioctl (fd, &VIDIOC-S-AUDIO;, &audio)) { | 372 | if (-1 == ioctl(fd, &VIDIOC-S-AUDIO;, &audio)) { |
445 | perror ("VIDIOC_S_AUDIO"); | 373 | perror("VIDIOC_S_AUDIO"); |
446 | exit (EXIT_FAILURE); | 374 | exit(EXIT_FAILURE); |
447 | } | 375 | } |
448 | </programlisting> | 376 | </programlisting> |
449 | </example> | 377 | </example> |
@@ -468,7 +396,7 @@ the tuner.</para> | |||
468 | video inputs.</para> | 396 | video inputs.</para> |
469 | 397 | ||
470 | <para>To query and change tuner properties applications use the | 398 | <para>To query and change tuner properties applications use the |
471 | &VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; ioctl, respectively. The | 399 | &VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; ioctls, respectively. The |
472 | &v4l2-tuner; returned by <constant>VIDIOC_G_TUNER</constant> also | 400 | &v4l2-tuner; returned by <constant>VIDIOC_G_TUNER</constant> also |
473 | contains signal status information applicable when the tuner of the | 401 | contains signal status information applicable when the tuner of the |
474 | current video or radio input is queried. Note that | 402 | current video or radio input is queried. Note that |
@@ -533,7 +461,7 @@ standards or variations of standards. Each video input and output may | |||
533 | support another set of standards. This set is reported by the | 461 | support another set of standards. This set is reported by the |
534 | <structfield>std</structfield> field of &v4l2-input; and | 462 | <structfield>std</structfield> field of &v4l2-input; and |
535 | &v4l2-output; returned by the &VIDIOC-ENUMINPUT; and | 463 | &v4l2-output; returned by the &VIDIOC-ENUMINPUT; and |
536 | &VIDIOC-ENUMOUTPUT; ioctl, respectively.</para> | 464 | &VIDIOC-ENUMOUTPUT; ioctls, respectively.</para> |
537 | 465 | ||
538 | <para>V4L2 defines one bit for each analog video standard | 466 | <para>V4L2 defines one bit for each analog video standard |
539 | currently in use worldwide, and sets aside bits for driver defined | 467 | currently in use worldwide, and sets aside bits for driver defined |
@@ -564,28 +492,10 @@ automatically.</para> | |||
564 | <para>To query and select the standard used by the current video | 492 | <para>To query and select the standard used by the current video |
565 | input or output applications call the &VIDIOC-G-STD; and | 493 | input or output applications call the &VIDIOC-G-STD; and |
566 | &VIDIOC-S-STD; ioctl, respectively. The <emphasis>received</emphasis> | 494 | &VIDIOC-S-STD; ioctl, respectively. The <emphasis>received</emphasis> |
567 | standard can be sensed with the &VIDIOC-QUERYSTD; ioctl. Note that the parameter of all these ioctls is a pointer to a &v4l2-std-id; type (a standard set), <emphasis>not</emphasis> an index into the standard enumeration.<footnote> | 495 | standard can be sensed with the &VIDIOC-QUERYSTD; ioctl. Note that the |
568 | <para>An alternative to the current scheme is to use pointers | 496 | parameter of all these ioctls is a pointer to a &v4l2-std-id; type |
569 | to indices as arguments of <constant>VIDIOC_G_STD</constant> and | 497 | (a standard set), <emphasis>not</emphasis> an index into the standard |
570 | <constant>VIDIOC_S_STD</constant>, the &v4l2-input; and | 498 | enumeration. Drivers must implement all video standard ioctls |
571 | &v4l2-output; <structfield>std</structfield> field would be a set of | ||
572 | indices like <structfield>audioset</structfield>.</para> | ||
573 | <para>Indices are consistent with the rest of the API | ||
574 | and identify the standard unambiguously. In the present scheme of | ||
575 | things an enumerated standard is looked up by &v4l2-std-id;. Now the | ||
576 | standards supported by the inputs of a device can overlap. Just | ||
577 | assume the tuner and composite input in the example above both | ||
578 | exist on a device. An enumeration of "PAL-B/G", "PAL-H/I" suggests | ||
579 | a choice which does not exist. We cannot merge or omit sets, because | ||
580 | applications would be unable to find the standards reported by | ||
581 | <constant>VIDIOC_G_STD</constant>. That leaves separate enumerations | ||
582 | for each input. Also selecting a standard by &v4l2-std-id; can be | ||
583 | ambiguous. Advantage of this method is that applications need not | ||
584 | identify the standard indirectly, after enumerating.</para><para>So in | ||
585 | summary, the lookup itself is unavoidable. The difference is only | ||
586 | whether the lookup is necessary to find an enumerated standard or to | ||
587 | switch to a standard by &v4l2-std-id;.</para> | ||
588 | </footnote> Drivers must implement all video standard ioctls | ||
589 | when the device has one or more video inputs or outputs.</para> | 499 | when the device has one or more video inputs or outputs.</para> |
590 | 500 | ||
591 | <para>Special rules apply to devices such as USB cameras where the notion of video | 501 | <para>Special rules apply to devices such as USB cameras where the notion of video |
@@ -604,17 +514,10 @@ to zero and the <constant>VIDIOC_G_STD</constant>, | |||
604 | <constant>VIDIOC_S_STD</constant>, | 514 | <constant>VIDIOC_S_STD</constant>, |
605 | <constant>VIDIOC_QUERYSTD</constant> and | 515 | <constant>VIDIOC_QUERYSTD</constant> and |
606 | <constant>VIDIOC_ENUMSTD</constant> ioctls shall return the | 516 | <constant>VIDIOC_ENUMSTD</constant> ioctls shall return the |
607 | &ENOTTY;.<footnote> | 517 | &ENOTTY; or the &EINVAL;.</para> |
608 | <para>See <xref linkend="buffer" /> for a rationale.</para> | ||
609 | <para>Applications can make use of the <xref linkend="input-capabilities" /> and | 518 | <para>Applications can make use of the <xref linkend="input-capabilities" /> and |
610 | <xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls | 519 | <xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls |
611 | are available for the device.</para> | 520 | can be used with the given input or output.</para> |
612 | |||
613 | <para>See <xref linkend="buffer" /> for a rationale. Probably | ||
614 | even USB cameras follow some well known video standard. It might have | ||
615 | been better to explicitly indicate elsewhere if a device cannot live | ||
616 | up to normal expectations, instead of this exception.</para> | ||
617 | </footnote></para> | ||
618 | 521 | ||
619 | <example> | 522 | <example> |
620 | <title>Information about the current video standard</title> | 523 | <title>Information about the current video standard</title> |
@@ -623,22 +526,22 @@ up to normal expectations, instead of this exception.</para> | |||
623 | &v4l2-std-id; std_id; | 526 | &v4l2-std-id; std_id; |
624 | &v4l2-standard; standard; | 527 | &v4l2-standard; standard; |
625 | 528 | ||
626 | if (-1 == ioctl (fd, &VIDIOC-G-STD;, &std_id)) { | 529 | if (-1 == ioctl(fd, &VIDIOC-G-STD;, &std_id)) { |
627 | /* Note when VIDIOC_ENUMSTD always returns ENOTTY this | 530 | /* Note when VIDIOC_ENUMSTD always returns ENOTTY this |
628 | is no video device or it falls under the USB exception, | 531 | is no video device or it falls under the USB exception, |
629 | and VIDIOC_G_STD returning ENOTTY is no error. */ | 532 | and VIDIOC_G_STD returning ENOTTY is no error. */ |
630 | 533 | ||
631 | perror ("VIDIOC_G_STD"); | 534 | perror("VIDIOC_G_STD"); |
632 | exit (EXIT_FAILURE); | 535 | exit(EXIT_FAILURE); |
633 | } | 536 | } |
634 | 537 | ||
635 | memset (&standard, 0, sizeof (standard)); | 538 | memset(&standard, 0, sizeof(standard)); |
636 | standard.index = 0; | 539 | standard.index = 0; |
637 | 540 | ||
638 | while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &standard)) { | 541 | while (0 == ioctl(fd, &VIDIOC-ENUMSTD;, &standard)) { |
639 | if (standard.id & std_id) { | 542 | if (standard.id & std_id) { |
640 | printf ("Current video standard: %s\n", standard.name); | 543 | printf("Current video standard: %s\n", standard.name); |
641 | exit (EXIT_SUCCESS); | 544 | exit(EXIT_SUCCESS); |
642 | } | 545 | } |
643 | 546 | ||
644 | standard.index++; | 547 | standard.index++; |
@@ -648,8 +551,8 @@ while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &standard)) { | |||
648 | empty unless this device falls under the USB exception. */ | 551 | empty unless this device falls under the USB exception. */ |
649 | 552 | ||
650 | if (errno == EINVAL || standard.index == 0) { | 553 | if (errno == EINVAL || standard.index == 0) { |
651 | perror ("VIDIOC_ENUMSTD"); | 554 | perror("VIDIOC_ENUMSTD"); |
652 | exit (EXIT_FAILURE); | 555 | exit(EXIT_FAILURE); |
653 | } | 556 | } |
654 | </programlisting> | 557 | </programlisting> |
655 | </example> | 558 | </example> |
@@ -662,26 +565,26 @@ input</title> | |||
662 | &v4l2-input; input; | 565 | &v4l2-input; input; |
663 | &v4l2-standard; standard; | 566 | &v4l2-standard; standard; |
664 | 567 | ||
665 | memset (&input, 0, sizeof (input)); | 568 | memset(&input, 0, sizeof(input)); |
666 | 569 | ||
667 | if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &input.index)) { | 570 | if (-1 == ioctl(fd, &VIDIOC-G-INPUT;, &input.index)) { |
668 | perror ("VIDIOC_G_INPUT"); | 571 | perror("VIDIOC_G_INPUT"); |
669 | exit (EXIT_FAILURE); | 572 | exit(EXIT_FAILURE); |
670 | } | 573 | } |
671 | 574 | ||
672 | if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &input)) { | 575 | if (-1 == ioctl(fd, &VIDIOC-ENUMINPUT;, &input)) { |
673 | perror ("VIDIOC_ENUM_INPUT"); | 576 | perror("VIDIOC_ENUM_INPUT"); |
674 | exit (EXIT_FAILURE); | 577 | exit(EXIT_FAILURE); |
675 | } | 578 | } |
676 | 579 | ||
677 | printf ("Current input %s supports:\n", input.name); | 580 | printf("Current input %s supports:\n", input.name); |
678 | 581 | ||
679 | memset (&standard, 0, sizeof (standard)); | 582 | memset(&standard, 0, sizeof(standard)); |
680 | standard.index = 0; | 583 | standard.index = 0; |
681 | 584 | ||
682 | while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &standard)) { | 585 | while (0 == ioctl(fd, &VIDIOC-ENUMSTD;, &standard)) { |
683 | if (standard.id & input.std) | 586 | if (standard.id & input.std) |
684 | printf ("%s\n", standard.name); | 587 | printf("%s\n", standard.name); |
685 | 588 | ||
686 | standard.index++; | 589 | standard.index++; |
687 | } | 590 | } |
@@ -690,8 +593,8 @@ while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &standard)) { | |||
690 | empty unless this device falls under the USB exception. */ | 593 | empty unless this device falls under the USB exception. */ |
691 | 594 | ||
692 | if (errno != EINVAL || standard.index == 0) { | 595 | if (errno != EINVAL || standard.index == 0) { |
693 | perror ("VIDIOC_ENUMSTD"); | 596 | perror("VIDIOC_ENUMSTD"); |
694 | exit (EXIT_FAILURE); | 597 | exit(EXIT_FAILURE); |
695 | } | 598 | } |
696 | </programlisting> | 599 | </programlisting> |
697 | </example> | 600 | </example> |
@@ -703,21 +606,21 @@ if (errno != EINVAL || standard.index == 0) { | |||
703 | &v4l2-input; input; | 606 | &v4l2-input; input; |
704 | &v4l2-std-id; std_id; | 607 | &v4l2-std-id; std_id; |
705 | 608 | ||
706 | memset (&input, 0, sizeof (input)); | 609 | memset(&input, 0, sizeof(input)); |
707 | 610 | ||
708 | if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &input.index)) { | 611 | if (-1 == ioctl(fd, &VIDIOC-G-INPUT;, &input.index)) { |
709 | perror ("VIDIOC_G_INPUT"); | 612 | perror("VIDIOC_G_INPUT"); |
710 | exit (EXIT_FAILURE); | 613 | exit(EXIT_FAILURE); |
711 | } | 614 | } |
712 | 615 | ||
713 | if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &input)) { | 616 | if (-1 == ioctl(fd, &VIDIOC-ENUMINPUT;, &input)) { |
714 | perror ("VIDIOC_ENUM_INPUT"); | 617 | perror("VIDIOC_ENUM_INPUT"); |
715 | exit (EXIT_FAILURE); | 618 | exit(EXIT_FAILURE); |
716 | } | 619 | } |
717 | 620 | ||
718 | if (0 == (input.std & V4L2_STD_PAL_BG)) { | 621 | if (0 == (input.std & V4L2_STD_PAL_BG)) { |
719 | fprintf (stderr, "Oops. B/G PAL is not supported.\n"); | 622 | fprintf(stderr, "Oops. B/G PAL is not supported.\n"); |
720 | exit (EXIT_FAILURE); | 623 | exit(EXIT_FAILURE); |
721 | } | 624 | } |
722 | 625 | ||
723 | /* Note this is also supposed to work when only B | 626 | /* Note this is also supposed to work when only B |
@@ -725,9 +628,9 @@ if (0 == (input.std & V4L2_STD_PAL_BG)) { | |||
725 | 628 | ||
726 | std_id = V4L2_STD_PAL_BG; | 629 | std_id = V4L2_STD_PAL_BG; |
727 | 630 | ||
728 | if (-1 == ioctl (fd, &VIDIOC-S-STD;, &std_id)) { | 631 | if (-1 == ioctl(fd, &VIDIOC-S-STD;, &std_id)) { |
729 | perror ("VIDIOC_S_STD"); | 632 | perror("VIDIOC_S_STD"); |
730 | exit (EXIT_FAILURE); | 633 | exit(EXIT_FAILURE); |
731 | } | 634 | } |
732 | </programlisting> | 635 | </programlisting> |
733 | </example> | 636 | </example> |
@@ -740,26 +643,25 @@ corresponding video timings. Today there are many more different hardware interf | |||
740 | such as High Definition TV interfaces (HDMI), VGA, DVI connectors etc., that carry | 643 | such as High Definition TV interfaces (HDMI), VGA, DVI connectors etc., that carry |
741 | video signals and there is a need to extend the API to select the video timings | 644 | video signals and there is a need to extend the API to select the video timings |
742 | for these interfaces. Since it is not possible to extend the &v4l2-std-id; due to | 645 | for these interfaces. Since it is not possible to extend the &v4l2-std-id; due to |
743 | the limited bits available, a new set of IOCTLs was added to set/get video timings at | 646 | the limited bits available, a new set of ioctls was added to set/get video timings at |
744 | the input and output: </para><itemizedlist> | 647 | the input and output.</para> |
745 | <listitem> | 648 | |
746 | <para>DV Timings: This will allow applications to define detailed | 649 | <para>These ioctls deal with the detailed digital video timings that define |
747 | video timings for the interface. This includes parameters such as width, height, | 650 | each video format. This includes parameters such as the active video width and height, |
748 | polarities, frontporch, backporch etc. The <filename>linux/v4l2-dv-timings.h</filename> | 651 | signal polarities, frontporches, backporches, sync widths etc. The <filename>linux/v4l2-dv-timings.h</filename> |
749 | header can be used to get the timings of the formats in the <xref linkend="cea861" /> and | 652 | header can be used to get the timings of the formats in the <xref linkend="cea861" /> and |
750 | <xref linkend="vesadmt" /> standards. | 653 | <xref linkend="vesadmt" /> standards. |
751 | </para> | 654 | </para> |
752 | </listitem> | 655 | |
753 | </itemizedlist> | 656 | <para>To enumerate and query the attributes of the DV timings supported by a device |
754 | <para>To enumerate and query the attributes of the DV timings supported by a device, | ||
755 | applications use the &VIDIOC-ENUM-DV-TIMINGS; and &VIDIOC-DV-TIMINGS-CAP; ioctls. | 657 | applications use the &VIDIOC-ENUM-DV-TIMINGS; and &VIDIOC-DV-TIMINGS-CAP; ioctls. |
756 | To set DV timings for the device, applications use the | 658 | To set DV timings for the device applications use the |
757 | &VIDIOC-S-DV-TIMINGS; ioctl and to get current DV timings they use the | 659 | &VIDIOC-S-DV-TIMINGS; ioctl and to get current DV timings they use the |
758 | &VIDIOC-G-DV-TIMINGS; ioctl. To detect the DV timings as seen by the video receiver applications | 660 | &VIDIOC-G-DV-TIMINGS; ioctl. To detect the DV timings as seen by the video receiver applications |
759 | use the &VIDIOC-QUERY-DV-TIMINGS; ioctl.</para> | 661 | use the &VIDIOC-QUERY-DV-TIMINGS; ioctl.</para> |
760 | <para>Applications can make use of the <xref linkend="input-capabilities" /> and | 662 | <para>Applications can make use of the <xref linkend="input-capabilities" /> and |
761 | <xref linkend="output-capabilities"/> flags to decide what ioctls are available to set the | 663 | <xref linkend="output-capabilities"/> flags to determine whether the digital video ioctls |
762 | video timings for the device.</para> | 664 | can be used with the given input or output.</para> |
763 | </section> | 665 | </section> |
764 | 666 | ||
765 | &sub-controls; | 667 | &sub-controls; |
diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 86c6dd2f6b8a..eee6f0f4aa43 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml | |||
@@ -2535,6 +2535,16 @@ fields changed from _s32 to _u32. | |||
2535 | </orderedlist> | 2535 | </orderedlist> |
2536 | </section> | 2536 | </section> |
2537 | 2537 | ||
2538 | <section> | ||
2539 | <title>V4L2 in Linux 3.15</title> | ||
2540 | <orderedlist> | ||
2541 | <listitem> | ||
2542 | <para>Added Software Defined Radio (SDR) Interface. | ||
2543 | </para> | ||
2544 | </listitem> | ||
2545 | </orderedlist> | ||
2546 | </section> | ||
2547 | |||
2538 | <section id="other"> | 2548 | <section id="other"> |
2539 | <title>Relation of V4L2 to other Linux multimedia APIs</title> | 2549 | <title>Relation of V4L2 to other Linux multimedia APIs</title> |
2540 | 2550 | ||
@@ -2651,6 +2661,9 @@ ioctls.</para> | |||
2651 | <listitem> | 2661 | <listitem> |
2652 | <para>Exporting DMABUF files using &VIDIOC-EXPBUF; ioctl.</para> | 2662 | <para>Exporting DMABUF files using &VIDIOC-EXPBUF; ioctl.</para> |
2653 | </listitem> | 2663 | </listitem> |
2664 | <listitem> | ||
2665 | <para>Software Defined Radio (SDR) Interface, <xref linkend="sdr" />.</para> | ||
2666 | </listitem> | ||
2654 | </itemizedlist> | 2667 | </itemizedlist> |
2655 | </section> | 2668 | </section> |
2656 | 2669 | ||
diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index a5a3188e5af7..47198eef75a4 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml | |||
@@ -2258,6 +2258,26 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders.</entry> | |||
2258 | VBV buffer control.</entry> | 2258 | VBV buffer control.</entry> |
2259 | </row> | 2259 | </row> |
2260 | 2260 | ||
2261 | <row><entry></entry></row> | ||
2262 | <row id="v4l2-mpeg-video-hor-search-range"> | ||
2263 | <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE</constant> </entry> | ||
2264 | <entry>integer</entry> | ||
2265 | </row> | ||
2266 | <row><entry spanname="descr">Horizontal search range defines maximum horizontal search area in pixels | ||
2267 | to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set | ||
2268 | horizontal search range for motion estimation module in video encoder.</entry> | ||
2269 | </row> | ||
2270 | |||
2271 | <row><entry></entry></row> | ||
2272 | <row id="v4l2-mpeg-video-vert-search-range"> | ||
2273 | <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE</constant> </entry> | ||
2274 | <entry>integer</entry> | ||
2275 | </row> | ||
2276 | <row><entry spanname="descr">Vertical search range defines maximum vertical search area in pixels | ||
2277 | to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set | ||
2278 | vertical search range for motion estimation module in video encoder.</entry> | ||
2279 | </row> | ||
2280 | |||
2261 | <row><entry></entry></row> | 2281 | <row><entry></entry></row> |
2262 | <row> | 2282 | <row> |
2263 | <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant> </entry> | 2283 | <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant> </entry> |
@@ -4370,6 +4390,24 @@ interface and may change in the future.</para> | |||
4370 | <entry>The flash controller has detected a short or open | 4390 | <entry>The flash controller has detected a short or open |
4371 | circuit condition on the indicator LED.</entry> | 4391 | circuit condition on the indicator LED.</entry> |
4372 | </row> | 4392 | </row> |
4393 | <row> | ||
4394 | <entry><constant>V4L2_FLASH_FAULT_UNDER_VOLTAGE</constant></entry> | ||
4395 | <entry>Flash controller voltage to the flash LED | ||
4396 | has been below the minimum limit specific to the flash | ||
4397 | controller.</entry> | ||
4398 | </row> | ||
4399 | <row> | ||
4400 | <entry><constant>V4L2_FLASH_FAULT_INPUT_VOLTAGE</constant></entry> | ||
4401 | <entry>The input voltage of the flash controller is below | ||
4402 | the limit under which strobing the flash at full current | ||
4403 | will not be possible.The condition persists until this flag | ||
4404 | is no longer set.</entry> | ||
4405 | </row> | ||
4406 | <row> | ||
4407 | <entry><constant>V4L2_FLASH_FAULT_LED_OVER_TEMPERATURE</constant></entry> | ||
4408 | <entry>The temperature of the LED has exceeded its | ||
4409 | allowed upper limit.</entry> | ||
4410 | </row> | ||
4373 | </tbody> | 4411 | </tbody> |
4374 | </entrytbl> | 4412 | </entrytbl> |
4375 | </row> | 4413 | </row> |
@@ -4971,4 +5009,142 @@ defines possible values for de-emphasis. Here they are:</entry> | |||
4971 | </table> | 5009 | </table> |
4972 | 5010 | ||
4973 | </section> | 5011 | </section> |
5012 | |||
5013 | <section id="rf-tuner-controls"> | ||
5014 | <title>RF Tuner Control Reference</title> | ||
5015 | |||
5016 | <para> | ||
5017 | The RF Tuner (RF_TUNER) class includes controls for common features of devices | ||
5018 | having RF tuner. | ||
5019 | </para> | ||
5020 | <para> | ||
5021 | In this context, RF tuner is radio receiver circuit between antenna and | ||
5022 | demodulator. It receives radio frequency (RF) from the antenna and converts that | ||
5023 | received signal to lower intermediate frequency (IF) or baseband frequency (BB). | ||
5024 | Tuners that could do baseband output are often called Zero-IF tuners. Older | ||
5025 | tuners were typically simple PLL tuners inside a metal box, whilst newer ones | ||
5026 | are highly integrated chips without a metal box "silicon tuners". These controls | ||
5027 | are mostly applicable for new feature rich silicon tuners, just because older | ||
5028 | tuners does not have much adjustable features. | ||
5029 | </para> | ||
5030 | <para> | ||
5031 | For more information about RF tuners see | ||
5032 | <ulink url="http://en.wikipedia.org/wiki/Tuner_%28radio%29">Tuner (radio)</ulink> | ||
5033 | and | ||
5034 | <ulink url="http://en.wikipedia.org/wiki/RF_front_end">RF front end</ulink> | ||
5035 | from Wikipedia. | ||
5036 | </para> | ||
5037 | |||
5038 | <table pgwide="1" frame="none" id="rf-tuner-control-id"> | ||
5039 | <title>RF_TUNER Control IDs</title> | ||
5040 | |||
5041 | <tgroup cols="4"> | ||
5042 | <colspec colname="c1" colwidth="1*" /> | ||
5043 | <colspec colname="c2" colwidth="6*" /> | ||
5044 | <colspec colname="c3" colwidth="2*" /> | ||
5045 | <colspec colname="c4" colwidth="6*" /> | ||
5046 | <spanspec namest="c1" nameend="c2" spanname="id" /> | ||
5047 | <spanspec namest="c2" nameend="c4" spanname="descr" /> | ||
5048 | <thead> | ||
5049 | <row> | ||
5050 | <entry spanname="id" align="left">ID</entry> | ||
5051 | <entry align="left">Type</entry> | ||
5052 | </row> | ||
5053 | <row rowsep="1"> | ||
5054 | <entry spanname="descr" align="left">Description</entry> | ||
5055 | </row> | ||
5056 | </thead> | ||
5057 | <tbody valign="top"> | ||
5058 | <row><entry></entry></row> | ||
5059 | <row> | ||
5060 | <entry spanname="id"><constant>V4L2_CID_RF_TUNER_CLASS</constant> </entry> | ||
5061 | <entry>class</entry> | ||
5062 | </row><row><entry spanname="descr">The RF_TUNER class | ||
5063 | descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a | ||
5064 | description of this control class.</entry> | ||
5065 | </row> | ||
5066 | <row> | ||
5067 | <entry spanname="id"><constant>V4L2_CID_RF_TUNER_BANDWIDTH_AUTO</constant> </entry> | ||
5068 | <entry>boolean</entry> | ||
5069 | </row> | ||
5070 | <row> | ||
5071 | <entry spanname="descr">Enables/disables tuner radio channel | ||
5072 | bandwidth configuration. In automatic mode bandwidth configuration is performed | ||
5073 | by the driver.</entry> | ||
5074 | </row> | ||
5075 | <row> | ||
5076 | <entry spanname="id"><constant>V4L2_CID_RF_TUNER_BANDWIDTH</constant> </entry> | ||
5077 | <entry>integer</entry> | ||
5078 | </row> | ||
5079 | <row> | ||
5080 | <entry spanname="descr">Filter(s) on tuner signal path are used to | ||
5081 | filter signal according to receiving party needs. Driver configures filters to | ||
5082 | fulfill desired bandwidth requirement. Used when V4L2_CID_RF_TUNER_BANDWIDTH_AUTO is not | ||
5083 | set. Unit is in Hz. The range and step are driver-specific.</entry> | ||
5084 | </row> | ||
5085 | <row> | ||
5086 | <entry spanname="id"><constant>V4L2_CID_RF_TUNER_LNA_GAIN_AUTO</constant> </entry> | ||
5087 | <entry>boolean</entry> | ||
5088 | </row> | ||
5089 | <row> | ||
5090 | <entry spanname="descr">Enables/disables LNA automatic gain control (AGC)</entry> | ||
5091 | </row> | ||
5092 | <row> | ||
5093 | <entry spanname="id"><constant>V4L2_CID_RF_TUNER_MIXER_GAIN_AUTO</constant> </entry> | ||
5094 | <entry>boolean</entry> | ||
5095 | </row> | ||
5096 | <row> | ||
5097 | <entry spanname="descr">Enables/disables mixer automatic gain control (AGC)</entry> | ||
5098 | </row> | ||
5099 | <row> | ||
5100 | <entry spanname="id"><constant>V4L2_CID_RF_TUNER_IF_GAIN_AUTO</constant> </entry> | ||
5101 | <entry>boolean</entry> | ||
5102 | </row> | ||
5103 | <row> | ||
5104 | <entry spanname="descr">Enables/disables IF automatic gain control (AGC)</entry> | ||
5105 | </row> | ||
5106 | <row> | ||
5107 | <entry spanname="id"><constant>V4L2_CID_RF_TUNER_LNA_GAIN</constant> </entry> | ||
5108 | <entry>integer</entry> | ||
5109 | </row> | ||
5110 | <row> | ||
5111 | <entry spanname="descr">LNA (low noise amplifier) gain is first | ||
5112 | gain stage on the RF tuner signal path. It is located very close to tuner | ||
5113 | antenna input. Used when <constant>V4L2_CID_RF_TUNER_LNA_GAIN_AUTO</constant> is not set. | ||
5114 | The range and step are driver-specific.</entry> | ||
5115 | </row> | ||
5116 | <row> | ||
5117 | <entry spanname="id"><constant>V4L2_CID_RF_TUNER_MIXER_GAIN</constant> </entry> | ||
5118 | <entry>integer</entry> | ||
5119 | </row> | ||
5120 | <row> | ||
5121 | <entry spanname="descr">Mixer gain is second gain stage on the RF | ||
5122 | tuner signal path. It is located inside mixer block, where RF signal is | ||
5123 | down-converted by the mixer. Used when <constant>V4L2_CID_RF_TUNER_MIXER_GAIN_AUTO</constant> | ||
5124 | is not set. The range and step are driver-specific.</entry> | ||
5125 | </row> | ||
5126 | <row> | ||
5127 | <entry spanname="id"><constant>V4L2_CID_RF_TUNER_IF_GAIN</constant> </entry> | ||
5128 | <entry>integer</entry> | ||
5129 | </row> | ||
5130 | <row> | ||
5131 | <entry spanname="descr">IF gain is last gain stage on the RF tuner | ||
5132 | signal path. It is located on output of RF tuner. It controls signal level of | ||
5133 | intermediate frequency output or baseband output. Used when | ||
5134 | <constant>V4L2_CID_RF_TUNER_IF_GAIN_AUTO</constant> is not set. The range and step are | ||
5135 | driver-specific.</entry> | ||
5136 | </row> | ||
5137 | <row> | ||
5138 | <entry spanname="id"><constant>V4L2_CID_RF_TUNER_PLL_LOCK</constant> </entry> | ||
5139 | <entry>boolean</entry> | ||
5140 | </row> | ||
5141 | <row> | ||
5142 | <entry spanname="descr">Is synthesizer PLL locked? RF tuner is | ||
5143 | receiving given frequency when that control is set. This is a read-only control. | ||
5144 | </entry> | ||
5145 | </row> | ||
5146 | </tbody> | ||
5147 | </tgroup> | ||
5148 | </table> | ||
5149 | </section> | ||
4974 | </section> | 5150 | </section> |
diff --git a/Documentation/DocBook/media/v4l/dev-osd.xml b/Documentation/DocBook/media/v4l/dev-osd.xml index dd91d6134e8c..54853329140b 100644 --- a/Documentation/DocBook/media/v4l/dev-osd.xml +++ b/Documentation/DocBook/media/v4l/dev-osd.xml | |||
@@ -56,18 +56,18 @@ framebuffer device.</para> | |||
56 | unsigned int i; | 56 | unsigned int i; |
57 | int fb_fd; | 57 | int fb_fd; |
58 | 58 | ||
59 | if (-1 == ioctl (fd, VIDIOC_G_FBUF, &fbuf)) { | 59 | if (-1 == ioctl(fd, VIDIOC_G_FBUF, &fbuf)) { |
60 | perror ("VIDIOC_G_FBUF"); | 60 | perror("VIDIOC_G_FBUF"); |
61 | exit (EXIT_FAILURE); | 61 | exit(EXIT_FAILURE); |
62 | } | 62 | } |
63 | 63 | ||
64 | for (i = 0; i > 30; ++i) { | 64 | for (i = 0; i < 30; i++) { |
65 | char dev_name[16]; | 65 | char dev_name[16]; |
66 | struct fb_fix_screeninfo si; | 66 | struct fb_fix_screeninfo si; |
67 | 67 | ||
68 | snprintf (dev_name, sizeof (dev_name), "/dev/fb%u", i); | 68 | snprintf(dev_name, sizeof(dev_name), "/dev/fb%u", i); |
69 | 69 | ||
70 | fb_fd = open (dev_name, O_RDWR); | 70 | fb_fd = open(dev_name, O_RDWR); |
71 | if (-1 == fb_fd) { | 71 | if (-1 == fb_fd) { |
72 | switch (errno) { | 72 | switch (errno) { |
73 | case ENOENT: /* no such file */ | 73 | case ENOENT: /* no such file */ |
@@ -75,19 +75,19 @@ for (i = 0; i > 30; ++i) { | |||
75 | continue; | 75 | continue; |
76 | 76 | ||
77 | default: | 77 | default: |
78 | perror ("open"); | 78 | perror("open"); |
79 | exit (EXIT_FAILURE); | 79 | exit(EXIT_FAILURE); |
80 | } | 80 | } |
81 | } | 81 | } |
82 | 82 | ||
83 | if (0 == ioctl (fb_fd, FBIOGET_FSCREENINFO, &si)) { | 83 | if (0 == ioctl(fb_fd, FBIOGET_FSCREENINFO, &si)) { |
84 | if (si.smem_start == (unsigned long) fbuf.base) | 84 | if (si.smem_start == (unsigned long)fbuf.base) |
85 | break; | 85 | break; |
86 | } else { | 86 | } else { |
87 | /* Apparently not a framebuffer device. */ | 87 | /* Apparently not a framebuffer device. */ |
88 | } | 88 | } |
89 | 89 | ||
90 | close (fb_fd); | 90 | close(fb_fd); |
91 | fb_fd = -1; | 91 | fb_fd = -1; |
92 | } | 92 | } |
93 | 93 | ||
diff --git a/Documentation/DocBook/media/v4l/dev-sdr.xml b/Documentation/DocBook/media/v4l/dev-sdr.xml new file mode 100644 index 000000000000..dc14804f5436 --- /dev/null +++ b/Documentation/DocBook/media/v4l/dev-sdr.xml | |||
@@ -0,0 +1,110 @@ | |||
1 | <title>Software Defined Radio Interface (SDR)</title> | ||
2 | |||
3 | <note> | ||
4 | <title>Experimental</title> | ||
5 | <para>This is an <link linkend="experimental"> experimental </link> | ||
6 | interface and may change in the future.</para> | ||
7 | </note> | ||
8 | |||
9 | <para> | ||
10 | SDR is an abbreviation of Software Defined Radio, the radio device | ||
11 | which uses application software for modulation or demodulation. This interface | ||
12 | is intended for controlling and data streaming of such devices. | ||
13 | </para> | ||
14 | |||
15 | <para> | ||
16 | SDR devices are accessed through character device special files named | ||
17 | <filename>/dev/swradio0</filename> to <filename>/dev/swradio255</filename> | ||
18 | with major number 81 and dynamically allocated minor numbers 0 to 255. | ||
19 | </para> | ||
20 | |||
21 | <section> | ||
22 | <title>Querying Capabilities</title> | ||
23 | |||
24 | <para> | ||
25 | Devices supporting the SDR receiver interface set the | ||
26 | <constant>V4L2_CAP_SDR_CAPTURE</constant> and | ||
27 | <constant>V4L2_CAP_TUNER</constant> flag in the | ||
28 | <structfield>capabilities</structfield> field of &v4l2-capability; | ||
29 | returned by the &VIDIOC-QUERYCAP; ioctl. That flag means the device has an | ||
30 | Analog to Digital Converter (ADC), which is a mandatory element for the SDR receiver. | ||
31 | At least one of the read/write, streaming or asynchronous I/O methods must | ||
32 | be supported. | ||
33 | </para> | ||
34 | </section> | ||
35 | |||
36 | <section> | ||
37 | <title>Supplemental Functions</title> | ||
38 | |||
39 | <para> | ||
40 | SDR devices can support <link linkend="control">controls</link>, and must | ||
41 | support the <link linkend="tuner">tuner</link> ioctls. Tuner ioctls are used | ||
42 | for setting the ADC sampling rate (sampling frequency) and the possible RF tuner | ||
43 | frequency. | ||
44 | </para> | ||
45 | |||
46 | <para> | ||
47 | The <constant>V4L2_TUNER_ADC</constant> tuner type is used for ADC tuners, and | ||
48 | the <constant>V4L2_TUNER_RF</constant> tuner type is used for RF tuners. The | ||
49 | tuner index of the RF tuner (if any) must always follow the ADC tuner index. | ||
50 | Normally the ADC tuner is #0 and the RF tuner is #1. | ||
51 | </para> | ||
52 | |||
53 | <para> | ||
54 | The &VIDIOC-S-HW-FREQ-SEEK; ioctl is not supported. | ||
55 | </para> | ||
56 | </section> | ||
57 | |||
58 | <section> | ||
59 | <title>Data Format Negotiation</title> | ||
60 | |||
61 | <para> | ||
62 | The SDR capture device uses the <link linkend="format">format</link> ioctls to | ||
63 | select the capture format. Both the sampling resolution and the data streaming | ||
64 | format are bound to that selectable format. In addition to the basic | ||
65 | <link linkend="format">format</link> ioctls, the &VIDIOC-ENUM-FMT; ioctl | ||
66 | must be supported as well. | ||
67 | </para> | ||
68 | |||
69 | <para> | ||
70 | To use the <link linkend="format">format</link> ioctls applications set the | ||
71 | <structfield>type</structfield> field of a &v4l2-format; to | ||
72 | <constant>V4L2_BUF_TYPE_SDR_CAPTURE</constant> and use the &v4l2-sdr-format; | ||
73 | <structfield>sdr</structfield> member of the <structfield>fmt</structfield> | ||
74 | union as needed per the desired operation. | ||
75 | Currently only the <structfield>pixelformat</structfield> field of | ||
76 | &v4l2-sdr-format; is used. The content of that field is the V4L2 fourcc code | ||
77 | of the data format. | ||
78 | </para> | ||
79 | |||
80 | <table pgwide="1" frame="none" id="v4l2-sdr-format"> | ||
81 | <title>struct <structname>v4l2_sdr_format</structname></title> | ||
82 | <tgroup cols="3"> | ||
83 | &cs-str; | ||
84 | <tbody valign="top"> | ||
85 | <row> | ||
86 | <entry>__u32</entry> | ||
87 | <entry><structfield>pixelformat</structfield></entry> | ||
88 | <entry> | ||
89 | The data format or type of compression, set by the application. This is a | ||
90 | little endian <link linkend="v4l2-fourcc">four character code</link>. | ||
91 | V4L2 defines SDR formats in <xref linkend="sdr-formats" />. | ||
92 | </entry> | ||
93 | </row> | ||
94 | <row> | ||
95 | <entry>__u8</entry> | ||
96 | <entry><structfield>reserved[28]</structfield></entry> | ||
97 | <entry>This array is reserved for future extensions. | ||
98 | Drivers and applications must set it to zero.</entry> | ||
99 | </row> | ||
100 | </tbody> | ||
101 | </tgroup> | ||
102 | </table> | ||
103 | |||
104 | <para> | ||
105 | An SDR device may support <link linkend="rw">read/write</link> | ||
106 | and/or streaming (<link linkend="mmap">memory mapping</link> | ||
107 | or <link linkend="userp">user pointer</link>) I/O. | ||
108 | </para> | ||
109 | |||
110 | </section> | ||
diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 2c4c068dde83..97a69bf6f3eb 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml | |||
@@ -339,8 +339,8 @@ returns immediately with an &EAGAIN; when no buffer is available. The | |||
339 | queues as a side effect. Since there is no notion of doing anything | 339 | queues as a side effect. Since there is no notion of doing anything |
340 | "now" on a multitasking system, if an application needs to synchronize | 340 | "now" on a multitasking system, if an application needs to synchronize |
341 | with another event it should examine the &v4l2-buffer; | 341 | with another event it should examine the &v4l2-buffer; |
342 | <structfield>timestamp</structfield> of captured buffers, or set the | 342 | <structfield>timestamp</structfield> of captured or outputted buffers. |
343 | field before enqueuing buffers for output.</para> | 343 | </para> |
344 | 344 | ||
345 | <para>Drivers implementing memory mapping I/O must | 345 | <para>Drivers implementing memory mapping I/O must |
346 | support the <constant>VIDIOC_REQBUFS</constant>, | 346 | support the <constant>VIDIOC_REQBUFS</constant>, |
@@ -457,7 +457,7 @@ queues and unlocks all buffers as a side effect. Since there is no | |||
457 | notion of doing anything "now" on a multitasking system, if an | 457 | notion of doing anything "now" on a multitasking system, if an |
458 | application needs to synchronize with another event it should examine | 458 | application needs to synchronize with another event it should examine |
459 | the &v4l2-buffer; <structfield>timestamp</structfield> of captured | 459 | the &v4l2-buffer; <structfield>timestamp</structfield> of captured |
460 | buffers, or set the field before enqueuing buffers for output.</para> | 460 | or outputted buffers.</para> |
461 | 461 | ||
462 | <para>Drivers implementing user pointer I/O must | 462 | <para>Drivers implementing user pointer I/O must |
463 | support the <constant>VIDIOC_REQBUFS</constant>, | 463 | support the <constant>VIDIOC_REQBUFS</constant>, |
@@ -620,8 +620,7 @@ returns immediately with an &EAGAIN; when no buffer is available. The | |||
620 | unlocks all buffers as a side effect. Since there is no notion of doing | 620 | unlocks all buffers as a side effect. Since there is no notion of doing |
621 | anything "now" on a multitasking system, if an application needs to synchronize | 621 | anything "now" on a multitasking system, if an application needs to synchronize |
622 | with another event it should examine the &v4l2-buffer; | 622 | with another event it should examine the &v4l2-buffer; |
623 | <structfield>timestamp</structfield> of captured buffers, or set the field | 623 | <structfield>timestamp</structfield> of captured or outputted buffers.</para> |
624 | before enqueuing buffers for output.</para> | ||
625 | 624 | ||
626 | <para>Drivers implementing DMABUF importing I/O must support the | 625 | <para>Drivers implementing DMABUF importing I/O must support the |
627 | <constant>VIDIOC_REQBUFS</constant>, <constant>VIDIOC_QBUF</constant>, | 626 | <constant>VIDIOC_REQBUFS</constant>, <constant>VIDIOC_QBUF</constant>, |
@@ -654,38 +653,19 @@ plane, are stored in struct <structname>v4l2_plane</structname> instead. | |||
654 | In that case, struct <structname>v4l2_buffer</structname> contains an array of | 653 | In that case, struct <structname>v4l2_buffer</structname> contains an array of |
655 | plane structures.</para> | 654 | plane structures.</para> |
656 | 655 | ||
657 | <para>Nominally timestamps refer to the first data byte transmitted. | 656 | <para>Dequeued video buffers come with timestamps. The driver |
658 | In practice however the wide range of hardware covered by the V4L2 API | 657 | decides at which part of the frame and with which clock the |
659 | limits timestamp accuracy. Often an interrupt routine will | 658 | timestamp is taken. Please see flags in the masks |
660 | sample the system clock shortly after the field or frame was stored | 659 | <constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant> and |
661 | completely in memory. So applications must expect a constant | 660 | <constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> in <xref |
662 | difference up to one field or frame period plus a small (few scan | 661 | linkend="buffer-flags" />. These flags are always valid and constant |
663 | lines) random error. The delay and error can be much | 662 | across all buffers during the whole video stream. Changes in these |
664 | larger due to compression or transmission over an external bus when | 663 | flags may take place as a side effect of &VIDIOC-S-INPUT; or |
665 | the frames are not properly stamped by the sender. This is frequently | 664 | &VIDIOC-S-OUTPUT; however. The |
666 | the case with USB cameras. Here timestamps refer to the instant the | 665 | <constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant> timestamp type |
667 | field or frame was received by the driver, not the capture time. These | 666 | which is used by e.g. on mem-to-mem devices is an exception to the |
668 | devices identify by not enumerating any video standards, see <xref | 667 | rule: the timestamp source flags are copied from the OUTPUT video |
669 | linkend="standard" />.</para> | 668 | buffer to the CAPTURE video buffer.</para> |
670 | |||
671 | <para>Similar limitations apply to output timestamps. Typically | ||
672 | the video hardware locks to a clock controlling the video timing, the | ||
673 | horizontal and vertical synchronization pulses. At some point in the | ||
674 | line sequence, possibly the vertical blanking, an interrupt routine | ||
675 | samples the system clock, compares against the timestamp and programs | ||
676 | the hardware to repeat the previous field or frame, or to display the | ||
677 | buffer contents.</para> | ||
678 | |||
679 | <para>Apart of limitations of the video device and natural | ||
680 | inaccuracies of all clocks, it should be noted system time itself is | ||
681 | not perfectly stable. It can be affected by power saving cycles, | ||
682 | warped to insert leap seconds, or even turned back or forth by the | ||
683 | system administrator affecting long term measurements. <footnote> | ||
684 | <para>Since no other Linux multimedia | ||
685 | API supports unadjusted time it would be foolish to introduce here. We | ||
686 | must use a universally supported clock to synchronize different media, | ||
687 | hence time of day.</para> | ||
688 | </footnote></para> | ||
689 | 669 | ||
690 | <table frame="none" pgwide="1" id="v4l2-buffer"> | 670 | <table frame="none" pgwide="1" id="v4l2-buffer"> |
691 | <title>struct <structname>v4l2_buffer</structname></title> | 671 | <title>struct <structname>v4l2_buffer</structname></title> |
@@ -696,10 +676,11 @@ hence time of day.</para> | |||
696 | <entry>__u32</entry> | 676 | <entry>__u32</entry> |
697 | <entry><structfield>index</structfield></entry> | 677 | <entry><structfield>index</structfield></entry> |
698 | <entry></entry> | 678 | <entry></entry> |
699 | <entry>Number of the buffer, set by the application. This | 679 | <entry>Number of the buffer, set by the application except |
700 | field is only used for <link linkend="mmap">memory mapping</link> I/O | 680 | when calling &VIDIOC-DQBUF;, then it is set by the driver. |
701 | and can range from zero to the number of buffers allocated | 681 | This field can range from zero to the number of buffers allocated |
702 | with the &VIDIOC-REQBUFS; ioctl (&v4l2-requestbuffers; <structfield>count</structfield>) minus one.</entry> | 682 | with the &VIDIOC-REQBUFS; ioctl (&v4l2-requestbuffers; <structfield>count</structfield>), |
683 | plus any buffers allocated with &VIDIOC-CREATE-BUFS; minus one.</entry> | ||
703 | </row> | 684 | </row> |
704 | <row> | 685 | <row> |
705 | <entry>__u32</entry> | 686 | <entry>__u32</entry> |
@@ -718,7 +699,7 @@ linkend="v4l2-buf-type" /></entry> | |||
718 | buffer. It depends on the negotiated data format and may change with | 699 | buffer. It depends on the negotiated data format and may change with |
719 | each buffer for compressed variable size data like JPEG images. | 700 | each buffer for compressed variable size data like JPEG images. |
720 | Drivers must set this field when <structfield>type</structfield> | 701 | Drivers must set this field when <structfield>type</structfield> |
721 | refers to an input stream, applications when an output stream.</entry> | 702 | refers to an input stream, applications when it refers to an output stream.</entry> |
722 | </row> | 703 | </row> |
723 | <row> | 704 | <row> |
724 | <entry>__u32</entry> | 705 | <entry>__u32</entry> |
@@ -735,7 +716,7 @@ linkend="buffer-flags" />.</entry> | |||
735 | buffer, see <xref linkend="v4l2-field" />. This field is not used when | 716 | buffer, see <xref linkend="v4l2-field" />. This field is not used when |
736 | the buffer contains VBI data. Drivers must set it when | 717 | the buffer contains VBI data. Drivers must set it when |
737 | <structfield>type</structfield> refers to an input stream, | 718 | <structfield>type</structfield> refers to an input stream, |
738 | applications when an output stream.</entry> | 719 | applications when it refers to an output stream.</entry> |
739 | </row> | 720 | </row> |
740 | <row> | 721 | <row> |
741 | <entry>struct timeval</entry> | 722 | <entry>struct timeval</entry> |
@@ -745,15 +726,13 @@ applications when an output stream.</entry> | |||
745 | byte was captured, as returned by the | 726 | byte was captured, as returned by the |
746 | <function>clock_gettime()</function> function for the relevant | 727 | <function>clock_gettime()</function> function for the relevant |
747 | clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in | 728 | clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in |
748 | <xref linkend="buffer-flags" />. For output streams the data | 729 | <xref linkend="buffer-flags" />. For output streams the driver |
749 | will not be displayed before this time, secondary to the nominal | 730 | stores the time at which the last data byte was actually sent out |
750 | frame rate determined by the current video standard in enqueued | 731 | in the <structfield>timestamp</structfield> field. This permits |
751 | order. Applications can for example zero this field to display | ||
752 | frames as soon as possible. The driver stores the time at which | ||
753 | the first data byte was actually sent out in the | ||
754 | <structfield>timestamp</structfield> field. This permits | ||
755 | applications to monitor the drift between the video and system | 732 | applications to monitor the drift between the video and system |
756 | clock.</para></entry> | 733 | clock. For output streams that use <constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant> |
734 | the application has to fill in the timestamp which will be copied | ||
735 | by the driver to the capture stream.</para></entry> | ||
757 | </row> | 736 | </row> |
758 | <row> | 737 | <row> |
759 | <entry>&v4l2-timecode;</entry> | 738 | <entry>&v4l2-timecode;</entry> |
@@ -846,7 +825,8 @@ is the file descriptor associated with a DMABUF buffer.</entry> | |||
846 | <entry><structfield>length</structfield></entry> | 825 | <entry><structfield>length</structfield></entry> |
847 | <entry></entry> | 826 | <entry></entry> |
848 | <entry>Size of the buffer (not the payload) in bytes for the | 827 | <entry>Size of the buffer (not the payload) in bytes for the |
849 | single-planar API. For the multi-planar API the application sets | 828 | single-planar API. This is set by the driver based on the calls to |
829 | &VIDIOC-REQBUFS; and/or &VIDIOC-CREATE-BUFS;. For the multi-planar API the application sets | ||
850 | this to the number of elements in the <structfield>planes</structfield> | 830 | this to the number of elements in the <structfield>planes</structfield> |
851 | array. The driver will fill in the actual number of valid elements in | 831 | array. The driver will fill in the actual number of valid elements in |
852 | that array. | 832 | that array. |
@@ -880,13 +860,15 @@ should set this to 0.</entry> | |||
880 | <entry><structfield>bytesused</structfield></entry> | 860 | <entry><structfield>bytesused</structfield></entry> |
881 | <entry></entry> | 861 | <entry></entry> |
882 | <entry>The number of bytes occupied by data in the plane | 862 | <entry>The number of bytes occupied by data in the plane |
883 | (its payload).</entry> | 863 | (its payload). Drivers must set this field when <structfield>type</structfield> |
864 | refers to an input stream, applications when it refers to an output stream.</entry> | ||
884 | </row> | 865 | </row> |
885 | <row> | 866 | <row> |
886 | <entry>__u32</entry> | 867 | <entry>__u32</entry> |
887 | <entry><structfield>length</structfield></entry> | 868 | <entry><structfield>length</structfield></entry> |
888 | <entry></entry> | 869 | <entry></entry> |
889 | <entry>Size in bytes of the plane (not its payload).</entry> | 870 | <entry>Size in bytes of the plane (not its payload). This is set by the driver |
871 | based on the calls to &VIDIOC-REQBUFS; and/or &VIDIOC-CREATE-BUFS;.</entry> | ||
890 | </row> | 872 | </row> |
891 | <row> | 873 | <row> |
892 | <entry>union</entry> | 874 | <entry>union</entry> |
@@ -925,7 +907,9 @@ should set this to 0.</entry> | |||
925 | <entry>__u32</entry> | 907 | <entry>__u32</entry> |
926 | <entry><structfield>data_offset</structfield></entry> | 908 | <entry><structfield>data_offset</structfield></entry> |
927 | <entry></entry> | 909 | <entry></entry> |
928 | <entry>Offset in bytes to video data in the plane, if applicable. | 910 | <entry>Offset in bytes to video data in the plane. |
911 | Drivers must set this field when <structfield>type</structfield> | ||
912 | refers to an input stream, applications when it refers to an output stream. | ||
929 | </entry> | 913 | </entry> |
930 | </row> | 914 | </row> |
931 | <row> | 915 | <row> |
@@ -1005,6 +989,12 @@ should set this to 0.</entry> | |||
1005 | <entry>Buffer for video output overlay (OSD), see <xref | 989 | <entry>Buffer for video output overlay (OSD), see <xref |
1006 | linkend="osd" />.</entry> | 990 | linkend="osd" />.</entry> |
1007 | </row> | 991 | </row> |
992 | <row> | ||
993 | <entry><constant>V4L2_BUF_TYPE_SDR_CAPTURE</constant></entry> | ||
994 | <entry>11</entry> | ||
995 | <entry>Buffer for Software Defined Radio (SDR), see <xref | ||
996 | linkend="sdr" />.</entry> | ||
997 | </row> | ||
1008 | </tbody> | 998 | </tbody> |
1009 | </tgroup> | 999 | </tgroup> |
1010 | </table> | 1000 | </table> |
@@ -1016,7 +1006,7 @@ should set this to 0.</entry> | |||
1016 | <tbody valign="top"> | 1006 | <tbody valign="top"> |
1017 | <row> | 1007 | <row> |
1018 | <entry><constant>V4L2_BUF_FLAG_MAPPED</constant></entry> | 1008 | <entry><constant>V4L2_BUF_FLAG_MAPPED</constant></entry> |
1019 | <entry>0x0001</entry> | 1009 | <entry>0x00000001</entry> |
1020 | <entry>The buffer resides in device memory and has been mapped | 1010 | <entry>The buffer resides in device memory and has been mapped |
1021 | into the application's address space, see <xref linkend="mmap" /> for details. | 1011 | into the application's address space, see <xref linkend="mmap" /> for details. |
1022 | Drivers set or clear this flag when the | 1012 | Drivers set or clear this flag when the |
@@ -1026,7 +1016,7 @@ Drivers set or clear this flag when the | |||
1026 | </row> | 1016 | </row> |
1027 | <row> | 1017 | <row> |
1028 | <entry><constant>V4L2_BUF_FLAG_QUEUED</constant></entry> | 1018 | <entry><constant>V4L2_BUF_FLAG_QUEUED</constant></entry> |
1029 | <entry>0x0002</entry> | 1019 | <entry>0x00000002</entry> |
1030 | <entry>Internally drivers maintain two buffer queues, an | 1020 | <entry>Internally drivers maintain two buffer queues, an |
1031 | incoming and outgoing queue. When this flag is set, the buffer is | 1021 | incoming and outgoing queue. When this flag is set, the buffer is |
1032 | currently on the incoming queue. It automatically moves to the | 1022 | currently on the incoming queue. It automatically moves to the |
@@ -1039,7 +1029,7 @@ cleared.</entry> | |||
1039 | </row> | 1029 | </row> |
1040 | <row> | 1030 | <row> |
1041 | <entry><constant>V4L2_BUF_FLAG_DONE</constant></entry> | 1031 | <entry><constant>V4L2_BUF_FLAG_DONE</constant></entry> |
1042 | <entry>0x0004</entry> | 1032 | <entry>0x00000004</entry> |
1043 | <entry>When this flag is set, the buffer is currently on | 1033 | <entry>When this flag is set, the buffer is currently on |
1044 | the outgoing queue, ready to be dequeued from the driver. Drivers set | 1034 | the outgoing queue, ready to be dequeued from the driver. Drivers set |
1045 | or clear this flag when the <constant>VIDIOC_QUERYBUF</constant> ioctl | 1035 | or clear this flag when the <constant>VIDIOC_QUERYBUF</constant> ioctl |
@@ -1049,11 +1039,11 @@ buffer cannot be on both queues at the same time, the | |||
1049 | <constant>V4L2_BUF_FLAG_QUEUED</constant> and | 1039 | <constant>V4L2_BUF_FLAG_QUEUED</constant> and |
1050 | <constant>V4L2_BUF_FLAG_DONE</constant> flag are mutually exclusive. | 1040 | <constant>V4L2_BUF_FLAG_DONE</constant> flag are mutually exclusive. |
1051 | They can be both cleared however, then the buffer is in "dequeued" | 1041 | They can be both cleared however, then the buffer is in "dequeued" |
1052 | state, in the application domain to say so.</entry> | 1042 | state, in the application domain so to say.</entry> |
1053 | </row> | 1043 | </row> |
1054 | <row> | 1044 | <row> |
1055 | <entry><constant>V4L2_BUF_FLAG_ERROR</constant></entry> | 1045 | <entry><constant>V4L2_BUF_FLAG_ERROR</constant></entry> |
1056 | <entry>0x0040</entry> | 1046 | <entry>0x00000040</entry> |
1057 | <entry>When this flag is set, the buffer has been dequeued | 1047 | <entry>When this flag is set, the buffer has been dequeued |
1058 | successfully, although the data might have been corrupted. | 1048 | successfully, although the data might have been corrupted. |
1059 | This is recoverable, streaming may continue as normal and | 1049 | This is recoverable, streaming may continue as normal and |
@@ -1063,35 +1053,43 @@ state, in the application domain to say so.</entry> | |||
1063 | </row> | 1053 | </row> |
1064 | <row> | 1054 | <row> |
1065 | <entry><constant>V4L2_BUF_FLAG_KEYFRAME</constant></entry> | 1055 | <entry><constant>V4L2_BUF_FLAG_KEYFRAME</constant></entry> |
1066 | <entry>0x0008</entry> | 1056 | <entry>0x00000008</entry> |
1067 | <entry>Drivers set or clear this flag when calling the | 1057 | <entry>Drivers set or clear this flag when calling the |
1068 | <constant>VIDIOC_DQBUF</constant> ioctl. It may be set by video | 1058 | <constant>VIDIOC_DQBUF</constant> ioctl. It may be set by video |
1069 | capture devices when the buffer contains a compressed image which is a | 1059 | capture devices when the buffer contains a compressed image which is a |
1070 | key frame (or field), &ie; can be decompressed on its own.</entry> | 1060 | key frame (or field), &ie; can be decompressed on its own. Also know as |
1061 | an I-frame. Applications can set this bit when <structfield>type</structfield> | ||
1062 | refers to an output stream.</entry> | ||
1071 | </row> | 1063 | </row> |
1072 | <row> | 1064 | <row> |
1073 | <entry><constant>V4L2_BUF_FLAG_PFRAME</constant></entry> | 1065 | <entry><constant>V4L2_BUF_FLAG_PFRAME</constant></entry> |
1074 | <entry>0x0010</entry> | 1066 | <entry>0x00000010</entry> |
1075 | <entry>Similar to <constant>V4L2_BUF_FLAG_KEYFRAME</constant> | 1067 | <entry>Similar to <constant>V4L2_BUF_FLAG_KEYFRAME</constant> |
1076 | this flags predicted frames or fields which contain only differences to a | 1068 | this flags predicted frames or fields which contain only differences to a |
1077 | previous key frame.</entry> | 1069 | previous key frame. Applications can set this bit when <structfield>type</structfield> |
1070 | refers to an output stream.</entry> | ||
1078 | </row> | 1071 | </row> |
1079 | <row> | 1072 | <row> |
1080 | <entry><constant>V4L2_BUF_FLAG_BFRAME</constant></entry> | 1073 | <entry><constant>V4L2_BUF_FLAG_BFRAME</constant></entry> |
1081 | <entry>0x0020</entry> | 1074 | <entry>0x00000020</entry> |
1082 | <entry>Similar to <constant>V4L2_BUF_FLAG_PFRAME</constant> | 1075 | <entry>Similar to <constant>V4L2_BUF_FLAG_KEYFRAME</constant> |
1083 | this is a bidirectional predicted frame or field. [ooc tbd]</entry> | 1076 | this flags a bi-directional predicted frame or field which contains only |
1077 | the differences between the current frame and both the preceding and following | ||
1078 | key frames to specify its content. Applications can set this bit when | ||
1079 | <structfield>type</structfield> refers to an output stream.</entry> | ||
1084 | </row> | 1080 | </row> |
1085 | <row> | 1081 | <row> |
1086 | <entry><constant>V4L2_BUF_FLAG_TIMECODE</constant></entry> | 1082 | <entry><constant>V4L2_BUF_FLAG_TIMECODE</constant></entry> |
1087 | <entry>0x0100</entry> | 1083 | <entry>0x00000100</entry> |
1088 | <entry>The <structfield>timecode</structfield> field is valid. | 1084 | <entry>The <structfield>timecode</structfield> field is valid. |
1089 | Drivers set or clear this flag when the <constant>VIDIOC_DQBUF</constant> | 1085 | Drivers set or clear this flag when the <constant>VIDIOC_DQBUF</constant> |
1090 | ioctl is called.</entry> | 1086 | ioctl is called. Applications can set this bit and the corresponding |
1087 | <structfield>timecode</structfield> structure when <structfield>type</structfield> | ||
1088 | refers to an output stream.</entry> | ||
1091 | </row> | 1089 | </row> |
1092 | <row> | 1090 | <row> |
1093 | <entry><constant>V4L2_BUF_FLAG_PREPARED</constant></entry> | 1091 | <entry><constant>V4L2_BUF_FLAG_PREPARED</constant></entry> |
1094 | <entry>0x0400</entry> | 1092 | <entry>0x00000400</entry> |
1095 | <entry>The buffer has been prepared for I/O and can be queued by the | 1093 | <entry>The buffer has been prepared for I/O and can be queued by the |
1096 | application. Drivers set or clear this flag when the | 1094 | application. Drivers set or clear this flag when the |
1097 | <link linkend="vidioc-querybuf">VIDIOC_QUERYBUF</link>, <link | 1095 | <link linkend="vidioc-querybuf">VIDIOC_QUERYBUF</link>, <link |
@@ -1101,7 +1099,7 @@ application. Drivers set or clear this flag when the | |||
1101 | </row> | 1099 | </row> |
1102 | <row> | 1100 | <row> |
1103 | <entry><constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant></entry> | 1101 | <entry><constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant></entry> |
1104 | <entry>0x0800</entry> | 1102 | <entry>0x00000800</entry> |
1105 | <entry>Caches do not have to be invalidated for this buffer. | 1103 | <entry>Caches do not have to be invalidated for this buffer. |
1106 | Typically applications shall use this flag if the data captured in the buffer | 1104 | Typically applications shall use this flag if the data captured in the buffer |
1107 | is not going to be touched by the CPU, instead the buffer will, probably, be | 1105 | is not going to be touched by the CPU, instead the buffer will, probably, be |
@@ -1110,7 +1108,7 @@ passed on to a DMA-capable hardware unit for further processing or output. | |||
1110 | </row> | 1108 | </row> |
1111 | <row> | 1109 | <row> |
1112 | <entry><constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant></entry> | 1110 | <entry><constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant></entry> |
1113 | <entry>0x1000</entry> | 1111 | <entry>0x00001000</entry> |
1114 | <entry>Caches do not have to be cleaned for this buffer. | 1112 | <entry>Caches do not have to be cleaned for this buffer. |
1115 | Typically applications shall use this flag for output buffers if the data | 1113 | Typically applications shall use this flag for output buffers if the data |
1116 | in this buffer has not been created by the CPU but by some DMA-capable unit, | 1114 | in this buffer has not been created by the CPU but by some DMA-capable unit, |
@@ -1118,7 +1116,7 @@ in which case caches have not been used.</entry> | |||
1118 | </row> | 1116 | </row> |
1119 | <row> | 1117 | <row> |
1120 | <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry> | 1118 | <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry> |
1121 | <entry>0xe000</entry> | 1119 | <entry>0x0000e000</entry> |
1122 | <entry>Mask for timestamp types below. To test the | 1120 | <entry>Mask for timestamp types below. To test the |
1123 | timestamp type, mask out bits not belonging to timestamp | 1121 | timestamp type, mask out bits not belonging to timestamp |
1124 | type by performing a logical and operation with buffer | 1122 | type by performing a logical and operation with buffer |
@@ -1126,7 +1124,7 @@ in which case caches have not been used.</entry> | |||
1126 | </row> | 1124 | </row> |
1127 | <row> | 1125 | <row> |
1128 | <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry> | 1126 | <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry> |
1129 | <entry>0x0000</entry> | 1127 | <entry>0x00000000</entry> |
1130 | <entry>Unknown timestamp type. This type is used by | 1128 | <entry>Unknown timestamp type. This type is used by |
1131 | drivers before Linux 3.9 and may be either monotonic (see | 1129 | drivers before Linux 3.9 and may be either monotonic (see |
1132 | below) or realtime (wall clock). Monotonic clock has been | 1130 | below) or realtime (wall clock). Monotonic clock has been |
@@ -1139,7 +1137,7 @@ in which case caches have not been used.</entry> | |||
1139 | </row> | 1137 | </row> |
1140 | <row> | 1138 | <row> |
1141 | <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry> | 1139 | <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry> |
1142 | <entry>0x2000</entry> | 1140 | <entry>0x00002000</entry> |
1143 | <entry>The buffer timestamp has been taken from the | 1141 | <entry>The buffer timestamp has been taken from the |
1144 | <constant>CLOCK_MONOTONIC</constant> clock. To access the | 1142 | <constant>CLOCK_MONOTONIC</constant> clock. To access the |
1145 | same clock outside V4L2, use | 1143 | same clock outside V4L2, use |
@@ -1147,10 +1145,42 @@ in which case caches have not been used.</entry> | |||
1147 | </row> | 1145 | </row> |
1148 | <row> | 1146 | <row> |
1149 | <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant></entry> | 1147 | <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant></entry> |
1150 | <entry>0x4000</entry> | 1148 | <entry>0x00004000</entry> |
1151 | <entry>The CAPTURE buffer timestamp has been taken from the | 1149 | <entry>The CAPTURE buffer timestamp has been taken from the |
1152 | corresponding OUTPUT buffer. This flag applies only to mem2mem devices.</entry> | 1150 | corresponding OUTPUT buffer. This flag applies only to mem2mem devices.</entry> |
1153 | </row> | 1151 | </row> |
1152 | <row> | ||
1153 | <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant></entry> | ||
1154 | <entry>0x00070000</entry> | ||
1155 | <entry>Mask for timestamp sources below. The timestamp source | ||
1156 | defines the point of time the timestamp is taken in relation to | ||
1157 | the frame. Logical 'and' operation between the | ||
1158 | <structfield>flags</structfield> field and | ||
1159 | <constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> produces the | ||
1160 | value of the timestamp source. Applications must set the timestamp | ||
1161 | source when <structfield>type</structfield> refers to an output stream | ||
1162 | and <constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant> is set.</entry> | ||
1163 | </row> | ||
1164 | <row> | ||
1165 | <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_EOF</constant></entry> | ||
1166 | <entry>0x00000000</entry> | ||
1167 | <entry>End Of Frame. The buffer timestamp has been taken | ||
1168 | when the last pixel of the frame has been received or the | ||
1169 | last pixel of the frame has been transmitted. In practice, | ||
1170 | software generated timestamps will typically be read from | ||
1171 | the clock a small amount of time after the last pixel has | ||
1172 | been received or transmitten, depending on the system and | ||
1173 | other activity in it.</entry> | ||
1174 | </row> | ||
1175 | <row> | ||
1176 | <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_SOE</constant></entry> | ||
1177 | <entry>0x00010000</entry> | ||
1178 | <entry>Start Of Exposure. The buffer timestamp has been | ||
1179 | taken when the exposure of the frame has begun. This is | ||
1180 | only valid for the | ||
1181 | <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> buffer | ||
1182 | type.</entry> | ||
1183 | </row> | ||
1154 | </tbody> | 1184 | </tbody> |
1155 | </tgroup> | 1185 | </tgroup> |
1156 | </table> | 1186 | </table> |
@@ -1440,10 +1470,9 @@ or application, depending on data direction, must set &v4l2-buffer; | |||
1440 | <constant>V4L2_FIELD_BOTTOM</constant>. Any two successive fields pair | 1470 | <constant>V4L2_FIELD_BOTTOM</constant>. Any two successive fields pair |
1441 | to build a frame. If fields are successive, without any dropped fields | 1471 | to build a frame. If fields are successive, without any dropped fields |
1442 | between them (fields can drop individually), can be determined from | 1472 | between them (fields can drop individually), can be determined from |
1443 | the &v4l2-buffer; <structfield>sequence</structfield> field. Image | 1473 | the &v4l2-buffer; <structfield>sequence</structfield> field. This format |
1444 | sizes refer to the frame, not fields. This format cannot be selected | 1474 | cannot be selected when using the read/write I/O method since there |
1445 | when using the read/write I/O method.<!-- Where it's indistinguishable | 1475 | is no way to communicate if a field was a top or bottom field.</entry> |
1446 | from V4L2_FIELD_SEQ_*. --></entry> | ||
1447 | </row> | 1476 | </row> |
1448 | <row> | 1477 | <row> |
1449 | <entry><constant>V4L2_FIELD_INTERLACED_TB</constant></entry> | 1478 | <entry><constant>V4L2_FIELD_INTERLACED_TB</constant></entry> |
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml index c51d5a4cda09..fb2b5e35d665 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | |||
@@ -12,18 +12,17 @@ | |||
12 | <refsect1> | 12 | <refsect1> |
13 | <title>Description</title> | 13 | <title>Description</title> |
14 | 14 | ||
15 | <para>This is a multi-planar, two-plane version of the YUV 4:2:0 format. | 15 | <para>This is a multi-planar, two-plane version of the YUV 4:2:2 format. |
16 | The three components are separated into two sub-images or planes. | 16 | The three components are separated into two sub-images or planes. |
17 | <constant>V4L2_PIX_FMT_NV16M</constant> differs from <constant>V4L2_PIX_FMT_NV16 | 17 | <constant>V4L2_PIX_FMT_NV16M</constant> differs from <constant>V4L2_PIX_FMT_NV16 |
18 | </constant> in that the two planes are non-contiguous in memory, i.e. the chroma | 18 | </constant> in that the two planes are non-contiguous in memory, i.e. the chroma |
19 | plane does not necessarily immediately follows the luma plane. | 19 | plane does not necessarily immediately follow the luma plane. |
20 | The luminance data occupies the first plane. The Y plane has one byte per pixel. | 20 | The luminance data occupies the first plane. The Y plane has one byte per pixel. |
21 | In the second plane there is chrominance data with alternating chroma samples. | 21 | In the second plane there is chrominance data with alternating chroma samples. |
22 | The CbCr plane is the same width and height, in bytes, as the Y plane. | 22 | The CbCr plane is the same width and height, in bytes, as the Y plane. |
23 | Each CbCr pair belongs to four pixels. For example, | 23 | Each CbCr pair belongs to two pixels. For example, |
24 | Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to | 24 | Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to |
25 | Y'<subscript>00</subscript>, Y'<subscript>01</subscript>, | 25 | Y'<subscript>00</subscript>, Y'<subscript>01</subscript>. |
26 | Y'<subscript>10</subscript>, Y'<subscript>11</subscript>. | ||
27 | <constant>V4L2_PIX_FMT_NV61M</constant> is the same as <constant>V4L2_PIX_FMT_NV16M</constant> | 26 | <constant>V4L2_PIX_FMT_NV61M</constant> is the same as <constant>V4L2_PIX_FMT_NV16M</constant> |
28 | except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte.</para> | 27 | except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte.</para> |
29 | 28 | ||
diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml index 166c8d65e4f7..e1c4f8b4c0b3 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml | |||
@@ -121,14 +121,14 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> | |||
121 | <entry><constant>V4L2_PIX_FMT_RGB332</constant></entry> | 121 | <entry><constant>V4L2_PIX_FMT_RGB332</constant></entry> |
122 | <entry>'RGB1'</entry> | 122 | <entry>'RGB1'</entry> |
123 | <entry></entry> | 123 | <entry></entry> |
124 | <entry>b<subscript>1</subscript></entry> | ||
125 | <entry>b<subscript>0</subscript></entry> | ||
126 | <entry>g<subscript>2</subscript></entry> | ||
127 | <entry>g<subscript>1</subscript></entry> | ||
128 | <entry>g<subscript>0</subscript></entry> | ||
129 | <entry>r<subscript>2</subscript></entry> | 124 | <entry>r<subscript>2</subscript></entry> |
130 | <entry>r<subscript>1</subscript></entry> | 125 | <entry>r<subscript>1</subscript></entry> |
131 | <entry>r<subscript>0</subscript></entry> | 126 | <entry>r<subscript>0</subscript></entry> |
127 | <entry>g<subscript>2</subscript></entry> | ||
128 | <entry>g<subscript>1</subscript></entry> | ||
129 | <entry>g<subscript>0</subscript></entry> | ||
130 | <entry>b<subscript>1</subscript></entry> | ||
131 | <entry>b<subscript>0</subscript></entry> | ||
132 | </row> | 132 | </row> |
133 | <row id="V4L2-PIX-FMT-RGB444"> | 133 | <row id="V4L2-PIX-FMT-RGB444"> |
134 | <entry><constant>V4L2_PIX_FMT_RGB444</constant></entry> | 134 | <entry><constant>V4L2_PIX_FMT_RGB444</constant></entry> |
@@ -159,18 +159,18 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> | |||
159 | <entry>g<subscript>2</subscript></entry> | 159 | <entry>g<subscript>2</subscript></entry> |
160 | <entry>g<subscript>1</subscript></entry> | 160 | <entry>g<subscript>1</subscript></entry> |
161 | <entry>g<subscript>0</subscript></entry> | 161 | <entry>g<subscript>0</subscript></entry> |
162 | <entry>r<subscript>4</subscript></entry> | ||
163 | <entry>r<subscript>3</subscript></entry> | ||
164 | <entry>r<subscript>2</subscript></entry> | ||
165 | <entry>r<subscript>1</subscript></entry> | ||
166 | <entry>r<subscript>0</subscript></entry> | ||
167 | <entry></entry> | ||
168 | <entry>a</entry> | ||
169 | <entry>b<subscript>4</subscript></entry> | 162 | <entry>b<subscript>4</subscript></entry> |
170 | <entry>b<subscript>3</subscript></entry> | 163 | <entry>b<subscript>3</subscript></entry> |
171 | <entry>b<subscript>2</subscript></entry> | 164 | <entry>b<subscript>2</subscript></entry> |
172 | <entry>b<subscript>1</subscript></entry> | 165 | <entry>b<subscript>1</subscript></entry> |
173 | <entry>b<subscript>0</subscript></entry> | 166 | <entry>b<subscript>0</subscript></entry> |
167 | <entry></entry> | ||
168 | <entry>a</entry> | ||
169 | <entry>r<subscript>4</subscript></entry> | ||
170 | <entry>r<subscript>3</subscript></entry> | ||
171 | <entry>r<subscript>2</subscript></entry> | ||
172 | <entry>r<subscript>1</subscript></entry> | ||
173 | <entry>r<subscript>0</subscript></entry> | ||
174 | <entry>g<subscript>4</subscript></entry> | 174 | <entry>g<subscript>4</subscript></entry> |
175 | <entry>g<subscript>3</subscript></entry> | 175 | <entry>g<subscript>3</subscript></entry> |
176 | </row> | 176 | </row> |
@@ -181,17 +181,17 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> | |||
181 | <entry>g<subscript>2</subscript></entry> | 181 | <entry>g<subscript>2</subscript></entry> |
182 | <entry>g<subscript>1</subscript></entry> | 182 | <entry>g<subscript>1</subscript></entry> |
183 | <entry>g<subscript>0</subscript></entry> | 183 | <entry>g<subscript>0</subscript></entry> |
184 | <entry>r<subscript>4</subscript></entry> | ||
185 | <entry>r<subscript>3</subscript></entry> | ||
186 | <entry>r<subscript>2</subscript></entry> | ||
187 | <entry>r<subscript>1</subscript></entry> | ||
188 | <entry>r<subscript>0</subscript></entry> | ||
189 | <entry></entry> | ||
190 | <entry>b<subscript>4</subscript></entry> | 184 | <entry>b<subscript>4</subscript></entry> |
191 | <entry>b<subscript>3</subscript></entry> | 185 | <entry>b<subscript>3</subscript></entry> |
192 | <entry>b<subscript>2</subscript></entry> | 186 | <entry>b<subscript>2</subscript></entry> |
193 | <entry>b<subscript>1</subscript></entry> | 187 | <entry>b<subscript>1</subscript></entry> |
194 | <entry>b<subscript>0</subscript></entry> | 188 | <entry>b<subscript>0</subscript></entry> |
189 | <entry></entry> | ||
190 | <entry>r<subscript>4</subscript></entry> | ||
191 | <entry>r<subscript>3</subscript></entry> | ||
192 | <entry>r<subscript>2</subscript></entry> | ||
193 | <entry>r<subscript>1</subscript></entry> | ||
194 | <entry>r<subscript>0</subscript></entry> | ||
195 | <entry>g<subscript>5</subscript></entry> | 195 | <entry>g<subscript>5</subscript></entry> |
196 | <entry>g<subscript>4</subscript></entry> | 196 | <entry>g<subscript>4</subscript></entry> |
197 | <entry>g<subscript>3</subscript></entry> | 197 | <entry>g<subscript>3</subscript></entry> |
@@ -201,32 +201,32 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> | |||
201 | <entry>'RGBQ'</entry> | 201 | <entry>'RGBQ'</entry> |
202 | <entry></entry> | 202 | <entry></entry> |
203 | <entry>a</entry> | 203 | <entry>a</entry> |
204 | <entry>b<subscript>4</subscript></entry> | ||
205 | <entry>b<subscript>3</subscript></entry> | ||
206 | <entry>b<subscript>2</subscript></entry> | ||
207 | <entry>b<subscript>1</subscript></entry> | ||
208 | <entry>b<subscript>0</subscript></entry> | ||
209 | <entry>g<subscript>4</subscript></entry> | ||
210 | <entry>g<subscript>3</subscript></entry> | ||
211 | <entry></entry> | ||
212 | <entry>g<subscript>2</subscript></entry> | ||
213 | <entry>g<subscript>1</subscript></entry> | ||
214 | <entry>g<subscript>0</subscript></entry> | ||
215 | <entry>r<subscript>4</subscript></entry> | 204 | <entry>r<subscript>4</subscript></entry> |
216 | <entry>r<subscript>3</subscript></entry> | 205 | <entry>r<subscript>3</subscript></entry> |
217 | <entry>r<subscript>2</subscript></entry> | 206 | <entry>r<subscript>2</subscript></entry> |
218 | <entry>r<subscript>1</subscript></entry> | 207 | <entry>r<subscript>1</subscript></entry> |
219 | <entry>r<subscript>0</subscript></entry> | 208 | <entry>r<subscript>0</subscript></entry> |
220 | </row> | 209 | <entry>g<subscript>4</subscript></entry> |
221 | <row id="V4L2-PIX-FMT-RGB565X"> | 210 | <entry>g<subscript>3</subscript></entry> |
222 | <entry><constant>V4L2_PIX_FMT_RGB565X</constant></entry> | ||
223 | <entry>'RGBR'</entry> | ||
224 | <entry></entry> | 211 | <entry></entry> |
212 | <entry>g<subscript>2</subscript></entry> | ||
213 | <entry>g<subscript>1</subscript></entry> | ||
214 | <entry>g<subscript>0</subscript></entry> | ||
225 | <entry>b<subscript>4</subscript></entry> | 215 | <entry>b<subscript>4</subscript></entry> |
226 | <entry>b<subscript>3</subscript></entry> | 216 | <entry>b<subscript>3</subscript></entry> |
227 | <entry>b<subscript>2</subscript></entry> | 217 | <entry>b<subscript>2</subscript></entry> |
228 | <entry>b<subscript>1</subscript></entry> | 218 | <entry>b<subscript>1</subscript></entry> |
229 | <entry>b<subscript>0</subscript></entry> | 219 | <entry>b<subscript>0</subscript></entry> |
220 | </row> | ||
221 | <row id="V4L2-PIX-FMT-RGB565X"> | ||
222 | <entry><constant>V4L2_PIX_FMT_RGB565X</constant></entry> | ||
223 | <entry>'RGBR'</entry> | ||
224 | <entry></entry> | ||
225 | <entry>r<subscript>4</subscript></entry> | ||
226 | <entry>r<subscript>3</subscript></entry> | ||
227 | <entry>r<subscript>2</subscript></entry> | ||
228 | <entry>r<subscript>1</subscript></entry> | ||
229 | <entry>r<subscript>0</subscript></entry> | ||
230 | <entry>g<subscript>5</subscript></entry> | 230 | <entry>g<subscript>5</subscript></entry> |
231 | <entry>g<subscript>4</subscript></entry> | 231 | <entry>g<subscript>4</subscript></entry> |
232 | <entry>g<subscript>3</subscript></entry> | 232 | <entry>g<subscript>3</subscript></entry> |
@@ -234,11 +234,11 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> | |||
234 | <entry>g<subscript>2</subscript></entry> | 234 | <entry>g<subscript>2</subscript></entry> |
235 | <entry>g<subscript>1</subscript></entry> | 235 | <entry>g<subscript>1</subscript></entry> |
236 | <entry>g<subscript>0</subscript></entry> | 236 | <entry>g<subscript>0</subscript></entry> |
237 | <entry>r<subscript>4</subscript></entry> | 237 | <entry>b<subscript>4</subscript></entry> |
238 | <entry>r<subscript>3</subscript></entry> | 238 | <entry>b<subscript>3</subscript></entry> |
239 | <entry>r<subscript>2</subscript></entry> | 239 | <entry>b<subscript>2</subscript></entry> |
240 | <entry>r<subscript>1</subscript></entry> | 240 | <entry>b<subscript>1</subscript></entry> |
241 | <entry>r<subscript>0</subscript></entry> | 241 | <entry>b<subscript>0</subscript></entry> |
242 | </row> | 242 | </row> |
243 | <row id="V4L2-PIX-FMT-BGR666"> | 243 | <row id="V4L2-PIX-FMT-BGR666"> |
244 | <entry><constant>V4L2_PIX_FMT_BGR666</constant></entry> | 244 | <entry><constant>V4L2_PIX_FMT_BGR666</constant></entry> |
@@ -385,6 +385,15 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> | |||
385 | <entry><constant>V4L2_PIX_FMT_RGB32</constant></entry> | 385 | <entry><constant>V4L2_PIX_FMT_RGB32</constant></entry> |
386 | <entry>'RGB4'</entry> | 386 | <entry>'RGB4'</entry> |
387 | <entry></entry> | 387 | <entry></entry> |
388 | <entry>a<subscript>7</subscript></entry> | ||
389 | <entry>a<subscript>6</subscript></entry> | ||
390 | <entry>a<subscript>5</subscript></entry> | ||
391 | <entry>a<subscript>4</subscript></entry> | ||
392 | <entry>a<subscript>3</subscript></entry> | ||
393 | <entry>a<subscript>2</subscript></entry> | ||
394 | <entry>a<subscript>1</subscript></entry> | ||
395 | <entry>a<subscript>0</subscript></entry> | ||
396 | <entry></entry> | ||
388 | <entry>r<subscript>7</subscript></entry> | 397 | <entry>r<subscript>7</subscript></entry> |
389 | <entry>r<subscript>6</subscript></entry> | 398 | <entry>r<subscript>6</subscript></entry> |
390 | <entry>r<subscript>5</subscript></entry> | 399 | <entry>r<subscript>5</subscript></entry> |
@@ -411,25 +420,16 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> | |||
411 | <entry>b<subscript>2</subscript></entry> | 420 | <entry>b<subscript>2</subscript></entry> |
412 | <entry>b<subscript>1</subscript></entry> | 421 | <entry>b<subscript>1</subscript></entry> |
413 | <entry>b<subscript>0</subscript></entry> | 422 | <entry>b<subscript>0</subscript></entry> |
414 | <entry></entry> | ||
415 | <entry>a<subscript>7</subscript></entry> | ||
416 | <entry>a<subscript>6</subscript></entry> | ||
417 | <entry>a<subscript>5</subscript></entry> | ||
418 | <entry>a<subscript>4</subscript></entry> | ||
419 | <entry>a<subscript>3</subscript></entry> | ||
420 | <entry>a<subscript>2</subscript></entry> | ||
421 | <entry>a<subscript>1</subscript></entry> | ||
422 | <entry>a<subscript>0</subscript></entry> | ||
423 | </row> | 423 | </row> |
424 | </tbody> | 424 | </tbody> |
425 | </tgroup> | 425 | </tgroup> |
426 | </table> | 426 | </table> |
427 | 427 | ||
428 | <para>Bit 7 is the most significant bit. The value of a = alpha | 428 | <para>Bit 7 is the most significant bit. The value of the a = alpha |
429 | bits is undefined when reading from the driver, ignored when writing | 429 | bits is undefined when reading from the driver, ignored when writing |
430 | to the driver, except when alpha blending has been negotiated for a | 430 | to the driver, except when alpha blending has been negotiated for a |
431 | <link linkend="overlay">Video Overlay</link> or <link linkend="osd"> | 431 | <link linkend="overlay">Video Overlay</link> or <link linkend="osd"> |
432 | Video Output Overlay</link> or when alpha component has been configured | 432 | Video Output Overlay</link> or when the alpha component has been configured |
433 | for a <link linkend="capture">Video Capture</link> by means of <link | 433 | for a <link linkend="capture">Video Capture</link> by means of <link |
434 | linkend="v4l2-alpha-component"> <constant>V4L2_CID_ALPHA_COMPONENT | 434 | linkend="v4l2-alpha-component"> <constant>V4L2_CID_ALPHA_COMPONENT |
435 | </constant> </link> control.</para> | 435 | </constant> </link> control.</para> |
@@ -512,421 +512,6 @@ image</title> | |||
512 | </formalpara> | 512 | </formalpara> |
513 | </example> | 513 | </example> |
514 | 514 | ||
515 | <important> | ||
516 | <para>Drivers may interpret these formats differently.</para> | ||
517 | </important> | ||
518 | |||
519 | <para>Some RGB formats above are uncommon and were probably | ||
520 | defined in error. Drivers may interpret them as in <xref | ||
521 | linkend="rgb-formats-corrected" />.</para> | ||
522 | |||
523 | <table pgwide="1" frame="none" id="rgb-formats-corrected"> | ||
524 | <title>Packed RGB Image Formats (corrected)</title> | ||
525 | <tgroup cols="37" align="center"> | ||
526 | <colspec colname="id" align="left" /> | ||
527 | <colspec colname="fourcc" /> | ||
528 | <colspec colname="bit" /> | ||
529 | |||
530 | <colspec colnum="4" colname="b07" align="center" /> | ||
531 | <colspec colnum="5" colname="b06" align="center" /> | ||
532 | <colspec colnum="6" colname="b05" align="center" /> | ||
533 | <colspec colnum="7" colname="b04" align="center" /> | ||
534 | <colspec colnum="8" colname="b03" align="center" /> | ||
535 | <colspec colnum="9" colname="b02" align="center" /> | ||
536 | <colspec colnum="10" colname="b01" align="center" /> | ||
537 | <colspec colnum="11" colname="b00" align="center" /> | ||
538 | |||
539 | <colspec colnum="13" colname="b17" align="center" /> | ||
540 | <colspec colnum="14" colname="b16" align="center" /> | ||
541 | <colspec colnum="15" colname="b15" align="center" /> | ||
542 | <colspec colnum="16" colname="b14" align="center" /> | ||
543 | <colspec colnum="17" colname="b13" align="center" /> | ||
544 | <colspec colnum="18" colname="b12" align="center" /> | ||
545 | <colspec colnum="19" colname="b11" align="center" /> | ||
546 | <colspec colnum="20" colname="b10" align="center" /> | ||
547 | |||
548 | <colspec colnum="22" colname="b27" align="center" /> | ||
549 | <colspec colnum="23" colname="b26" align="center" /> | ||
550 | <colspec colnum="24" colname="b25" align="center" /> | ||
551 | <colspec colnum="25" colname="b24" align="center" /> | ||
552 | <colspec colnum="26" colname="b23" align="center" /> | ||
553 | <colspec colnum="27" colname="b22" align="center" /> | ||
554 | <colspec colnum="28" colname="b21" align="center" /> | ||
555 | <colspec colnum="29" colname="b20" align="center" /> | ||
556 | |||
557 | <colspec colnum="31" colname="b37" align="center" /> | ||
558 | <colspec colnum="32" colname="b36" align="center" /> | ||
559 | <colspec colnum="33" colname="b35" align="center" /> | ||
560 | <colspec colnum="34" colname="b34" align="center" /> | ||
561 | <colspec colnum="35" colname="b33" align="center" /> | ||
562 | <colspec colnum="36" colname="b32" align="center" /> | ||
563 | <colspec colnum="37" colname="b31" align="center" /> | ||
564 | <colspec colnum="38" colname="b30" align="center" /> | ||
565 | |||
566 | <spanspec namest="b07" nameend="b00" spanname="b0" /> | ||
567 | <spanspec namest="b17" nameend="b10" spanname="b1" /> | ||
568 | <spanspec namest="b27" nameend="b20" spanname="b2" /> | ||
569 | <spanspec namest="b37" nameend="b30" spanname="b3" /> | ||
570 | <thead> | ||
571 | <row> | ||
572 | <entry>Identifier</entry> | ||
573 | <entry>Code</entry> | ||
574 | <entry> </entry> | ||
575 | <entry spanname="b0">Byte 0 in memory</entry> | ||
576 | <entry spanname="b1">Byte 1</entry> | ||
577 | <entry spanname="b2">Byte 2</entry> | ||
578 | <entry spanname="b3">Byte 3</entry> | ||
579 | </row> | ||
580 | <row> | ||
581 | <entry> </entry> | ||
582 | <entry> </entry> | ||
583 | <entry>Bit</entry> | ||
584 | <entry>7</entry> | ||
585 | <entry>6</entry> | ||
586 | <entry>5</entry> | ||
587 | <entry>4</entry> | ||
588 | <entry>3</entry> | ||
589 | <entry>2</entry> | ||
590 | <entry>1</entry> | ||
591 | <entry>0</entry> | ||
592 | <entry> </entry> | ||
593 | <entry>7</entry> | ||
594 | <entry>6</entry> | ||
595 | <entry>5</entry> | ||
596 | <entry>4</entry> | ||
597 | <entry>3</entry> | ||
598 | <entry>2</entry> | ||
599 | <entry>1</entry> | ||
600 | <entry>0</entry> | ||
601 | <entry> </entry> | ||
602 | <entry>7</entry> | ||
603 | <entry>6</entry> | ||
604 | <entry>5</entry> | ||
605 | <entry>4</entry> | ||
606 | <entry>3</entry> | ||
607 | <entry>2</entry> | ||
608 | <entry>1</entry> | ||
609 | <entry>0</entry> | ||
610 | <entry> </entry> | ||
611 | <entry>7</entry> | ||
612 | <entry>6</entry> | ||
613 | <entry>5</entry> | ||
614 | <entry>4</entry> | ||
615 | <entry>3</entry> | ||
616 | <entry>2</entry> | ||
617 | <entry>1</entry> | ||
618 | <entry>0</entry> | ||
619 | </row> | ||
620 | </thead> | ||
621 | <tbody valign="top"> | ||
622 | <row><!-- id="V4L2-PIX-FMT-RGB332" --> | ||
623 | <entry><constant>V4L2_PIX_FMT_RGB332</constant></entry> | ||
624 | <entry>'RGB1'</entry> | ||
625 | <entry></entry> | ||
626 | <entry>r<subscript>2</subscript></entry> | ||
627 | <entry>r<subscript>1</subscript></entry> | ||
628 | <entry>r<subscript>0</subscript></entry> | ||
629 | <entry>g<subscript>2</subscript></entry> | ||
630 | <entry>g<subscript>1</subscript></entry> | ||
631 | <entry>g<subscript>0</subscript></entry> | ||
632 | <entry>b<subscript>1</subscript></entry> | ||
633 | <entry>b<subscript>0</subscript></entry> | ||
634 | </row> | ||
635 | <row><!-- id="V4L2-PIX-FMT-RGB444" --> | ||
636 | <entry><constant>V4L2_PIX_FMT_RGB444</constant></entry> | ||
637 | <entry>'R444'</entry> | ||
638 | <entry></entry> | ||
639 | <entry>g<subscript>3</subscript></entry> | ||
640 | <entry>g<subscript>2</subscript></entry> | ||
641 | <entry>g<subscript>1</subscript></entry> | ||
642 | <entry>g<subscript>0</subscript></entry> | ||
643 | <entry>b<subscript>3</subscript></entry> | ||
644 | <entry>b<subscript>2</subscript></entry> | ||
645 | <entry>b<subscript>1</subscript></entry> | ||
646 | <entry>b<subscript>0</subscript></entry> | ||
647 | <entry></entry> | ||
648 | <entry>a<subscript>3</subscript></entry> | ||
649 | <entry>a<subscript>2</subscript></entry> | ||
650 | <entry>a<subscript>1</subscript></entry> | ||
651 | <entry>a<subscript>0</subscript></entry> | ||
652 | <entry>r<subscript>3</subscript></entry> | ||
653 | <entry>r<subscript>2</subscript></entry> | ||
654 | <entry>r<subscript>1</subscript></entry> | ||
655 | <entry>r<subscript>0</subscript></entry> | ||
656 | </row> | ||
657 | <row><!-- id="V4L2-PIX-FMT-RGB555" --> | ||
658 | <entry><constant>V4L2_PIX_FMT_RGB555</constant></entry> | ||
659 | <entry>'RGBO'</entry> | ||
660 | <entry></entry> | ||
661 | <entry>g<subscript>2</subscript></entry> | ||
662 | <entry>g<subscript>1</subscript></entry> | ||
663 | <entry>g<subscript>0</subscript></entry> | ||
664 | <entry>b<subscript>4</subscript></entry> | ||
665 | <entry>b<subscript>3</subscript></entry> | ||
666 | <entry>b<subscript>2</subscript></entry> | ||
667 | <entry>b<subscript>1</subscript></entry> | ||
668 | <entry>b<subscript>0</subscript></entry> | ||
669 | <entry></entry> | ||
670 | <entry>a</entry> | ||
671 | <entry>r<subscript>4</subscript></entry> | ||
672 | <entry>r<subscript>3</subscript></entry> | ||
673 | <entry>r<subscript>2</subscript></entry> | ||
674 | <entry>r<subscript>1</subscript></entry> | ||
675 | <entry>r<subscript>0</subscript></entry> | ||
676 | <entry>g<subscript>4</subscript></entry> | ||
677 | <entry>g<subscript>3</subscript></entry> | ||
678 | </row> | ||
679 | <row><!-- id="V4L2-PIX-FMT-RGB565" --> | ||
680 | <entry><constant>V4L2_PIX_FMT_RGB565</constant></entry> | ||
681 | <entry>'RGBP'</entry> | ||
682 | <entry></entry> | ||
683 | <entry>g<subscript>2</subscript></entry> | ||
684 | <entry>g<subscript>1</subscript></entry> | ||
685 | <entry>g<subscript>0</subscript></entry> | ||
686 | <entry>b<subscript>4</subscript></entry> | ||
687 | <entry>b<subscript>3</subscript></entry> | ||
688 | <entry>b<subscript>2</subscript></entry> | ||
689 | <entry>b<subscript>1</subscript></entry> | ||
690 | <entry>b<subscript>0</subscript></entry> | ||
691 | <entry></entry> | ||
692 | <entry>r<subscript>4</subscript></entry> | ||
693 | <entry>r<subscript>3</subscript></entry> | ||
694 | <entry>r<subscript>2</subscript></entry> | ||
695 | <entry>r<subscript>1</subscript></entry> | ||
696 | <entry>r<subscript>0</subscript></entry> | ||
697 | <entry>g<subscript>5</subscript></entry> | ||
698 | <entry>g<subscript>4</subscript></entry> | ||
699 | <entry>g<subscript>3</subscript></entry> | ||
700 | </row> | ||
701 | <row><!-- id="V4L2-PIX-FMT-RGB555X" --> | ||
702 | <entry><constant>V4L2_PIX_FMT_RGB555X</constant></entry> | ||
703 | <entry>'RGBQ'</entry> | ||
704 | <entry></entry> | ||
705 | <entry>a</entry> | ||
706 | <entry>r<subscript>4</subscript></entry> | ||
707 | <entry>r<subscript>3</subscript></entry> | ||
708 | <entry>r<subscript>2</subscript></entry> | ||
709 | <entry>r<subscript>1</subscript></entry> | ||
710 | <entry>r<subscript>0</subscript></entry> | ||
711 | <entry>g<subscript>4</subscript></entry> | ||
712 | <entry>g<subscript>3</subscript></entry> | ||
713 | <entry></entry> | ||
714 | <entry>g<subscript>2</subscript></entry> | ||
715 | <entry>g<subscript>1</subscript></entry> | ||
716 | <entry>g<subscript>0</subscript></entry> | ||
717 | <entry>b<subscript>4</subscript></entry> | ||
718 | <entry>b<subscript>3</subscript></entry> | ||
719 | <entry>b<subscript>2</subscript></entry> | ||
720 | <entry>b<subscript>1</subscript></entry> | ||
721 | <entry>b<subscript>0</subscript></entry> | ||
722 | </row> | ||
723 | <row><!-- id="V4L2-PIX-FMT-RGB565X" --> | ||
724 | <entry><constant>V4L2_PIX_FMT_RGB565X</constant></entry> | ||
725 | <entry>'RGBR'</entry> | ||
726 | <entry></entry> | ||
727 | <entry>r<subscript>4</subscript></entry> | ||
728 | <entry>r<subscript>3</subscript></entry> | ||
729 | <entry>r<subscript>2</subscript></entry> | ||
730 | <entry>r<subscript>1</subscript></entry> | ||
731 | <entry>r<subscript>0</subscript></entry> | ||
732 | <entry>g<subscript>5</subscript></entry> | ||
733 | <entry>g<subscript>4</subscript></entry> | ||
734 | <entry>g<subscript>3</subscript></entry> | ||
735 | <entry></entry> | ||
736 | <entry>g<subscript>2</subscript></entry> | ||
737 | <entry>g<subscript>1</subscript></entry> | ||
738 | <entry>g<subscript>0</subscript></entry> | ||
739 | <entry>b<subscript>4</subscript></entry> | ||
740 | <entry>b<subscript>3</subscript></entry> | ||
741 | <entry>b<subscript>2</subscript></entry> | ||
742 | <entry>b<subscript>1</subscript></entry> | ||
743 | <entry>b<subscript>0</subscript></entry> | ||
744 | </row> | ||
745 | <row><!-- id="V4L2-PIX-FMT-BGR666" --> | ||
746 | <entry><constant>V4L2_PIX_FMT_BGR666</constant></entry> | ||
747 | <entry>'BGRH'</entry> | ||
748 | <entry></entry> | ||
749 | <entry>b<subscript>5</subscript></entry> | ||
750 | <entry>b<subscript>4</subscript></entry> | ||
751 | <entry>b<subscript>3</subscript></entry> | ||
752 | <entry>b<subscript>2</subscript></entry> | ||
753 | <entry>b<subscript>1</subscript></entry> | ||
754 | <entry>b<subscript>0</subscript></entry> | ||
755 | <entry>g<subscript>5</subscript></entry> | ||
756 | <entry>g<subscript>4</subscript></entry> | ||
757 | <entry></entry> | ||
758 | <entry>g<subscript>3</subscript></entry> | ||
759 | <entry>g<subscript>2</subscript></entry> | ||
760 | <entry>g<subscript>1</subscript></entry> | ||
761 | <entry>g<subscript>0</subscript></entry> | ||
762 | <entry>r<subscript>5</subscript></entry> | ||
763 | <entry>r<subscript>4</subscript></entry> | ||
764 | <entry>r<subscript>3</subscript></entry> | ||
765 | <entry>r<subscript>2</subscript></entry> | ||
766 | <entry></entry> | ||
767 | <entry>r<subscript>1</subscript></entry> | ||
768 | <entry>r<subscript>0</subscript></entry> | ||
769 | <entry></entry> | ||
770 | <entry></entry> | ||
771 | <entry></entry> | ||
772 | <entry></entry> | ||
773 | <entry></entry> | ||
774 | <entry></entry> | ||
775 | <entry></entry> | ||
776 | <entry></entry> | ||
777 | <entry></entry> | ||
778 | <entry></entry> | ||
779 | <entry></entry> | ||
780 | <entry></entry> | ||
781 | <entry></entry> | ||
782 | <entry></entry> | ||
783 | </row> | ||
784 | <row><!-- id="V4L2-PIX-FMT-BGR24" --> | ||
785 | <entry><constant>V4L2_PIX_FMT_BGR24</constant></entry> | ||
786 | <entry>'BGR3'</entry> | ||
787 | <entry></entry> | ||
788 | <entry>b<subscript>7</subscript></entry> | ||
789 | <entry>b<subscript>6</subscript></entry> | ||
790 | <entry>b<subscript>5</subscript></entry> | ||
791 | <entry>b<subscript>4</subscript></entry> | ||
792 | <entry>b<subscript>3</subscript></entry> | ||
793 | <entry>b<subscript>2</subscript></entry> | ||
794 | <entry>b<subscript>1</subscript></entry> | ||
795 | <entry>b<subscript>0</subscript></entry> | ||
796 | <entry></entry> | ||
797 | <entry>g<subscript>7</subscript></entry> | ||
798 | <entry>g<subscript>6</subscript></entry> | ||
799 | <entry>g<subscript>5</subscript></entry> | ||
800 | <entry>g<subscript>4</subscript></entry> | ||
801 | <entry>g<subscript>3</subscript></entry> | ||
802 | <entry>g<subscript>2</subscript></entry> | ||
803 | <entry>g<subscript>1</subscript></entry> | ||
804 | <entry>g<subscript>0</subscript></entry> | ||
805 | <entry></entry> | ||
806 | <entry>r<subscript>7</subscript></entry> | ||
807 | <entry>r<subscript>6</subscript></entry> | ||
808 | <entry>r<subscript>5</subscript></entry> | ||
809 | <entry>r<subscript>4</subscript></entry> | ||
810 | <entry>r<subscript>3</subscript></entry> | ||
811 | <entry>r<subscript>2</subscript></entry> | ||
812 | <entry>r<subscript>1</subscript></entry> | ||
813 | <entry>r<subscript>0</subscript></entry> | ||
814 | </row> | ||
815 | <row><!-- id="V4L2-PIX-FMT-RGB24" --> | ||
816 | <entry><constant>V4L2_PIX_FMT_RGB24</constant></entry> | ||
817 | <entry>'RGB3'</entry> | ||
818 | <entry></entry> | ||
819 | <entry>r<subscript>7</subscript></entry> | ||
820 | <entry>r<subscript>6</subscript></entry> | ||
821 | <entry>r<subscript>5</subscript></entry> | ||
822 | <entry>r<subscript>4</subscript></entry> | ||
823 | <entry>r<subscript>3</subscript></entry> | ||
824 | <entry>r<subscript>2</subscript></entry> | ||
825 | <entry>r<subscript>1</subscript></entry> | ||
826 | <entry>r<subscript>0</subscript></entry> | ||
827 | <entry></entry> | ||
828 | <entry>g<subscript>7</subscript></entry> | ||
829 | <entry>g<subscript>6</subscript></entry> | ||
830 | <entry>g<subscript>5</subscript></entry> | ||
831 | <entry>g<subscript>4</subscript></entry> | ||
832 | <entry>g<subscript>3</subscript></entry> | ||
833 | <entry>g<subscript>2</subscript></entry> | ||
834 | <entry>g<subscript>1</subscript></entry> | ||
835 | <entry>g<subscript>0</subscript></entry> | ||
836 | <entry></entry> | ||
837 | <entry>b<subscript>7</subscript></entry> | ||
838 | <entry>b<subscript>6</subscript></entry> | ||
839 | <entry>b<subscript>5</subscript></entry> | ||
840 | <entry>b<subscript>4</subscript></entry> | ||
841 | <entry>b<subscript>3</subscript></entry> | ||
842 | <entry>b<subscript>2</subscript></entry> | ||
843 | <entry>b<subscript>1</subscript></entry> | ||
844 | <entry>b<subscript>0</subscript></entry> | ||
845 | </row> | ||
846 | <row><!-- id="V4L2-PIX-FMT-BGR32" --> | ||
847 | <entry><constant>V4L2_PIX_FMT_BGR32</constant></entry> | ||
848 | <entry>'BGR4'</entry> | ||
849 | <entry></entry> | ||
850 | <entry>b<subscript>7</subscript></entry> | ||
851 | <entry>b<subscript>6</subscript></entry> | ||
852 | <entry>b<subscript>5</subscript></entry> | ||
853 | <entry>b<subscript>4</subscript></entry> | ||
854 | <entry>b<subscript>3</subscript></entry> | ||
855 | <entry>b<subscript>2</subscript></entry> | ||
856 | <entry>b<subscript>1</subscript></entry> | ||
857 | <entry>b<subscript>0</subscript></entry> | ||
858 | <entry></entry> | ||
859 | <entry>g<subscript>7</subscript></entry> | ||
860 | <entry>g<subscript>6</subscript></entry> | ||
861 | <entry>g<subscript>5</subscript></entry> | ||
862 | <entry>g<subscript>4</subscript></entry> | ||
863 | <entry>g<subscript>3</subscript></entry> | ||
864 | <entry>g<subscript>2</subscript></entry> | ||
865 | <entry>g<subscript>1</subscript></entry> | ||
866 | <entry>g<subscript>0</subscript></entry> | ||
867 | <entry></entry> | ||
868 | <entry>r<subscript>7</subscript></entry> | ||
869 | <entry>r<subscript>6</subscript></entry> | ||
870 | <entry>r<subscript>5</subscript></entry> | ||
871 | <entry>r<subscript>4</subscript></entry> | ||
872 | <entry>r<subscript>3</subscript></entry> | ||
873 | <entry>r<subscript>2</subscript></entry> | ||
874 | <entry>r<subscript>1</subscript></entry> | ||
875 | <entry>r<subscript>0</subscript></entry> | ||
876 | <entry></entry> | ||
877 | <entry>a<subscript>7</subscript></entry> | ||
878 | <entry>a<subscript>6</subscript></entry> | ||
879 | <entry>a<subscript>5</subscript></entry> | ||
880 | <entry>a<subscript>4</subscript></entry> | ||
881 | <entry>a<subscript>3</subscript></entry> | ||
882 | <entry>a<subscript>2</subscript></entry> | ||
883 | <entry>a<subscript>1</subscript></entry> | ||
884 | <entry>a<subscript>0</subscript></entry> | ||
885 | </row> | ||
886 | <row><!-- id="V4L2-PIX-FMT-RGB32" --> | ||
887 | <entry><constant>V4L2_PIX_FMT_RGB32</constant></entry> | ||
888 | <entry>'RGB4'</entry> | ||
889 | <entry></entry> | ||
890 | <entry>a<subscript>7</subscript></entry> | ||
891 | <entry>a<subscript>6</subscript></entry> | ||
892 | <entry>a<subscript>5</subscript></entry> | ||
893 | <entry>a<subscript>4</subscript></entry> | ||
894 | <entry>a<subscript>3</subscript></entry> | ||
895 | <entry>a<subscript>2</subscript></entry> | ||
896 | <entry>a<subscript>1</subscript></entry> | ||
897 | <entry>a<subscript>0</subscript></entry> | ||
898 | <entry></entry> | ||
899 | <entry>r<subscript>7</subscript></entry> | ||
900 | <entry>r<subscript>6</subscript></entry> | ||
901 | <entry>r<subscript>5</subscript></entry> | ||
902 | <entry>r<subscript>4</subscript></entry> | ||
903 | <entry>r<subscript>3</subscript></entry> | ||
904 | <entry>r<subscript>2</subscript></entry> | ||
905 | <entry>r<subscript>1</subscript></entry> | ||
906 | <entry>r<subscript>0</subscript></entry> | ||
907 | <entry></entry> | ||
908 | <entry>g<subscript>7</subscript></entry> | ||
909 | <entry>g<subscript>6</subscript></entry> | ||
910 | <entry>g<subscript>5</subscript></entry> | ||
911 | <entry>g<subscript>4</subscript></entry> | ||
912 | <entry>g<subscript>3</subscript></entry> | ||
913 | <entry>g<subscript>2</subscript></entry> | ||
914 | <entry>g<subscript>1</subscript></entry> | ||
915 | <entry>g<subscript>0</subscript></entry> | ||
916 | <entry></entry> | ||
917 | <entry>b<subscript>7</subscript></entry> | ||
918 | <entry>b<subscript>6</subscript></entry> | ||
919 | <entry>b<subscript>5</subscript></entry> | ||
920 | <entry>b<subscript>4</subscript></entry> | ||
921 | <entry>b<subscript>3</subscript></entry> | ||
922 | <entry>b<subscript>2</subscript></entry> | ||
923 | <entry>b<subscript>1</subscript></entry> | ||
924 | <entry>b<subscript>0</subscript></entry> | ||
925 | </row> | ||
926 | </tbody> | ||
927 | </tgroup> | ||
928 | </table> | ||
929 | |||
930 | <para>A test utility to determine which RGB formats a driver | 515 | <para>A test utility to determine which RGB formats a driver |
931 | actually supports is available from the LinuxTV v4l-dvb repository. | 516 | actually supports is available from the LinuxTV v4l-dvb repository. |
932 | See &v4l-dvb; for access instructions.</para> | 517 | See &v4l-dvb; for access instructions.</para> |
diff --git a/Documentation/DocBook/media/v4l/pixfmt-sdr-cu08.xml b/Documentation/DocBook/media/v4l/pixfmt-sdr-cu08.xml new file mode 100644 index 000000000000..2d80104c178b --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-sdr-cu08.xml | |||
@@ -0,0 +1,44 @@ | |||
1 | <refentry id="V4L2-SDR-FMT-CU08"> | ||
2 | <refmeta> | ||
3 | <refentrytitle>V4L2_SDR_FMT_CU8 ('CU08')</refentrytitle> | ||
4 | &manvol; | ||
5 | </refmeta> | ||
6 | <refnamediv> | ||
7 | <refname> | ||
8 | <constant>V4L2_SDR_FMT_CU8</constant> | ||
9 | </refname> | ||
10 | <refpurpose>Complex unsigned 8-bit IQ sample</refpurpose> | ||
11 | </refnamediv> | ||
12 | <refsect1> | ||
13 | <title>Description</title> | ||
14 | <para> | ||
15 | This format contains sequence of complex number samples. Each complex number | ||
16 | consist two parts, called In-phase and Quadrature (IQ). Both I and Q are | ||
17 | represented as a 8 bit unsigned number. I value comes first and Q value after | ||
18 | that. | ||
19 | </para> | ||
20 | <example> | ||
21 | <title><constant>V4L2_SDR_FMT_CU8</constant> 1 sample</title> | ||
22 | <formalpara> | ||
23 | <title>Byte Order.</title> | ||
24 | <para>Each cell is one byte. | ||
25 | <informaltable frame="none"> | ||
26 | <tgroup cols="2" align="center"> | ||
27 | <colspec align="left" colwidth="2*" /> | ||
28 | <tbody valign="top"> | ||
29 | <row> | ||
30 | <entry>start + 0:</entry> | ||
31 | <entry>I'<subscript>0</subscript></entry> | ||
32 | </row> | ||
33 | <row> | ||
34 | <entry>start + 1:</entry> | ||
35 | <entry>Q'<subscript>0</subscript></entry> | ||
36 | </row> | ||
37 | </tbody> | ||
38 | </tgroup> | ||
39 | </informaltable> | ||
40 | </para> | ||
41 | </formalpara> | ||
42 | </example> | ||
43 | </refsect1> | ||
44 | </refentry> | ||
diff --git a/Documentation/DocBook/media/v4l/pixfmt-sdr-cu16le.xml b/Documentation/DocBook/media/v4l/pixfmt-sdr-cu16le.xml new file mode 100644 index 000000000000..26288ffa9071 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-sdr-cu16le.xml | |||
@@ -0,0 +1,46 @@ | |||
1 | <refentry id="V4L2-SDR-FMT-CU16LE"> | ||
2 | <refmeta> | ||
3 | <refentrytitle>V4L2_SDR_FMT_CU16LE ('CU16')</refentrytitle> | ||
4 | &manvol; | ||
5 | </refmeta> | ||
6 | <refnamediv> | ||
7 | <refname> | ||
8 | <constant>V4L2_SDR_FMT_CU16LE</constant> | ||
9 | </refname> | ||
10 | <refpurpose>Complex unsigned 16-bit little endian IQ sample</refpurpose> | ||
11 | </refnamediv> | ||
12 | <refsect1> | ||
13 | <title>Description</title> | ||
14 | <para> | ||
15 | This format contains sequence of complex number samples. Each complex number | ||
16 | consist two parts, called In-phase and Quadrature (IQ). Both I and Q are | ||
17 | represented as a 16 bit unsigned little endian number. I value comes first | ||
18 | and Q value after that. | ||
19 | </para> | ||
20 | <example> | ||
21 | <title><constant>V4L2_SDR_FMT_CU16LE</constant> 1 sample</title> | ||
22 | <formalpara> | ||
23 | <title>Byte Order.</title> | ||
24 | <para>Each cell is one byte. | ||
25 | <informaltable frame="none"> | ||
26 | <tgroup cols="3" align="center"> | ||
27 | <colspec align="left" colwidth="2*" /> | ||
28 | <tbody valign="top"> | ||
29 | <row> | ||
30 | <entry>start + 0:</entry> | ||
31 | <entry>I'<subscript>0[7:0]</subscript></entry> | ||
32 | <entry>I'<subscript>0[15:8]</subscript></entry> | ||
33 | </row> | ||
34 | <row> | ||
35 | <entry>start + 2:</entry> | ||
36 | <entry>Q'<subscript>0[7:0]</subscript></entry> | ||
37 | <entry>Q'<subscript>0[15:8]</subscript></entry> | ||
38 | </row> | ||
39 | </tbody> | ||
40 | </tgroup> | ||
41 | </informaltable> | ||
42 | </para> | ||
43 | </formalpara> | ||
44 | </example> | ||
45 | </refsect1> | ||
46 | </refentry> | ||
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index 72d72bd67d0a..ea514d6075c5 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml | |||
@@ -25,7 +25,12 @@ capturing and output, for overlay frame buffer formats see also | |||
25 | <row> | 25 | <row> |
26 | <entry>__u32</entry> | 26 | <entry>__u32</entry> |
27 | <entry><structfield>height</structfield></entry> | 27 | <entry><structfield>height</structfield></entry> |
28 | <entry>Image height in pixels.</entry> | 28 | <entry>Image height in pixels. If <structfield>field</structfield> is |
29 | one of <constant>V4L2_FIELD_TOP</constant>, <constant>V4L2_FIELD_BOTTOM</constant> | ||
30 | or <constant>V4L2_FIELD_ALTERNATE</constant> then height refers to the | ||
31 | number of lines in the field, otherwise it refers to the number of | ||
32 | lines in the frame (which is twice the field height for interlaced | ||
33 | formats).</entry> | ||
29 | </row> | 34 | </row> |
30 | <row> | 35 | <row> |
31 | <entry spanname="hspan">Applications set these fields to | 36 | <entry spanname="hspan">Applications set these fields to |
@@ -54,7 +59,7 @@ linkend="reserved-formats" /></entry> | |||
54 | can request to capture or output only the top or bottom field, or both | 59 | can request to capture or output only the top or bottom field, or both |
55 | fields interlaced or sequentially stored in one buffer or alternating | 60 | fields interlaced or sequentially stored in one buffer or alternating |
56 | in separate buffers. Drivers return the actual field order selected. | 61 | in separate buffers. Drivers return the actual field order selected. |
57 | For details see <xref linkend="field-order" />.</entry> | 62 | For more details on fields see <xref linkend="field-order" />.</entry> |
58 | </row> | 63 | </row> |
59 | <row> | 64 | <row> |
60 | <entry>__u32</entry> | 65 | <entry>__u32</entry> |
@@ -81,7 +86,10 @@ plane and is divided by the same factor as the | |||
81 | example the Cb and Cr planes of a YUV 4:2:0 image have half as many | 86 | example the Cb and Cr planes of a YUV 4:2:0 image have half as many |
82 | padding bytes following each line as the Y plane. To avoid ambiguities | 87 | padding bytes following each line as the Y plane. To avoid ambiguities |
83 | drivers must return a <structfield>bytesperline</structfield> value | 88 | drivers must return a <structfield>bytesperline</structfield> value |
84 | rounded up to a multiple of the scale factor.</para></entry> | 89 | rounded up to a multiple of the scale factor.</para> |
90 | <para>For compressed formats the <structfield>bytesperline</structfield> | ||
91 | value makes no sense. Applications and drivers must set this to 0 in | ||
92 | that case.</para></entry> | ||
85 | </row> | 93 | </row> |
86 | <row> | 94 | <row> |
87 | <entry>__u32</entry> | 95 | <entry>__u32</entry> |
@@ -97,7 +105,8 @@ hold an image.</entry> | |||
97 | <entry>&v4l2-colorspace;</entry> | 105 | <entry>&v4l2-colorspace;</entry> |
98 | <entry><structfield>colorspace</structfield></entry> | 106 | <entry><structfield>colorspace</structfield></entry> |
99 | <entry>This information supplements the | 107 | <entry>This information supplements the |
100 | <structfield>pixelformat</structfield> and must be set by the driver, | 108 | <structfield>pixelformat</structfield> and must be set by the driver for |
109 | capture streams and by the application for output streams, | ||
101 | see <xref linkend="colorspaces" />.</entry> | 110 | see <xref linkend="colorspaces" />.</entry> |
102 | </row> | 111 | </row> |
103 | <row> | 112 | <row> |
@@ -135,7 +144,7 @@ set this field to zero.</entry> | |||
135 | <entry>__u16</entry> | 144 | <entry>__u16</entry> |
136 | <entry><structfield>bytesperline</structfield></entry> | 145 | <entry><structfield>bytesperline</structfield></entry> |
137 | <entry>Distance in bytes between the leftmost pixels in two adjacent | 146 | <entry>Distance in bytes between the leftmost pixels in two adjacent |
138 | lines.</entry> | 147 | lines. See &v4l2-pix-format;.</entry> |
139 | </row> | 148 | </row> |
140 | <row> | 149 | <row> |
141 | <entry>__u16</entry> | 150 | <entry>__u16</entry> |
@@ -154,12 +163,12 @@ set this field to zero.</entry> | |||
154 | <row> | 163 | <row> |
155 | <entry>__u32</entry> | 164 | <entry>__u32</entry> |
156 | <entry><structfield>width</structfield></entry> | 165 | <entry><structfield>width</structfield></entry> |
157 | <entry>Image width in pixels.</entry> | 166 | <entry>Image width in pixels. See &v4l2-pix-format;.</entry> |
158 | </row> | 167 | </row> |
159 | <row> | 168 | <row> |
160 | <entry>__u32</entry> | 169 | <entry>__u32</entry> |
161 | <entry><structfield>height</structfield></entry> | 170 | <entry><structfield>height</structfield></entry> |
162 | <entry>Image height in pixels.</entry> | 171 | <entry>Image height in pixels. See &v4l2-pix-format;.</entry> |
163 | </row> | 172 | </row> |
164 | <row> | 173 | <row> |
165 | <entry>__u32</entry> | 174 | <entry>__u32</entry> |
@@ -811,6 +820,17 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see | |||
811 | </table> | 820 | </table> |
812 | </section> | 821 | </section> |
813 | 822 | ||
823 | <section id="sdr-formats"> | ||
824 | <title>SDR Formats</title> | ||
825 | |||
826 | <para>These formats are used for <link linkend="sdr">SDR Capture</link> | ||
827 | interface only.</para> | ||
828 | |||
829 | &sub-sdr-cu08; | ||
830 | &sub-sdr-cu16le; | ||
831 | |||
832 | </section> | ||
833 | |||
814 | <section id="pixfmt-reserved"> | 834 | <section id="pixfmt-reserved"> |
815 | <title>Reserved Format Identifiers</title> | 835 | <title>Reserved Format Identifiers</title> |
816 | 836 | ||
diff --git a/Documentation/DocBook/media/v4l/remote_controllers.xml b/Documentation/DocBook/media/v4l/remote_controllers.xml index 160e464d44b7..5124a6c4daa8 100644 --- a/Documentation/DocBook/media/v4l/remote_controllers.xml +++ b/Documentation/DocBook/media/v4l/remote_controllers.xml | |||
@@ -1,10 +1,152 @@ | |||
1 | <partinfo> | ||
2 | <authorgroup> | ||
3 | <author> | ||
4 | <firstname>Mauro</firstname> | ||
5 | <surname>Chehab</surname> | ||
6 | <othername role="mi">Carvalho</othername> | ||
7 | <affiliation><address><email>m.chehab@samsung.com</email></address></affiliation> | ||
8 | <contrib>Initial version.</contrib> | ||
9 | </author> | ||
10 | </authorgroup> | ||
11 | <copyright> | ||
12 | <year>2009-2014</year> | ||
13 | <holder>Mauro Carvalho Chehab</holder> | ||
14 | </copyright> | ||
15 | |||
16 | <revhistory> | ||
17 | <!-- Put document revisions here, newest first. --> | ||
18 | <revision> | ||
19 | <revnumber>3.15</revnumber> | ||
20 | <date>2014-02-06</date> | ||
21 | <authorinitials>mcc</authorinitials> | ||
22 | <revremark>Added the interface description and the RC sysfs class description.</revremark> | ||
23 | </revision> | ||
24 | <revision> | ||
25 | <revnumber>1.0</revnumber> | ||
26 | <date>2009-09-06</date> | ||
27 | <authorinitials>mcc</authorinitials> | ||
28 | <revremark>Initial revision</revremark> | ||
29 | </revision> | ||
30 | </revhistory> | ||
31 | </partinfo> | ||
32 | |||
33 | <title>Remote Controller API</title> | ||
34 | <chapter id="remote_controllers"> | ||
35 | |||
1 | <title>Remote Controllers</title> | 36 | <title>Remote Controllers</title> |
37 | |||
2 | <section id="Remote_controllers_Intro"> | 38 | <section id="Remote_controllers_Intro"> |
3 | <title>Introduction</title> | 39 | <title>Introduction</title> |
4 | 40 | ||
5 | <para>Currently, most analog and digital devices have a Infrared input for remote controllers. Each | 41 | <para>Currently, most analog and digital devices have a Infrared input for remote controllers. Each |
6 | manufacturer has their own type of control. It is not rare for the same manufacturer to ship different | 42 | manufacturer has their own type of control. It is not rare for the same manufacturer to ship different |
7 | types of controls, depending on the device.</para> | 43 | types of controls, depending on the device.</para> |
44 | <para>A Remote Controller interface is mapped as a normal evdev/input interface, just like a keyboard or a mouse. | ||
45 | So, it uses all ioctls already defined for any other input devices.</para> | ||
46 | <para>However, remove controllers are more flexible than a normal input device, as the IR | ||
47 | receiver (and/or transmitter) can be used in conjunction with a wide variety of different IR remotes.</para> | ||
48 | <para>In order to allow flexibility, the Remote Controller subsystem allows controlling the | ||
49 | RC-specific attributes via <link linkend="remote_controllers_sysfs_nodes">the sysfs class nodes</link>.</para> | ||
50 | </section> | ||
51 | |||
52 | <section id="remote_controllers_sysfs_nodes"> | ||
53 | <title>Remote Controller's sysfs nodes</title> | ||
54 | <para>As defined at <constant>Documentation/ABI/testing/sysfs-class-rc</constant>, those are the sysfs nodes that control the Remote Controllers:</para> | ||
55 | |||
56 | <section id="sys_class_rc"> | ||
57 | <title>/sys/class/rc/</title> | ||
58 | <para>The <constant>/sys/class/rc/</constant> class sub-directory belongs to the Remote Controller | ||
59 | core and provides a sysfs interface for configuring infrared remote controller receivers. | ||
60 | </para> | ||
61 | |||
62 | </section> | ||
63 | <section id="sys_class_rc_rcN"> | ||
64 | <title>/sys/class/rc/rcN/</title> | ||
65 | <para>A <constant>/sys/class/rc/rcN</constant> directory is created for each remote | ||
66 | control receiver device where N is the number of the receiver.</para> | ||
67 | |||
68 | </section> | ||
69 | <section id="sys_class_rc_rcN_protocols"> | ||
70 | <title>/sys/class/rc/rcN/protocols</title> | ||
71 | <para>Reading this file returns a list of available protocols, something like:</para> | ||
72 | <para><constant>rc5 [rc6] nec jvc [sony]</constant></para> | ||
73 | <para>Enabled protocols are shown in [] brackets.</para> | ||
74 | <para>Writing "+proto" will add a protocol to the list of enabled protocols.</para> | ||
75 | <para>Writing "-proto" will remove a protocol from the list of enabled protocols.</para> | ||
76 | <para>Writing "proto" will enable only "proto".</para> | ||
77 | <para>Writing "none" will disable all protocols.</para> | ||
78 | <para>Write fails with EINVAL if an invalid protocol combination or unknown protocol name is used.</para> | ||
79 | |||
80 | </section> | ||
81 | <section id="sys_class_rc_rcN_filter"> | ||
82 | <title>/sys/class/rc/rcN/filter</title> | ||
83 | <para>Sets the scancode filter expected value.</para> | ||
84 | <para>Use in combination with <constant>/sys/class/rc/rcN/filter_mask</constant> to set the | ||
85 | expected value of the bits set in the filter mask. | ||
86 | If the hardware supports it then scancodes which do not match | ||
87 | the filter will be ignored. Otherwise the write will fail with | ||
88 | an error.</para> | ||
89 | <para>This value may be reset to 0 if the current protocol is altered.</para> | ||
90 | |||
91 | </section> | ||
92 | <section id="sys_class_rc_rcN_filter_mask"> | ||
93 | <title>/sys/class/rc/rcN/filter_mask</title> | ||
94 | <para>Sets the scancode filter mask of bits to compare. | ||
95 | Use in combination with <constant>/sys/class/rc/rcN/filter</constant> to set the bits | ||
96 | of the scancode which should be compared against the expected | ||
97 | value. A value of 0 disables the filter to allow all valid | ||
98 | scancodes to be processed.</para> | ||
99 | <para>If the hardware supports it then scancodes which do not match | ||
100 | the filter will be ignored. Otherwise the write will fail with | ||
101 | an error.</para> | ||
102 | <para>This value may be reset to 0 if the current protocol is altered.</para> | ||
103 | |||
104 | </section> | ||
105 | <section id="sys_class_rc_rcN_wakeup_protocols"> | ||
106 | <title>/sys/class/rc/rcN/wakeup_protocols</title> | ||
107 | <para>Reading this file returns a list of available protocols to use for the | ||
108 | wakeup filter, something like:</para> | ||
109 | <para><constant>rc5 rc6 nec jvc [sony]</constant></para> | ||
110 | <para>The enabled wakeup protocol is shown in [] brackets.</para> | ||
111 | <para>Writing "+proto" will add a protocol to the list of enabled wakeup | ||
112 | protocols.</para> | ||
113 | <para>Writing "-proto" will remove a protocol from the list of enabled wakeup | ||
114 | protocols.</para> | ||
115 | <para>Writing "proto" will use "proto" for wakeup events.</para> | ||
116 | <para>Writing "none" will disable wakeup.</para> | ||
117 | <para>Write fails with EINVAL if an invalid protocol combination or unknown | ||
118 | protocol name is used, or if wakeup is not supported by the hardware.</para> | ||
119 | |||
120 | </section> | ||
121 | <section id="sys_class_rc_rcN_wakeup_filter"> | ||
122 | <title>/sys/class/rc/rcN/wakeup_filter</title> | ||
123 | <para>Sets the scancode wakeup filter expected value. | ||
124 | Use in combination with <constant>/sys/class/rc/rcN/wakeup_filter_mask</constant> to | ||
125 | set the expected value of the bits set in the wakeup filter mask | ||
126 | to trigger a system wake event.</para> | ||
127 | <para>If the hardware supports it and wakeup_filter_mask is not 0 then | ||
128 | scancodes which match the filter will wake the system from e.g. | ||
129 | suspend to RAM or power off. | ||
130 | Otherwise the write will fail with an error.</para> | ||
131 | <para>This value may be reset to 0 if the wakeup protocol is altered.</para> | ||
132 | |||
133 | </section> | ||
134 | <section id="sys_class_rc_rcN_wakeup_filter_mask"> | ||
135 | <title>/sys/class/rc/rcN/wakeup_filter_mask</title> | ||
136 | <para>Sets the scancode wakeup filter mask of bits to compare. | ||
137 | Use in combination with <constant>/sys/class/rc/rcN/wakeup_filter</constant> to set | ||
138 | the bits of the scancode which should be compared against the | ||
139 | expected value to trigger a system wake event.</para> | ||
140 | <para>If the hardware supports it and wakeup_filter_mask is not 0 then | ||
141 | scancodes which match the filter will wake the system from e.g. | ||
142 | suspend to RAM or power off. | ||
143 | Otherwise the write will fail with an error.</para> | ||
144 | <para>This value may be reset to 0 if the wakeup protocol is altered.</para> | ||
145 | </section> | ||
146 | </section> | ||
147 | |||
148 | <section id="Remote_controllers_tables"> | ||
149 | <title>Remote controller tables</title> | ||
8 | <para>Unfortunately, for several years, there was no effort to create uniform IR keycodes for | 150 | <para>Unfortunately, for several years, there was no effort to create uniform IR keycodes for |
9 | different devices. This caused the same IR keyname to be mapped completely differently on | 151 | different devices. This caused the same IR keyname to be mapped completely differently on |
10 | different IR devices. This resulted that the same IR keyname to be mapped completely different on | 152 | different IR devices. This resulted that the same IR keyname to be mapped completely different on |
@@ -175,3 +317,4 @@ keymapping.</para> | |||
175 | </section> | 317 | </section> |
176 | 318 | ||
177 | &sub-lirc_device_interface; | 319 | &sub-lirc_device_interface; |
320 | </chapter> | ||
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 74b7f27af71a..b445161b912c 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml | |||
@@ -70,7 +70,7 @@ MPEG stream embedded, sliced VBI data format in this specification. | |||
70 | Remote Controller chapter.</contrib> | 70 | Remote Controller chapter.</contrib> |
71 | <affiliation> | 71 | <affiliation> |
72 | <address> | 72 | <address> |
73 | <email>mchehab@redhat.com</email> | 73 | <email>m.chehab@samsung.com</email> |
74 | </address> | 74 | </address> |
75 | </affiliation> | 75 | </affiliation> |
76 | </author> | 76 | </author> |
@@ -107,6 +107,16 @@ Remote Controller chapter.</contrib> | |||
107 | </address> | 107 | </address> |
108 | </affiliation> | 108 | </affiliation> |
109 | </author> | 109 | </author> |
110 | <author> | ||
111 | <firstname>Antti</firstname> | ||
112 | <surname>Palosaari</surname> | ||
113 | <contrib>SDR API.</contrib> | ||
114 | <affiliation> | ||
115 | <address> | ||
116 | <email>crope@iki.fi</email> | ||
117 | </address> | ||
118 | </affiliation> | ||
119 | </author> | ||
110 | </authorgroup> | 120 | </authorgroup> |
111 | 121 | ||
112 | <copyright> | 122 | <copyright> |
@@ -125,6 +135,7 @@ Remote Controller chapter.</contrib> | |||
125 | <year>2011</year> | 135 | <year>2011</year> |
126 | <year>2012</year> | 136 | <year>2012</year> |
127 | <year>2013</year> | 137 | <year>2013</year> |
138 | <year>2014</year> | ||
128 | <holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin | 139 | <holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin |
129 | Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab, | 140 | Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab, |
130 | Pawel Osciak</holder> | 141 | Pawel Osciak</holder> |
@@ -141,6 +152,16 @@ structs, ioctls) must be noted in more detail in the history chapter | |||
141 | applications. --> | 152 | applications. --> |
142 | 153 | ||
143 | <revision> | 154 | <revision> |
155 | <revnumber>3.15</revnumber> | ||
156 | <date>2014-02-03</date> | ||
157 | <authorinitials>hv, ap</authorinitials> | ||
158 | <revremark>Update several sections of "Common API Elements": "Opening and Closing Devices" | ||
159 | "Querying Capabilities", "Application Priority", "Video Inputs and Outputs", "Audio Inputs and Outputs" | ||
160 | "Tuners and Modulators", "Video Standards" and "Digital Video (DV) Timings". Added SDR API. | ||
161 | </revremark> | ||
162 | </revision> | ||
163 | |||
164 | <revision> | ||
144 | <revnumber>3.14</revnumber> | 165 | <revnumber>3.14</revnumber> |
145 | <date>2013-11-25</date> | 166 | <date>2013-11-25</date> |
146 | <authorinitials>rr</authorinitials> | 167 | <authorinitials>rr</authorinitials> |
@@ -537,6 +558,7 @@ and discussions on the V4L mailing list.</revremark> | |||
537 | <section id="ttx"> &sub-dev-teletext; </section> | 558 | <section id="ttx"> &sub-dev-teletext; </section> |
538 | <section id="radio"> &sub-dev-radio; </section> | 559 | <section id="radio"> &sub-dev-radio; </section> |
539 | <section id="rds"> &sub-dev-rds; </section> | 560 | <section id="rds"> &sub-dev-rds; </section> |
561 | <section id="sdr"> &sub-dev-sdr; </section> | ||
540 | <section id="event"> &sub-dev-event; </section> | 562 | <section id="event"> &sub-dev-event; </section> |
541 | <section id="subdev"> &sub-dev-subdev; </section> | 563 | <section id="subdev"> &sub-dev-subdev; </section> |
542 | </chapter> | 564 | </chapter> |
@@ -585,6 +607,7 @@ and discussions on the V4L mailing list.</revremark> | |||
585 | &sub-g-crop; | 607 | &sub-g-crop; |
586 | &sub-g-ctrl; | 608 | &sub-g-ctrl; |
587 | &sub-g-dv-timings; | 609 | &sub-g-dv-timings; |
610 | &sub-g-edid; | ||
588 | &sub-g-enc-index; | 611 | &sub-g-enc-index; |
589 | &sub-g-ext-ctrls; | 612 | &sub-g-ext-ctrls; |
590 | &sub-g-fbuf; | 613 | &sub-g-fbuf; |
@@ -616,7 +639,6 @@ and discussions on the V4L mailing list.</revremark> | |||
616 | &sub-subdev-enum-frame-size; | 639 | &sub-subdev-enum-frame-size; |
617 | &sub-subdev-enum-mbus-code; | 640 | &sub-subdev-enum-mbus-code; |
618 | &sub-subdev-g-crop; | 641 | &sub-subdev-g-crop; |
619 | &sub-subdev-g-edid; | ||
620 | &sub-subdev-g-fmt; | 642 | &sub-subdev-g-fmt; |
621 | &sub-subdev-g-frame-interval; | 643 | &sub-subdev-g-frame-interval; |
622 | &sub-subdev-g-selection; | 644 | &sub-subdev-g-selection; |
diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml index 6541ba0175ed..4e8ea65f7282 100644 --- a/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml +++ b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml | |||
@@ -100,7 +100,7 @@ See <xref linkend="v4l2-tuner-type" /></entry> | |||
100 | <entry><structfield>capability</structfield></entry> | 100 | <entry><structfield>capability</structfield></entry> |
101 | <entry spanname="hspan">The tuner/modulator capability flags for | 101 | <entry spanname="hspan">The tuner/modulator capability flags for |
102 | this frequency band, see <xref linkend="tuner-capability" />. The <constant>V4L2_TUNER_CAP_LOW</constant> | 102 | this frequency band, see <xref linkend="tuner-capability" />. The <constant>V4L2_TUNER_CAP_LOW</constant> |
103 | capability must be the same for all frequency bands of the selected tuner/modulator. | 103 | or <constant>V4L2_TUNER_CAP_1HZ</constant> capability must be the same for all frequency bands of the selected tuner/modulator. |
104 | So either all bands have that capability set, or none of them have that capability.</entry> | 104 | So either all bands have that capability set, or none of them have that capability.</entry> |
105 | </row> | 105 | </row> |
106 | <row> | 106 | <row> |
@@ -109,7 +109,8 @@ So either all bands have that capability set, or none of them have that capabili | |||
109 | <entry spanname="hspan">The lowest tunable frequency in | 109 | <entry spanname="hspan">The lowest tunable frequency in |
110 | units of 62.5 kHz, or if the <structfield>capability</structfield> | 110 | units of 62.5 kHz, or if the <structfield>capability</structfield> |
111 | flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 | 111 | flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 |
112 | Hz, for this frequency band.</entry> | 112 | Hz, for this frequency band. A 1 Hz unit is used when the <structfield>capability</structfield> flag |
113 | <constant>V4L2_TUNER_CAP_1HZ</constant> is set.</entry> | ||
113 | </row> | 114 | </row> |
114 | <row> | 115 | <row> |
115 | <entry>__u32</entry> | 116 | <entry>__u32</entry> |
@@ -117,7 +118,8 @@ Hz, for this frequency band.</entry> | |||
117 | <entry spanname="hspan">The highest tunable frequency in | 118 | <entry spanname="hspan">The highest tunable frequency in |
118 | units of 62.5 kHz, or if the <structfield>capability</structfield> | 119 | units of 62.5 kHz, or if the <structfield>capability</structfield> |
119 | flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 | 120 | flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 |
120 | Hz, for this frequency band.</entry> | 121 | Hz, for this frequency band. A 1 Hz unit is used when the <structfield>capability</structfield> flag |
122 | <constant>V4L2_TUNER_CAP_1HZ</constant> is set.</entry> | ||
121 | </row> | 123 | </row> |
122 | <row> | 124 | <row> |
123 | <entry>__u32</entry> | 125 | <entry>__u32</entry> |
diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml b/Documentation/DocBook/media/v4l/vidioc-g-edid.xml index bbd18f0e6ede..ce4563b87131 100644 --- a/Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-edid.xml | |||
@@ -1,12 +1,12 @@ | |||
1 | <refentry id="vidioc-subdev-g-edid"> | 1 | <refentry id="vidioc-g-edid"> |
2 | <refmeta> | 2 | <refmeta> |
3 | <refentrytitle>ioctl VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</refentrytitle> | 3 | <refentrytitle>ioctl VIDIOC_G_EDID, VIDIOC_S_EDID</refentrytitle> |
4 | &manvol; | 4 | &manvol; |
5 | </refmeta> | 5 | </refmeta> |
6 | 6 | ||
7 | <refnamediv> | 7 | <refnamediv> |
8 | <refname>VIDIOC_SUBDEV_G_EDID</refname> | 8 | <refname>VIDIOC_G_EDID</refname> |
9 | <refname>VIDIOC_SUBDEV_S_EDID</refname> | 9 | <refname>VIDIOC_S_EDID</refname> |
10 | <refpurpose>Get or set the EDID of a video receiver/transmitter</refpurpose> | 10 | <refpurpose>Get or set the EDID of a video receiver/transmitter</refpurpose> |
11 | </refnamediv> | 11 | </refnamediv> |
12 | 12 | ||
@@ -16,7 +16,7 @@ | |||
16 | <funcdef>int <function>ioctl</function></funcdef> | 16 | <funcdef>int <function>ioctl</function></funcdef> |
17 | <paramdef>int <parameter>fd</parameter></paramdef> | 17 | <paramdef>int <parameter>fd</parameter></paramdef> |
18 | <paramdef>int <parameter>request</parameter></paramdef> | 18 | <paramdef>int <parameter>request</parameter></paramdef> |
19 | <paramdef>struct v4l2_subdev_edid *<parameter>argp</parameter></paramdef> | 19 | <paramdef>struct v4l2_edid *<parameter>argp</parameter></paramdef> |
20 | </funcprototype> | 20 | </funcprototype> |
21 | </funcsynopsis> | 21 | </funcsynopsis> |
22 | <funcsynopsis> | 22 | <funcsynopsis> |
@@ -24,7 +24,7 @@ | |||
24 | <funcdef>int <function>ioctl</function></funcdef> | 24 | <funcdef>int <function>ioctl</function></funcdef> |
25 | <paramdef>int <parameter>fd</parameter></paramdef> | 25 | <paramdef>int <parameter>fd</parameter></paramdef> |
26 | <paramdef>int <parameter>request</parameter></paramdef> | 26 | <paramdef>int <parameter>request</parameter></paramdef> |
27 | <paramdef>const struct v4l2_subdev_edid *<parameter>argp</parameter></paramdef> | 27 | <paramdef>const struct v4l2_edid *<parameter>argp</parameter></paramdef> |
28 | </funcprototype> | 28 | </funcprototype> |
29 | </funcsynopsis> | 29 | </funcsynopsis> |
30 | </refsynopsisdiv> | 30 | </refsynopsisdiv> |
@@ -42,7 +42,7 @@ | |||
42 | <varlistentry> | 42 | <varlistentry> |
43 | <term><parameter>request</parameter></term> | 43 | <term><parameter>request</parameter></term> |
44 | <listitem> | 44 | <listitem> |
45 | <para>VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</para> | 45 | <para>VIDIOC_G_EDID, VIDIOC_S_EDID</para> |
46 | </listitem> | 46 | </listitem> |
47 | </varlistentry> | 47 | </varlistentry> |
48 | <varlistentry> | 48 | <varlistentry> |
@@ -56,12 +56,20 @@ | |||
56 | 56 | ||
57 | <refsect1> | 57 | <refsect1> |
58 | <title>Description</title> | 58 | <title>Description</title> |
59 | <para>These ioctls can be used to get or set an EDID associated with an input pad | 59 | <para>These ioctls can be used to get or set an EDID associated with an input |
60 | from a receiver or an output pad of a transmitter subdevice.</para> | 60 | from a receiver or an output of a transmitter device. They can be |
61 | used with subdevice nodes (/dev/v4l-subdevX) or with video nodes (/dev/videoX).</para> | ||
62 | |||
63 | <para>When used with video nodes the <structfield>pad</structfield> field represents the | ||
64 | input (for video capture devices) or output (for video output devices) index as | ||
65 | is returned by &VIDIOC-ENUMINPUT; and &VIDIOC-ENUMOUTPUT; respectively. When used | ||
66 | with subdevice nodes the <structfield>pad</structfield> field represents the | ||
67 | input or output pad of the subdevice. If there is no EDID support for the given | ||
68 | <structfield>pad</structfield> value, then the &EINVAL; will be returned.</para> | ||
61 | 69 | ||
62 | <para>To get the EDID data the application has to fill in the <structfield>pad</structfield>, | 70 | <para>To get the EDID data the application has to fill in the <structfield>pad</structfield>, |
63 | <structfield>start_block</structfield>, <structfield>blocks</structfield> and <structfield>edid</structfield> | 71 | <structfield>start_block</structfield>, <structfield>blocks</structfield> and <structfield>edid</structfield> |
64 | fields and call <constant>VIDIOC_SUBDEV_G_EDID</constant>. The current EDID from block | 72 | fields and call <constant>VIDIOC_G_EDID</constant>. The current EDID from block |
65 | <structfield>start_block</structfield> and of size <structfield>blocks</structfield> | 73 | <structfield>start_block</structfield> and of size <structfield>blocks</structfield> |
66 | will be placed in the memory <structfield>edid</structfield> points to. The <structfield>edid</structfield> | 74 | will be placed in the memory <structfield>edid</structfield> points to. The <structfield>edid</structfield> |
67 | pointer must point to memory at least <structfield>blocks</structfield> * 128 bytes | 75 | pointer must point to memory at least <structfield>blocks</structfield> * 128 bytes |
@@ -91,15 +99,17 @@ | |||
91 | data in some way. In any case, the end result is the same: the EDID is no longer available. | 99 | data in some way. In any case, the end result is the same: the EDID is no longer available. |
92 | </para> | 100 | </para> |
93 | 101 | ||
94 | <table pgwide="1" frame="none" id="v4l2-subdev-edid"> | 102 | <table pgwide="1" frame="none" id="v4l2-edid"> |
95 | <title>struct <structname>v4l2_subdev_edid</structname></title> | 103 | <title>struct <structname>v4l2_edid</structname></title> |
96 | <tgroup cols="3"> | 104 | <tgroup cols="3"> |
97 | &cs-str; | 105 | &cs-str; |
98 | <tbody valign="top"> | 106 | <tbody valign="top"> |
99 | <row> | 107 | <row> |
100 | <entry>__u32</entry> | 108 | <entry>__u32</entry> |
101 | <entry><structfield>pad</structfield></entry> | 109 | <entry><structfield>pad</structfield></entry> |
102 | <entry>Pad for which to get/set the EDID blocks.</entry> | 110 | <entry>Pad for which to get/set the EDID blocks. When used with a video device |
111 | node the pad represents the input or output index as returned by | ||
112 | &VIDIOC-ENUMINPUT; and &VIDIOC-ENUMOUTPUT; respectively.</entry> | ||
103 | </row> | 113 | </row> |
104 | <row> | 114 | <row> |
105 | <entry>__u32</entry> | 115 | <entry>__u32</entry> |
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml index b3bb9575b2e0..e9f6735c0823 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml | |||
@@ -327,7 +327,12 @@ These controls are described in <xref | |||
327 | These controls are described in <xref | 327 | These controls are described in <xref |
328 | linkend="fm-rx-controls" />.</entry> | 328 | linkend="fm-rx-controls" />.</entry> |
329 | </row> | 329 | </row> |
330 | 330 | <row> | |
331 | <entry><constant>V4L2_CTRL_CLASS_RF_TUNER</constant></entry> | ||
332 | <entry>0xa20000</entry> | ||
333 | <entry>The class containing RF tuner controls. | ||
334 | These controls are described in <xref linkend="rf-tuner-controls" />.</entry> | ||
335 | </row> | ||
331 | </tbody> | 336 | </tbody> |
332 | </tgroup> | 337 | </tgroup> |
333 | </table> | 338 | </table> |
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml index ee8f56e1bac0..4fe19a7a9a31 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml | |||
@@ -172,6 +172,13 @@ capture and output devices.</entry> | |||
172 | </row> | 172 | </row> |
173 | <row> | 173 | <row> |
174 | <entry></entry> | 174 | <entry></entry> |
175 | <entry>&v4l2-sdr-format;</entry> | ||
176 | <entry><structfield>sdr</structfield></entry> | ||
177 | <entry>Definition of a data format, see | ||
178 | <xref linkend="pixfmt" />, used by SDR capture devices.</entry> | ||
179 | </row> | ||
180 | <row> | ||
181 | <entry></entry> | ||
175 | <entry>__u8</entry> | 182 | <entry>__u8</entry> |
176 | <entry><structfield>raw_data</structfield>[200]</entry> | 183 | <entry><structfield>raw_data</structfield>[200]</entry> |
177 | <entry>Place holder for future extensions.</entry> | 184 | <entry>Place holder for future extensions.</entry> |
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml index c7a1c462e724..d1034fb61d15 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml | |||
@@ -109,9 +109,10 @@ See <xref linkend="v4l2-tuner-type" /></entry> | |||
109 | <entry>__u32</entry> | 109 | <entry>__u32</entry> |
110 | <entry><structfield>frequency</structfield></entry> | 110 | <entry><structfield>frequency</structfield></entry> |
111 | <entry>Tuning frequency in units of 62.5 kHz, or if the | 111 | <entry>Tuning frequency in units of 62.5 kHz, or if the |
112 | &v4l2-tuner; or &v4l2-modulator; <structfield>capabilities</structfield> flag | 112 | &v4l2-tuner; or &v4l2-modulator; <structfield>capability</structfield> flag |
113 | <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 | 113 | <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 |
114 | Hz.</entry> | 114 | Hz. A 1 Hz unit is used when the <structfield>capability</structfield> flag |
115 | <constant>V4L2_TUNER_CAP_1HZ</constant> is set.</entry> | ||
115 | </row> | 116 | </row> |
116 | <row> | 117 | <row> |
117 | <entry>__u32</entry> | 118 | <entry>__u32</entry> |
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml b/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml index 7f4ac7e41fa8..7068b599a00d 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml | |||
@@ -113,7 +113,8 @@ change for example with the current video standard.</entry> | |||
113 | <entry>The lowest tunable frequency in units of 62.5 | 113 | <entry>The lowest tunable frequency in units of 62.5 |
114 | KHz, or if the <structfield>capability</structfield> flag | 114 | KHz, or if the <structfield>capability</structfield> flag |
115 | <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 | 115 | <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 |
116 | Hz.</entry> | 116 | Hz, or if the <structfield>capability</structfield> flag |
117 | <constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz.</entry> | ||
117 | </row> | 118 | </row> |
118 | <row> | 119 | <row> |
119 | <entry>__u32</entry> | 120 | <entry>__u32</entry> |
@@ -121,7 +122,8 @@ Hz.</entry> | |||
121 | <entry>The highest tunable frequency in units of 62.5 | 122 | <entry>The highest tunable frequency in units of 62.5 |
122 | KHz, or if the <structfield>capability</structfield> flag | 123 | KHz, or if the <structfield>capability</structfield> flag |
123 | <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 | 124 | <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 |
124 | Hz.</entry> | 125 | Hz, or if the <structfield>capability</structfield> flag |
126 | <constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz.</entry> | ||
125 | </row> | 127 | </row> |
126 | <row> | 128 | <row> |
127 | <entry>__u32</entry> | 129 | <entry>__u32</entry> |
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml index 6cc82010c736..b0d865933da6 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml | |||
@@ -134,7 +134,9 @@ the structure refers to a radio tuner the | |||
134 | <entry spanname="hspan">The lowest tunable frequency in | 134 | <entry spanname="hspan">The lowest tunable frequency in |
135 | units of 62.5 kHz, or if the <structfield>capability</structfield> | 135 | units of 62.5 kHz, or if the <structfield>capability</structfield> |
136 | flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 | 136 | flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 |
137 | Hz. If multiple frequency bands are supported, then | 137 | Hz, or if the <structfield>capability</structfield> flag |
138 | <constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz. | ||
139 | If multiple frequency bands are supported, then | ||
138 | <structfield>rangelow</structfield> is the lowest frequency | 140 | <structfield>rangelow</structfield> is the lowest frequency |
139 | of all the frequency bands.</entry> | 141 | of all the frequency bands.</entry> |
140 | </row> | 142 | </row> |
@@ -144,7 +146,9 @@ of all the frequency bands.</entry> | |||
144 | <entry spanname="hspan">The highest tunable frequency in | 146 | <entry spanname="hspan">The highest tunable frequency in |
145 | units of 62.5 kHz, or if the <structfield>capability</structfield> | 147 | units of 62.5 kHz, or if the <structfield>capability</structfield> |
146 | flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 | 148 | flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 |
147 | Hz. If multiple frequency bands are supported, then | 149 | Hz, or if the <structfield>capability</structfield> flag |
150 | <constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz. | ||
151 | If multiple frequency bands are supported, then | ||
148 | <structfield>rangehigh</structfield> is the highest frequency | 152 | <structfield>rangehigh</structfield> is the highest frequency |
149 | of all the frequency bands.</entry> | 153 | of all the frequency bands.</entry> |
150 | </row> | 154 | </row> |
@@ -270,7 +274,7 @@ applications must set the array to zero.</entry> | |||
270 | <entry><constant>V4L2_TUNER_CAP_LOW</constant></entry> | 274 | <entry><constant>V4L2_TUNER_CAP_LOW</constant></entry> |
271 | <entry>0x0001</entry> | 275 | <entry>0x0001</entry> |
272 | <entry>When set, tuning frequencies are expressed in units of | 276 | <entry>When set, tuning frequencies are expressed in units of |
273 | 62.5 Hz, otherwise in units of 62.5 kHz.</entry> | 277 | 62.5 Hz instead of 62.5 kHz.</entry> |
274 | </row> | 278 | </row> |
275 | <row> | 279 | <row> |
276 | <entry><constant>V4L2_TUNER_CAP_NORM</constant></entry> | 280 | <entry><constant>V4L2_TUNER_CAP_NORM</constant></entry> |
@@ -360,6 +364,11 @@ radio tuners.</entry> | |||
360 | <entry>The range to search when using the hardware seek functionality | 364 | <entry>The range to search when using the hardware seek functionality |
361 | is programmable, see &VIDIOC-S-HW-FREQ-SEEK; for details.</entry> | 365 | is programmable, see &VIDIOC-S-HW-FREQ-SEEK; for details.</entry> |
362 | </row> | 366 | </row> |
367 | <row> | ||
368 | <entry><constant>V4L2_TUNER_CAP_1HZ</constant></entry> | ||
369 | <entry>0x1000</entry> | ||
370 | <entry>When set, tuning frequencies are expressed in units of 1 Hz instead of 62.5 kHz.</entry> | ||
371 | </row> | ||
363 | </tbody> | 372 | </tbody> |
364 | </tgroup> | 373 | </tgroup> |
365 | </table> | 374 | </table> |
diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index d5a3c97b206a..370d49d6fb64 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml | |||
@@ -296,6 +296,12 @@ modulator programming see | |||
296 | <xref linkend="tuner" />.</entry> | 296 | <xref linkend="tuner" />.</entry> |
297 | </row> | 297 | </row> |
298 | <row> | 298 | <row> |
299 | <entry><constant>V4L2_CAP_SDR_CAPTURE</constant></entry> | ||
300 | <entry>0x00100000</entry> | ||
301 | <entry>The device supports the | ||
302 | <link linkend="sdr">SDR Capture</link> interface.</entry> | ||
303 | </row> | ||
304 | <row> | ||
299 | <entry><constant>V4L2_CAP_READWRITE</constant></entry> | 305 | <entry><constant>V4L2_CAP_READWRITE</constant></entry> |
300 | <entry>0x01000000</entry> | 306 | <entry>0x01000000</entry> |
301 | <entry>The device supports the <link | 307 | <entry>The device supports the <link |
diff --git a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml index 5b379e752194..a5fc4c4880f3 100644 --- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml +++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml | |||
@@ -121,7 +121,9 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry> | |||
121 | <entry>If non-zero, the lowest tunable frequency of the band to | 121 | <entry>If non-zero, the lowest tunable frequency of the band to |
122 | search in units of 62.5 kHz, or if the &v4l2-tuner; | 122 | search in units of 62.5 kHz, or if the &v4l2-tuner; |
123 | <structfield>capability</structfield> field has the | 123 | <structfield>capability</structfield> field has the |
124 | <constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz. | 124 | <constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz or if the &v4l2-tuner; |
125 | <structfield>capability</structfield> field has the | ||
126 | <constant>V4L2_TUNER_CAP_1HZ</constant> flag set, in units of 1 Hz. | ||
125 | If <structfield>rangelow</structfield> is zero a reasonable default value | 127 | If <structfield>rangelow</structfield> is zero a reasonable default value |
126 | is used.</entry> | 128 | is used.</entry> |
127 | </row> | 129 | </row> |
@@ -131,7 +133,9 @@ is used.</entry> | |||
131 | <entry>If non-zero, the highest tunable frequency of the band to | 133 | <entry>If non-zero, the highest tunable frequency of the band to |
132 | search in units of 62.5 kHz, or if the &v4l2-tuner; | 134 | search in units of 62.5 kHz, or if the &v4l2-tuner; |
133 | <structfield>capability</structfield> field has the | 135 | <structfield>capability</structfield> field has the |
134 | <constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz. | 136 | <constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz or if the &v4l2-tuner; |
137 | <structfield>capability</structfield> field has the | ||
138 | <constant>V4L2_TUNER_CAP_1HZ</constant> flag set, in units of 1 Hz. | ||
135 | If <structfield>rangehigh</structfield> is zero a reasonable default value | 139 | If <structfield>rangehigh</structfield> is zero a reasonable default value |
136 | is used.</entry> | 140 | is used.</entry> |
137 | </row> | 141 | </row> |
diff --git a/Documentation/DocBook/media/v4l/vidioc-streamon.xml b/Documentation/DocBook/media/v4l/vidioc-streamon.xml index 65dff55079d7..df2c63d07bac 100644 --- a/Documentation/DocBook/media/v4l/vidioc-streamon.xml +++ b/Documentation/DocBook/media/v4l/vidioc-streamon.xml | |||
@@ -52,16 +52,24 @@ | |||
52 | <para>The <constant>VIDIOC_STREAMON</constant> and | 52 | <para>The <constant>VIDIOC_STREAMON</constant> and |
53 | <constant>VIDIOC_STREAMOFF</constant> ioctl start and stop the capture | 53 | <constant>VIDIOC_STREAMOFF</constant> ioctl start and stop the capture |
54 | or output process during streaming (<link linkend="mmap">memory | 54 | or output process during streaming (<link linkend="mmap">memory |
55 | mapping</link> or <link linkend="userp">user pointer</link>) I/O.</para> | 55 | mapping</link>, <link linkend="userp">user pointer</link> or |
56 | <link linkend="dmabuf">DMABUF</link>) I/O.</para> | ||
56 | 57 | ||
57 | <para>Specifically the capture hardware is disabled and no input | 58 | <para>Capture hardware is disabled and no input |
58 | buffers are filled (if there are any empty buffers in the incoming | 59 | buffers are filled (if there are any empty buffers in the incoming |
59 | queue) until <constant>VIDIOC_STREAMON</constant> has been called. | 60 | queue) until <constant>VIDIOC_STREAMON</constant> has been called. |
60 | Accordingly the output hardware is disabled, no video signal is | 61 | Output hardware is disabled and no video signal is |
61 | produced until <constant>VIDIOC_STREAMON</constant> has been called. | 62 | produced until <constant>VIDIOC_STREAMON</constant> has been called. |
62 | The ioctl will succeed when at least one output buffer is in the | 63 | The ioctl will succeed when at least one output buffer is in the |
63 | incoming queue.</para> | 64 | incoming queue.</para> |
64 | 65 | ||
66 | <para>Memory-to-memory devices will not start until | ||
67 | <constant>VIDIOC_STREAMON</constant> has been called for both the capture | ||
68 | and output stream types.</para> | ||
69 | |||
70 | <para>If <constant>VIDIOC_STREAMON</constant> fails then any already | ||
71 | queued buffers will remain queued.</para> | ||
72 | |||
65 | <para>The <constant>VIDIOC_STREAMOFF</constant> ioctl, apart of | 73 | <para>The <constant>VIDIOC_STREAMOFF</constant> ioctl, apart of |
66 | aborting or finishing any DMA in progress, unlocks any user pointer | 74 | aborting or finishing any DMA in progress, unlocks any user pointer |
67 | buffers locked in physical memory, and it removes all buffers from the | 75 | buffers locked in physical memory, and it removes all buffers from the |
@@ -70,14 +78,22 @@ dequeued yet will be lost, likewise all images enqueued for output but | |||
70 | not transmitted yet. I/O returns to the same state as after calling | 78 | not transmitted yet. I/O returns to the same state as after calling |
71 | &VIDIOC-REQBUFS; and can be restarted accordingly.</para> | 79 | &VIDIOC-REQBUFS; and can be restarted accordingly.</para> |
72 | 80 | ||
81 | <para>If buffers have been queued with &VIDIOC-QBUF; and | ||
82 | <constant>VIDIOC_STREAMOFF</constant> is called without ever having | ||
83 | called <constant>VIDIOC_STREAMON</constant>, then those queued buffers | ||
84 | will also be removed from the incoming queue and all are returned to the | ||
85 | same state as after calling &VIDIOC-REQBUFS; and can be restarted | ||
86 | accordingly.</para> | ||
87 | |||
73 | <para>Both ioctls take a pointer to an integer, the desired buffer or | 88 | <para>Both ioctls take a pointer to an integer, the desired buffer or |
74 | stream type. This is the same as &v4l2-requestbuffers; | 89 | stream type. This is the same as &v4l2-requestbuffers; |
75 | <structfield>type</structfield>.</para> | 90 | <structfield>type</structfield>.</para> |
76 | 91 | ||
77 | <para>If <constant>VIDIOC_STREAMON</constant> is called when streaming | 92 | <para>If <constant>VIDIOC_STREAMON</constant> is called when streaming |
78 | is already in progress, or if <constant>VIDIOC_STREAMOFF</constant> is called | 93 | is already in progress, or if <constant>VIDIOC_STREAMOFF</constant> is called |
79 | when streaming is already stopped, then the ioctl does nothing and 0 is | 94 | when streaming is already stopped, then 0 is returned. Nothing happens in the |
80 | returned.</para> | 95 | case of <constant>VIDIOC_STREAMON</constant>, but <constant>VIDIOC_STREAMOFF</constant> |
96 | will return queued buffers to their starting state as mentioned above.</para> | ||
81 | 97 | ||
82 | <para>Note that applications can be preempted for unknown periods right | 98 | <para>Note that applications can be preempted for unknown periods right |
83 | before or after the <constant>VIDIOC_STREAMON</constant> or | 99 | before or after the <constant>VIDIOC_STREAMON</constant> or |
@@ -93,7 +109,7 @@ synchronize with other events.</para> | |||
93 | <varlistentry> | 109 | <varlistentry> |
94 | <term><errorcode>EINVAL</errorcode></term> | 110 | <term><errorcode>EINVAL</errorcode></term> |
95 | <listitem> | 111 | <listitem> |
96 | <para>The buffer<structfield>type</structfield> is not supported, | 112 | <para>The buffer <structfield>type</structfield> is not supported, |
97 | or no buffers have been allocated (memory mapping) or enqueued | 113 | or no buffers have been allocated (memory mapping) or enqueued |
98 | (output) yet.</para> | 114 | (output) yet.</para> |
99 | </listitem> | 115 | </listitem> |
diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index ab56f89c8642..4decb46bfa76 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl | |||
@@ -34,22 +34,20 @@ | |||
34 | 34 | ||
35 | <book id="media_api"> | 35 | <book id="media_api"> |
36 | <bookinfo> | 36 | <bookinfo> |
37 | <title>LINUX MEDIA INFRASTRUCTURE API</title> | 37 | <title>LINUX MEDIA INFRASTRUCTURE API</title> |
38 | 38 | ||
39 | <copyright> | 39 | <copyright> |
40 | <year>2009-2012</year> | 40 | <year>2009-2014</year> |
41 | <holder>LinuxTV Developers</holder> | 41 | <holder>LinuxTV Developers</holder> |
42 | </copyright> | 42 | </copyright> |
43 | 43 | ||
44 | <legalnotice> | 44 | <legalnotice> |
45 | 45 | <para>Permission is granted to copy, distribute and/or modify | |
46 | <para>Permission is granted to copy, distribute and/or modify | 46 | this document under the terms of the GNU Free Documentation License, |
47 | this document under the terms of the GNU Free Documentation License, | 47 | Version 1.1 or any later version published by the Free Software |
48 | Version 1.1 or any later version published by the Free Software | 48 | Foundation. A copy of the license is included in the chapter entitled |
49 | Foundation. A copy of the license is included in the chapter entitled | 49 | "GNU Free Documentation License"</para> |
50 | "GNU Free Documentation License"</para> | 50 | </legalnotice> |
51 | </legalnotice> | ||
52 | |||
53 | </bookinfo> | 51 | </bookinfo> |
54 | 52 | ||
55 | <toc></toc> <!-- autogenerated --> | 53 | <toc></toc> <!-- autogenerated --> |
@@ -60,10 +58,11 @@ Foundation. A copy of the license is included in the chapter entitled | |||
60 | <para>This document covers the Linux Kernel to Userspace API's used by | 58 | <para>This document covers the Linux Kernel to Userspace API's used by |
61 | video and radio streaming devices, including video cameras, | 59 | video and radio streaming devices, including video cameras, |
62 | analog and digital TV receiver cards, AM/FM receiver cards, | 60 | analog and digital TV receiver cards, AM/FM receiver cards, |
63 | streaming capture devices.</para> | 61 | streaming capture and output devices, codec devices and remote |
62 | controllers.</para> | ||
64 | <para>It is divided into four parts.</para> | 63 | <para>It is divided into four parts.</para> |
65 | <para>The first part covers radio, capture, | 64 | <para>The first part covers radio, video capture and output, |
66 | cameras and analog TV devices.</para> | 65 | cameras, analog TV devices and codecs.</para> |
67 | <para>The second part covers the | 66 | <para>The second part covers the |
68 | API used for digital TV and Internet reception via one of the | 67 | API used for digital TV and Internet reception via one of the |
69 | several digital tv standards. While it is called as DVB API, | 68 | several digital tv standards. While it is called as DVB API, |
@@ -75,55 +74,14 @@ Foundation. A copy of the license is included in the chapter entitled | |||
75 | <para>For additional information and for the latest development code, | 74 | <para>For additional information and for the latest development code, |
76 | see: <ulink url="http://linuxtv.org">http://linuxtv.org</ulink>.</para> | 75 | see: <ulink url="http://linuxtv.org">http://linuxtv.org</ulink>.</para> |
77 | <para>For discussing improvements, reporting troubles, sending new drivers, etc, please mail to: <ulink url="http://vger.kernel.org/vger-lists.html#linux-media">Linux Media Mailing List (LMML).</ulink>.</para> | 76 | <para>For discussing improvements, reporting troubles, sending new drivers, etc, please mail to: <ulink url="http://vger.kernel.org/vger-lists.html#linux-media">Linux Media Mailing List (LMML).</ulink>.</para> |
78 | |||
79 | </preface> | 77 | </preface> |
80 | 78 | ||
81 | <part id="v4l2spec"> | 79 | <part id="v4l2spec">&sub-v4l2;</part> |
82 | &sub-v4l2; | 80 | <part id="dvbapi">&sub-dvbapi;</part> |
83 | </part> | 81 | <part id="remotes">&sub-remote_controllers;</part> |
84 | <part id="dvbapi"> | 82 | <part id="media_common">&sub-media-controller;</part> |
85 | &sub-dvbapi; | ||
86 | </part> | ||
87 | <part id="v4ldvb_common"> | ||
88 | <partinfo> | ||
89 | <authorgroup> | ||
90 | <author> | ||
91 | <firstname>Mauro</firstname> | ||
92 | <surname>Chehab</surname> | ||
93 | <othername role="mi">Carvalho</othername> | ||
94 | <affiliation><address><email>mchehab@redhat.com</email></address></affiliation> | ||
95 | <contrib>Initial version.</contrib> | ||
96 | </author> | ||
97 | </authorgroup> | ||
98 | <copyright> | ||
99 | <year>2009-2012</year> | ||
100 | <holder>Mauro Carvalho Chehab</holder> | ||
101 | </copyright> | ||
102 | |||
103 | <revhistory> | ||
104 | <!-- Put document revisions here, newest first. --> | ||
105 | <revision> | ||
106 | <revnumber>1.0.0</revnumber> | ||
107 | <date>2009-09-06</date> | ||
108 | <authorinitials>mcc</authorinitials> | ||
109 | <revremark>Initial revision</revremark> | ||
110 | </revision> | ||
111 | </revhistory> | ||
112 | </partinfo> | ||
113 | |||
114 | <title>Remote Controller API</title> | ||
115 | <chapter id="remote_controllers"> | ||
116 | &sub-remote_controllers; | ||
117 | </chapter> | ||
118 | </part> | ||
119 | <part id="media_common"> | ||
120 | &sub-media-controller; | ||
121 | </part> | ||
122 | |||
123 | <chapter id="gen_errors"> | ||
124 | &sub-gen-errors; | ||
125 | </chapter> | ||
126 | 83 | ||
84 | <chapter id="gen_errors">&sub-gen-errors;</chapter> | ||
127 | 85 | ||
128 | &sub-fdl-appendix; | 86 | &sub-fdl-appendix; |
129 | 87 | ||