diff options
Diffstat (limited to 'v4l2-spec/vidioc-g-fbuf.sgml')
| -rw-r--r-- | v4l2-spec/vidioc-g-fbuf.sgml | 45 |
1 files changed, 33 insertions, 12 deletions
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> |