diff options
Diffstat (limited to 'v4l2-spec')
| -rw-r--r-- | v4l2-spec/dev-overlay.sgml | 16 | ||||
| -rw-r--r-- | v4l2-spec/vidioc-g-fbuf.sgml | 45 |
2 files changed, 44 insertions, 17 deletions
diff --git a/v4l2-spec/dev-overlay.sgml b/v4l2-spec/dev-overlay.sgml index 0eadd1611..be56fc594 100644 --- a/v4l2-spec/dev-overlay.sgml +++ b/v4l2-spec/dev-overlay.sgml @@ -214,7 +214,9 @@ applications can set this field to point to an array of 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 all.</para> <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 --git a/v4l2-spec/vidioc-g-fbuf.sgml b/v4l2-spec/vidioc-g-fbuf.sgml index 65f597100..6781b5334 100644 --- a/v4l2-spec/vidioc-g-fbuf.sgml +++ b/v4l2-spec/vidioc-g-fbuf.sgml @@ -131,20 +131,25 @@ driver, see <xref linkend="framebuffer-flags"></entry> <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 fields and acceptable values <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> |