From patchwork Tue Jun 28 02:17:33 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 925382 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter2.kernel.org (8.14.4/8.14.4) with ESMTP id p5SGbMFs024323 for ; Tue, 28 Jun 2011 16:38:28 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759425Ab1F1Qej (ORCPT ); Tue, 28 Jun 2011 12:34:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28682 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758860Ab1F1QcL (ORCPT ); Tue, 28 Jun 2011 12:32:11 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p5SGWA3X007242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Jun 2011 12:32:10 -0400 Received: from pedra (vpn-8-193.rdu.redhat.com [10.11.8.193]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p5SGVgwT021073; Tue, 28 Jun 2011 12:32:09 -0400 Date: Mon, 27 Jun 2011 23:17:33 -0300 From: Mauro Carvalho Chehab Cc: Linux Media Mailing List , LKML Subject: [PATCHv2 13/13] [media] DocBook/v4l: Document the new system-wide version behavior Message-ID: <20110627231733.6dc52158@pedra> In-Reply-To: References: Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 To: unlisted-recipients:; (no To-header on input) Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter2.kernel.org [140.211.167.43]); Tue, 28 Jun 2011 16:38:28 +0000 (UTC) Acked-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 9028721..a86f7a0 100644 --- a/Documentation/DocBook/media/v4l/common.xml +++ b/Documentation/DocBook/media/v4l/common.xml @@ -236,7 +236,15 @@ important parts of the API. The &VIDIOC-QUERYCAP; ioctl is available to check if the kernel device is compatible with this specification, and to query the functions and I/O -methods supported by the device. Other features can be queried +methods supported by the device. + + 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. + + 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 diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index a7fd76d..c5ee398 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -128,6 +128,12 @@ structs, ioctls) must be noted in more detail in the history chapter applications. --> + 3.1 + 2011-06-27 + mcc, po + Documented that VIDIOC_QUERYCAP now returns a per-subsystem version instead of a per-driver one. + + 2.6.39 2011-03-01 mcc, po diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index f29f1b8..7aa6973 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -67,9 +67,8 @@ driver is not compatible with this specification the ioctl returns an 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 version -field.Storing strings in fixed sized arrays is bad +to work around known bugs, or to identify drivers in error reports. +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. @@ -100,9 +99,13 @@ empty string (bus_info[0] = 0).