The patch number 10481 was added via Hans Verkuil <hverk...@xs4all.nl>
to http://linuxtv.org/hg/v4l-dvb master development tree.
Kernel patches in this development tree may be modified to be backward
compatible with older kernels. Compatibility modifications will be
removed before inclusion into the mainstream Kernel
If anyone has any objections, please let us know by sending a message to:
Linux Media Mailing List <linux-me...@vger.kernel.org>
------
From: Hans Verkuil <hverk...@xs4all.nl>
v4l2-spec: fix some table alignment problems
Priority: normal
Signed-off-by: Hans Verkuil <hverk...@xs4all.nl>
---
v4l2-spec/dev-overlay.sgml | 16 ++++++++----
v4l2-spec/vidioc-g-fbuf.sgml | 45 +++++++++++++++++++++++++----------
2 files changed, 44 insertions(+), 17 deletions(-)
diff -r 68de51ae08c3 -r ab72ec45d16e v4l2-spec/dev-overlay.sgml
--- a/v4l2-spec/dev-overlay.sgml Thu Jan 22 08:10:36 2009 +0100
+++ b/v4l2-spec/dev-overlay.sgml Thu Jan 22 08:52:53 2009 +0100
@@ -214,7 +214,9 @@ clipping rectangles.</entry>
clipping rectangles.</entry>
</row>
<row>
- <entry spanname="hspan">Like the window coordinates
+ <entry></entry>
+ <entry></entry>
+ <entry>Like the window coordinates
<structfield>w</structfield>, clipping rectangles are defined relative
to the top, left corner of the frame buffer. However clipping
rectangles must not extend the frame buffer width and height, and they
@@ -276,15 +278,19 @@ more pixels or not write the image at al
<row>
<entry>__u8</entry>
<entry><structfield>global_alpha</structfield></entry>
- <entry><para>The global alpha value used to blend the
+ <entry>The global alpha value used to blend the
framebuffer with video images, if global alpha blending has been
negotiated (<constant>V4L2_FBUF_FLAG_GLOBAL_ALPHA</constant>, see
-&VIDIOC-S-FBUF;, <xref linkend="framebuffer-flags">).</para><para>Note
-this field was added in Linux 2.6.23, extending the structure. However
+&VIDIOC-S-FBUF;, <xref linkend="framebuffer-flags">).</entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry></entry>
+ <entry>Note this field was added in Linux 2.6.23, extending the
structure. However
the <link linkend="vidioc-g-fmt">VIDIOC_G/S/TRY_FMT</link> ioctls,
which take a pointer to a <link
linkend="v4l2-format">v4l2_format</link> parent structure with padding
-bytes at the end, are not affected.</para></entry>
+bytes at the end, are not affected.</entry>
</row>
</tbody>
</tgroup>
diff -r 68de51ae08c3 -r ab72ec45d16e v4l2-spec/vidioc-g-fbuf.sgml
--- a/v4l2-spec/vidioc-g-fbuf.sgml Thu Jan 22 08:10:36 2009 +0100
+++ b/v4l2-spec/vidioc-g-fbuf.sgml Thu Jan 22 08:52:53 2009 +0100
@@ -131,20 +131,25 @@ driver, see <xref linkend="framebuffer-f
<entry>void *</entry>
<entry><structfield>base</structfield></entry>
<entry></entry>
- <entry><para>Physical base address of the framebuffer,
+ <entry>Physical base address of the framebuffer,
that is the address of the pixel in the top left corner of the
framebuffer.<footnote><para>A physical base address may not suit all
platforms. GK notes in theory we should pass something like PCI device
+ memory region + offset instead. If you encounter problems please
-discuss on the linux-media mailing list:
-&v4l-ml;.</para></footnote></para><para>This field is irrelevant to
+discuss on the linux-media mailing list: &v4l-ml;.</para></footnote></entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry>This field is irrelevant to
<wordasword>non-destructive Video Overlays</wordasword>. For
<wordasword>destructive Video Overlays</wordasword> applications must
provide a base address. The driver may accept only base addresses
which are a multiple of two, four or eight bytes. For
<wordasword>Video Output Overlays</wordasword> the driver must return
a valid base address, so applications can find the corresponding Linux
-framebuffer device (see <xref linkend="osd">).</para></entry>
+framebuffer device (see <xref linkend="osd">).</entry>
</row>
<row>
<entry>&v4l2-pix-format;</entry>
@@ -171,23 +176,39 @@ linkend="pixfmt">, for clarification the
<entry></entry>
<entry>__u32</entry>
<entry><structfield>pixelformat</structfield></entry>
- <entry><para>The pixel format of the
-framebuffer.</para><para>For <wordasword>non-destructive Video
+ <entry>The pixel format of the
+framebuffer.</entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry>For <wordasword>non-destructive Video
Overlays</wordasword> this field only defines a format for the
-&v4l2-window; <structfield>chromakey</structfield>
-field.</para><para>For <wordasword>destructive Video
+&v4l2-window; <structfield>chromakey</structfield> field.</entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry>For <wordasword>destructive Video
Overlays</wordasword> applications must initialize this field. For
<wordasword>Video Output Overlays</wordasword> the driver must return
-a valid format.</para><para>Usually this is an RGB format (for example
-<link
-linkend="V4L2-PIX-FMT-RGB565"><constant>V4L2_PIX_FMT_RGB565</constant></link>)
+a valid format.</entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry></entry>
+ <entry></entry>
+ <entry>Usually this is an RGB format (for example
+<link
linkend="V4L2-PIX-FMT-RGB565"><constant>V4L2_PIX_FMT_RGB565</constant></link>)
but YUV formats (only packed YUV formats when chroma keying is used,
not including <constant>V4L2_PIX_FMT_YUYV</constant> and
<constant>V4L2_PIX_FMT_UYVY</constant>) and the
<constant>V4L2_PIX_FMT_PAL8</constant> format are also permitted. The
behavior of the driver when an application requests a compressed
format is undefined. See <xref linkend="pixfmt"> for information on
-pixel formats.</para></entry>
+pixel formats.</entry>
</row>
<row>
<entry></entry>
---
Patch is available at:
http://linuxtv.org/hg/v4l-dvb/rev/ab72ec45d16e1c6e1991743ea9ee7e442d1a6f4e
_______________________________________________
linuxtv-commits mailing list
linuxtv-commits@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linuxtv-commits
