[media] DocBook/v4l: Document the new system-wide version behavior
Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This commit is contained in:
parent
29834c1ac7
commit
c20eb18ce1
|
@ -236,7 +236,15 @@ important parts of the API.</para>
|
||||||
<para>The &VIDIOC-QUERYCAP; ioctl is available to check if the kernel
|
<para>The &VIDIOC-QUERYCAP; ioctl is available to check if the kernel
|
||||||
device is compatible with this specification, and to query the <link
|
device is compatible with this specification, and to query the <link
|
||||||
linkend="devices">functions</link> and <link linkend="io">I/O
|
linkend="devices">functions</link> and <link linkend="io">I/O
|
||||||
methods</link> supported by the device. Other features can be queried
|
methods</link> supported by the device.</para>
|
||||||
|
|
||||||
|
<para>Starting with kernel version 3.1, VIDIOC-QUERYCAP will return the
|
||||||
|
V4L2 API version used by the driver, with generally matches the Kernel version.
|
||||||
|
There's no need of using &VIDIOC-QUERYCAP; to check if an specific ioctl is
|
||||||
|
supported, the V4L2 core now returns ENOIOCTLCMD if a driver doesn't provide
|
||||||
|
support for an ioctl.</para>
|
||||||
|
|
||||||
|
<para>Other features can be queried
|
||||||
by calling the respective ioctl, for example &VIDIOC-ENUMINPUT;
|
by calling the respective ioctl, for example &VIDIOC-ENUMINPUT;
|
||||||
to learn about the number, types and names of video connectors on the
|
to learn about the number, types and names of video connectors on the
|
||||||
device. Although abstraction is a major objective of this API, the
|
device. Although abstraction is a major objective of this API, the
|
||||||
|
|
|
@ -127,6 +127,12 @@ structs, ioctls) must be noted in more detail in the history chapter
|
||||||
(compat.xml), along with the possible impact on existing drivers and
|
(compat.xml), along with the possible impact on existing drivers and
|
||||||
applications. -->
|
applications. -->
|
||||||
|
|
||||||
|
<revision>
|
||||||
|
<revnumber>3.1</revnumber>
|
||||||
|
<date>2011-06-27</date>
|
||||||
|
<authorinitials>mcc, po</authorinitials>
|
||||||
|
<revremark>Documented that VIDIOC_QUERYCAP now returns a per-subsystem version instead of a per-driver one.</revremark>
|
||||||
|
</revision>
|
||||||
<revision>
|
<revision>
|
||||||
<revnumber>2.6.39</revnumber>
|
<revnumber>2.6.39</revnumber>
|
||||||
<date>2011-03-01</date>
|
<date>2011-03-01</date>
|
||||||
|
|
|
@ -67,9 +67,8 @@ driver is not compatible with this specification the ioctl returns an
|
||||||
<entry><para>Name of the driver, a unique NUL-terminated
|
<entry><para>Name of the driver, a unique NUL-terminated
|
||||||
ASCII string. For example: "bttv". Driver specific applications can
|
ASCII string. For example: "bttv". Driver specific applications can
|
||||||
use this information to verify the driver identity. It is also useful
|
use this information to verify the driver identity. It is also useful
|
||||||
to work around known bugs, or to identify drivers in error reports.
|
to work around known bugs, or to identify drivers in error reports.</para>
|
||||||
The driver version is stored in the <structfield>version</structfield>
|
<para>Storing strings in fixed sized arrays is bad
|
||||||
field.</para><para>Storing strings in fixed sized arrays is bad
|
|
||||||
practice but unavoidable here. Drivers and applications should take
|
practice but unavoidable here. Drivers and applications should take
|
||||||
precautions to never read or write beyond the end of the array and to
|
precautions to never read or write beyond the end of the array and to
|
||||||
make sure the strings are properly NUL-terminated.</para></entry>
|
make sure the strings are properly NUL-terminated.</para></entry>
|
||||||
|
@ -100,9 +99,13 @@ empty string (<structfield>bus_info</structfield>[0] = 0).<!-- XXX pci_dev->slot
|
||||||
<row>
|
<row>
|
||||||
<entry>__u32</entry>
|
<entry>__u32</entry>
|
||||||
<entry><structfield>version</structfield></entry>
|
<entry><structfield>version</structfield></entry>
|
||||||
<entry><para>Version number of the driver. Together with
|
<entry><para>Version number of the driver.</para>
|
||||||
the <structfield>driver</structfield> field this identifies a
|
<para>Starting on kernel 3.1, the version reported is provided per
|
||||||
particular driver. The version number is formatted using the
|
V4L2 subsystem, following the same Kernel numberation scheme. However, it
|
||||||
|
should not always return the same version as the kernel, if, for example,
|
||||||
|
an stable or distribution-modified kernel uses the V4L2 stack from a
|
||||||
|
newer kernel.</para>
|
||||||
|
<para>The version number is formatted using the
|
||||||
<constant>KERNEL_VERSION()</constant> macro:</para></entry>
|
<constant>KERNEL_VERSION()</constant> macro:</para></entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
|
|
Reference in New Issue