From: Hans Verkuil Date: Fri, 14 Sep 2012 10:39:55 +0000 (-0300) Subject: [media] DocBook: fix awkward language and fix the documented return value X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=d7a11e1f18e1b6772af0e7670baa83ce8c3b2674;p=GitHub%2FLineageOS%2Fandroid_kernel_motorola_exynos9610.git [media] DocBook: fix awkward language and fix the documented return value The Video Standard section contains some awkward language. It also wasn't updated when the error code for unimplemented ioctls changed from EINVAL to ENOTTY. [mchehab@redhat.com: remove a misplaced footnote tag] Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml index b91d25313b63..73c6847436c9 100644 --- a/Documentation/DocBook/media/v4l/common.xml +++ b/Documentation/DocBook/media/v4l/common.xml @@ -564,7 +564,7 @@ automatically. To query and select the standard used by the current video input or output applications call the &VIDIOC-G-STD; and &VIDIOC-S-STD; ioctl, respectively. The received -standard can be sensed with the &VIDIOC-QUERYSTD; ioctl. Note parameter of all these ioctls is a pointer to a &v4l2-std-id; type (a standard set), not an index into the standard enumeration. +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), not an index into the standard enumeration. An alternative to the current scheme is to use pointers to indices as arguments of VIDIOC_G_STD and VIDIOC_S_STD, the &v4l2-input; and @@ -588,30 +588,28 @@ switch to a standard by &v4l2-std-id;. Drivers must implement all video standard ioctls when the device has one or more video inputs or outputs. - Special rules apply to USB cameras where the notion of video -standards makes little sense. More generally any capture device, -output devices accordingly, which is + Special rules apply to devices such as USB cameras where the notion of video +standards makes little sense. More generally for any capture or output device +which is: incapable of capturing fields or frames at the nominal rate of the video standard, or - where timestamps refer -to the instant the field or frame was received by the driver, not the -capture time, or - - - where sequence numbers -refer to the frames received by the driver, not the captured -frames. + that does not support the video standard formats at all. Here the driver shall set the std field of &v4l2-input; and &v4l2-output; -to zero, the VIDIOC_G_STD, +to zero and the VIDIOC_G_STD, VIDIOC_S_STD, VIDIOC_QUERYSTD and VIDIOC_ENUMSTD ioctls shall return the -&EINVAL;. +&ENOTTY;. + See for a rationale. + Applications can make use of the and + flags to determine whether the video standard ioctls +are available for the device. +&ENOTTY;. See for a rationale. Probably even USB cameras follow some well known video standard. It might have been better to explicitly indicate elsewhere if a device cannot live @@ -626,9 +624,9 @@ up to normal expectations, instead of this exception. &v4l2-standard; standard; if (-1 == ioctl (fd, &VIDIOC-G-STD;, &std_id)) { - /* Note when VIDIOC_ENUMSTD always returns EINVAL this + /* Note when VIDIOC_ENUMSTD always returns ENOTTY this is no video device or it falls under the USB exception, - and VIDIOC_G_STD returning EINVAL is no error. */ + and VIDIOC_G_STD returning ENOTTY is no error. */ perror ("VIDIOC_G_STD"); exit (EXIT_FAILURE);