Commit c20eb18c authored by Mauro Carvalho Chehab's avatar Mauro Carvalho Chehab

[media] DocBook/v4l: Document the new system-wide version behavior

Acked-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
parent 29834c1a
......@@ -236,7 +236,15 @@ important parts of the API.</para>
<para>The &VIDIOC-QUERYCAP; ioctl is available to check if the kernel
device is compatible with this specification, and to query the <link
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;
to learn about the number, types and names of video connectors on 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
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>
<revnumber>2.6.39</revnumber>
<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
ASCII string. For example: "bttv". Driver specific applications can
use this information to verify the driver identity. It is also useful
to work around known bugs, or to identify drivers in error reports.
The driver version is stored in the <structfield>version</structfield>
field.</para><para>Storing strings in fixed sized arrays is bad
to work around known bugs, or to identify drivers in error reports.</para>
<para>Storing strings in fixed sized arrays is bad
practice but unavoidable here. Drivers and applications should take
precautions to never read or write beyond the end of the array and to
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>
<entry>__u32</entry>
<entry><structfield>version</structfield></entry>
<entry><para>Version number of the driver. Together with
the <structfield>driver</structfield> field this identifies a
particular driver. The version number is formatted using the
<entry><para>Version number of the driver.</para>
<para>Starting on kernel 3.1, the version reported is provided per
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>
</row>
<row>
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment