From 8f85ebb446130d67e0b6f8a8a6ac48451843beaf Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Thu, 22 Jan 2009 08:52:53 +0100 Subject: v4l2-spec: fix some table alignment problems From: Hans Verkuil Priority: normal Signed-off-by: Hans Verkuil --- v4l2-spec/dev-overlay.sgml | 16 +++++++++++----- 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. - Like the window coordinates + + + Like the window coordinates w, 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. __u8 global_alpha - The global alpha value used to blend the + The global alpha value used to blend the framebuffer with video images, if global alpha blending has been negotiated (V4L2_FBUF_FLAG_GLOBAL_ALPHA, see -&VIDIOC-S-FBUF;, ).Note -this field was added in Linux 2.6.23, extending the structure. However +&VIDIOC-S-FBUF;, ). + + + + + Note this field was added in Linux 2.6.23, extending the structure. However the VIDIOC_G/S/TRY_FMT ioctls, which take a pointer to a v4l2_format parent structure with padding -bytes at the end, are not affected. +bytes at the end, are not affected. 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 void * base - Physical base address of the framebuffer, + Physical base address of the framebuffer, that is the address of the pixel in the top left corner of the framebuffer.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;.This field is irrelevant to +discuss on the linux-media mailing list: &v4l-ml;. + + + + + + This field is irrelevant to non-destructive Video Overlays. For destructive Video Overlays applications must provide a base address. The driver may accept only base addresses which are a multiple of two, four or eight bytes. For Video Output Overlays the driver must return a valid base address, so applications can find the corresponding Linux -framebuffer device (see ). +framebuffer device (see ). &v4l2-pix-format; @@ -171,23 +176,39 @@ linkend="pixfmt">, for clarification the fields and acceptable values __u32 pixelformat - The pixel format of the -framebuffer.For non-destructive Video + The pixel format of the +framebuffer. + + + + + + For non-destructive Video Overlays this field only defines a format for the -&v4l2-window; chromakey -field.For destructive Video +&v4l2-window; chromakey field. + + + + + + For destructive Video Overlays applications must initialize this field. For Video Output Overlays the driver must return -a valid format.Usually this is an RGB format (for example -V4L2_PIX_FMT_RGB565) +a valid format. + + + + + + Usually this is an RGB format (for example +V4L2_PIX_FMT_RGB565) but YUV formats (only packed YUV formats when chroma keying is used, not including V4L2_PIX_FMT_YUYV and V4L2_PIX_FMT_UYVY) and the V4L2_PIX_FMT_PAL8 format are also permitted. The behavior of the driver when an application requests a compressed format is undefined. See for information on -pixel formats. +pixel formats. -- cgit v1.2.3