summaryrefslogtreecommitdiff
path: root/Documentation/DocBook
diff options
context:
space:
mode:
authorHans Verkuil <hverkuil@xs4all.nl>2015-03-11 09:00:45 -0300
committerMauro Carvalho Chehab <mchehab@osg.samsung.com>2015-04-02 18:20:19 -0300
commit2ddb77bb1138dccb5067690e8696e991093e22c6 (patch)
tree9fdf05e5488485493b5ac99ecdfe3c0c3f9993d4 /Documentation/DocBook
parent3259aa57dba142c04da3f37e207f9cbcf30a76df (diff)
downloadlinux-exynos-2ddb77bb1138dccb5067690e8696e991093e22c6.tar.gz
linux-exynos-2ddb77bb1138dccb5067690e8696e991093e22c6.tar.bz2
linux-exynos-2ddb77bb1138dccb5067690e8696e991093e22c6.zip
[media] DocBook v4l: update bytesperline handling
The documentation says that the bytesperline field in v4l2_pix_format refers to the largest plane in the case of planar formats (i.e. multiple planes stores in a single buffer). For almost all planar formats the first plane is also the largest (or equal) plane, except for two formats: V4L2_PIX_FMT_NV24/NV42. For this YUV 4:4:4 format the second chroma plane is twice the size of the first luma plane. Looking at the very few drivers that support this format the bytesperline value that they report is actually that of the first plane and not that of the largest plane. Rather than fixing the drivers it makes more sense to update the documentation since it is very difficult to use the largest plane for this. You would have to check what the format is in order to know to which plane bytesperline belongs, which makes calculations much more difficult. This patch updates the documentation accordingly. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Diffstat (limited to 'Documentation/DocBook')
-rw-r--r--Documentation/DocBook/media/v4l/pixfmt.xml4
-rw-r--r--Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml4
2 files changed, 4 insertions, 4 deletions
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml
index 56bdd24abf69..79c2bd049c92 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -80,9 +80,9 @@ padding bytes after the last line of an image cross a system page
boundary. Input devices may write padding bytes, the value is
undefined. Output devices ignore the contents of padding
bytes.</para><para>When the image format is planar the
-<structfield>bytesperline</structfield> value applies to the largest
+<structfield>bytesperline</structfield> value applies to the first
plane and is divided by the same factor as the
-<structfield>width</structfield> field for any smaller planes. For
+<structfield>width</structfield> field for the other planes. For
example the Cb and Cr planes of a YUV 4:2:0 image have half as many
padding bytes following each line as the Y plane. To avoid ambiguities
drivers must return a <structfield>bytesperline</structfield> value
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml b/Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml
index 20460730b02c..77607cc19688 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml
@@ -240,9 +240,9 @@ where padding bytes after the last line of an image cross a system
page boundary. Capture devices may write padding bytes, the value is
undefined. Output devices ignore the contents of padding
bytes.</para><para>When the image format is planar the
-<structfield>bytesperline</structfield> value applies to the largest
+<structfield>bytesperline</structfield> value applies to the first
plane and is divided by the same factor as the
-<structfield>width</structfield> field for any smaller planes. For
+<structfield>width</structfield> field for the other planes. For
example the Cb and Cr planes of a YUV 4:2:0 image have half as many
padding bytes following each line as the Y plane. To avoid ambiguities
drivers must return a <structfield>bytesperline</structfield> value