From patchwork Sun Jan 16 22:21:43 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pawel Osciak X-Patchwork-Id: 5604 Return-path: Envelope-to: mchehab@pedra Delivery-date: Sun, 16 Jan 2011 20:24:46 -0200 Received: from mchehab by pedra with local (Exim 4.72) (envelope-from ) id 1Peb1i-00044D-2r for mchehab@pedra; Sun, 16 Jan 2011 20:24:46 -0200 Received: from casper.infradead.org [85.118.1.10] by pedra with IMAP (fetchmail-6.3.17) for (single-drop); Sun, 16 Jan 2011 20:24:46 -0200 (BRST) Received: from vger.kernel.org ([209.132.180.67]) by casper.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1PeazO-00016u-Ts; Sun, 16 Jan 2011 22:22:23 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754038Ab1APWWQ (ORCPT + 1 other); Sun, 16 Jan 2011 17:22:16 -0500 Received: from mail-px0-f174.google.com ([209.85.212.174]:34392 "EHLO mail-px0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754006Ab1APWWP (ORCPT ); Sun, 16 Jan 2011 17:22:15 -0500 Received: by pxi15 with SMTP id 15so739671pxi.19 for ; Sun, 16 Jan 2011 14:22:14 -0800 (PST) Received: by 10.142.165.15 with SMTP id n15mr2905841wfe.99.1295216534847; Sun, 16 Jan 2011 14:22:14 -0800 (PST) Received: from localhost.localdomain (c-24-4-32-53.hsd1.ca.comcast.net [24.4.32.53]) by mx.google.com with ESMTPS id q13sm5603561wfc.17.2011.01.16.14.22.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 Jan 2011 14:22:13 -0800 (PST) From: Pawel Osciak To: linux-media@vger.kernel.org Cc: m.szyprowski@samsung.com, kyungmin.park@samsung.com, s.nawrocki@samsung.com, Pawel Osciak Subject: [PATCH] [media] Remove compatibility layer from multi-planar API documentation Date: Sun, 16 Jan 2011 14:21:43 -0800 Message-Id: <1295216503-15535-1-git-send-email-pawel@osciak.com> X-Mailer: git-send-email 1.7.3.5 Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Sender: This feature will probably be moved to libv4l2. Signed-off-by: Pawel Osciak --- Documentation/DocBook/v4l/planar-apis.xml | 35 +++++------------------- Documentation/DocBook/v4l/vidioc-querycap.xml | 22 +++++++-------- 2 files changed, 18 insertions(+), 39 deletions(-) diff --git a/Documentation/DocBook/v4l/planar-apis.xml b/Documentation/DocBook/v4l/planar-apis.xml index 8be7552..e6b5c18 100644 --- a/Documentation/DocBook/v4l/planar-apis.xml +++ b/Documentation/DocBook/v4l/planar-apis.xml @@ -2,10 +2,10 @@ Single- and multi-planar APIs Some devices require data for each input or output video frame - to be placed in discontiguous memory buffers. In such cases one + to be placed in discontiguous memory buffers. In such cases, one video frame has to be addressed using more than one memory address, i.e. one - pointer per "plane". A plane is a sub-buffer of current frame. For examples - of such formats see . + pointer per "plane". A plane is a sub-buffer of the current frame. For + examples of such formats see . Initially, V4L2 API did not support multi-planar buffers and a set of extensions has been introduced to handle them. Those extensions constitute @@ -14,8 +14,8 @@ Some of the V4L2 API calls and structures are interpreted differently, depending on whether single- or multi-planar API is being used. An application can choose whether to use one or the other by passing a corresponding buffer - type to its ioctl calls. Multi-planar versions of buffer types are suffixed with - an `_MPLANE' string. For a list of available multi-planar buffer types + type to its ioctl calls. Multi-planar versions of buffer types are suffixed + with an `_MPLANE' string. For a list of available multi-planar buffer types see &v4l2-buf-type;. @@ -24,28 +24,9 @@ Multi-planar API introduces new multi-planar formats. Those formats use a separate set of FourCC codes. It is important to distinguish between the multi-planar API and a multi-planar format. Multi-planar API calls can - handle all single-planar formats as well, while the single-planar API cannot - handle multi-planar formats. Applications do not have to switch between APIs - when handling both single- and multi-planar devices and should use the - multi-planar API version for both single- and multi-planar formats. - Drivers that do not support multi-planar API can still be handled with it, - utilizing a compatibility layer built into standard V4L2 ioctl handling. - - - -
- Single and multi-planar API compatibility layer - In most casesThe compatibility layer does not cover - drivers that do not use video_ioctl2() call., applications - can use the multi-planar API with older drivers that support - only its single-planar version and vice versa. Appropriate conversion is - done seamlessly for both applications and drivers in the V4L2 core. The - general rule of thumb is: as long as an application uses formats that - a driver supports, it can use either API (although use of multi-planar - formats is only possible with the multi-planar API). The list of formats - supported by a driver can be obtained using the &VIDIOC-ENUM-FMT; call. - It is possible, but discouraged, for a driver or an application to support - and use both versions of the API. + handle all single-planar formats as well (as long as they are passed in + multi-planar API structures), while the single-planar API cannot + handle multi-planar formats.
diff --git a/Documentation/DocBook/v4l/vidioc-querycap.xml b/Documentation/DocBook/v4l/vidioc-querycap.xml index 9369976..f29f1b8 100644 --- a/Documentation/DocBook/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/v4l/vidioc-querycap.xml @@ -142,30 +142,28 @@ this array to zero. V4L2_CAP_VIDEO_CAPTURE 0x00000001 - The device supports single-planar formats through the Video Capture interface. An application can use either -the single or the multi-planar API. + The device supports the single-planar API through the Video Capture interface. V4L2_CAP_VIDEO_CAPTURE_MPLANE 0x00001000 - The device supports multi-planar formats through the Video Capture interface. An application has to use the -multi-planar API. + The device supports the + multi-planar API through the + Video Capture interface. V4L2_CAP_VIDEO_OUTPUT 0x00000002 - The device supports single-planar formats through the Video Output interface. An application can use either -the single or the multi-planar API. + The device supports the single-planar API through the Video Output interface. V4L2_CAP_VIDEO_OUTPUT_MPLANE 0x00002000 - The device supports multi-planar formats through the Video Output interface. An application has to use the -multi-planar API. + The device supports the + multi-planar API through the + Video Output interface. V4L2_CAP_VIDEO_OVERLAY