From 2b2c1ab7e57020630689626bb0896a1bfd1df4d5 Mon Sep 17 00:00:00 2001 From: Vaibhav Hiremath Date: Tue, 10 Nov 2009 13:14:51 -0300 Subject: [PATCH] --- yaml --- r: 174168 b: refs/heads/master c: a4834cef185fbe73f26c864fe38badc4f890afb7 h: refs/heads/master v: v3 --- [refs] | 2 +- .../Documentation/DocBook/v4l/vidioc-g-fbuf.xml | 17 +++++++++++++++++ 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/[refs] b/[refs] index c60569f94a20..99a8706cd3d2 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: d8008562379b927758ca08eded1508c68d9beb4e +refs/heads/master: a4834cef185fbe73f26c864fe38badc4f890afb7 diff --git a/trunk/Documentation/DocBook/v4l/vidioc-g-fbuf.xml b/trunk/Documentation/DocBook/v4l/vidioc-g-fbuf.xml index f7017062656e..e7dda4822f04 100644 --- a/trunk/Documentation/DocBook/v4l/vidioc-g-fbuf.xml +++ b/trunk/Documentation/DocBook/v4l/vidioc-g-fbuf.xml @@ -336,6 +336,13 @@ alpha value. Alpha blending makes no sense for destructive overlays. inverted alpha channel of the framebuffer or VGA signal. Alpha blending makes no sense for destructive overlays. + + V4L2_FBUF_CAP_SRC_CHROMAKEY + 0x0080 + The device supports Source Chroma-keying. Framebuffer pixels +with the chroma-key colors are replaced by video pixels, which is exactly opposite of +V4L2_FBUF_CAP_CHROMAKEY + @@ -411,6 +418,16 @@ images, but with an inverted alpha value. The blend function is: output = framebuffer pixel * (1 - alpha) + video pixel * alpha. The actual alpha depth depends on the framebuffer pixel format. + + V4L2_FBUF_FLAG_SRC_CHROMAKEY + 0x0040 + Use source chroma-keying. The source chroma-key color is +determined by the chromakey field of +&v4l2-window; and negotiated with the &VIDIOC-S-FMT; ioctl, see and . +Both chroma-keying are mutual exclusive to each other, so same +chromakey field of &v4l2-window; is being used. +