mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2025-01-22 08:28:27 +07:00
[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
|
||||
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>
|
||||
|
Loading…
Reference in New Issue
Block a user