Message ID | 1257864345-13595-1-git-send-email-hvaibhav@ti.com (mailing list archive) |
---|---|
State | Superseded, archived |
Headers |
Return-path: <linux-media-owner@vger.kernel.org> Envelope-to: mchehab@infradead.org Delivery-date: Tue, 10 Nov 2009 14:45:53 +0000 Received: from bombadil.infradead.org [18.85.46.34] by pedra.chehab.org with IMAP (fetchmail-6.3.6) for <mchehab@localhost> (single-drop); Tue, 10 Nov 2009 12:46:45 -0200 (BRST) Received: from vger.kernel.org ([209.132.176.167]) by bombadil.infradead.org with esmtp (Exim 4.69 #1 (Red Hat Linux)) id 1N7ryi-00077N-SE; Tue, 10 Nov 2009 14:45:53 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756372AbZKJOpq (ORCPT <rfc822; kmpark@infradead.org> + 1 other); Tue, 10 Nov 2009 09:45:46 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756545AbZKJOpq (ORCPT <rfc822;linux-media-outgoing>); Tue, 10 Nov 2009 09:45:46 -0500 Received: from devils.ext.ti.com ([198.47.26.153]:37376 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756309AbZKJOpp (ORCPT <rfc822;linux-media@vger.kernel.org>); Tue, 10 Nov 2009 09:45:45 -0500 Received: from dbdp31.itg.ti.com ([172.24.170.98]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id nAAEjlUk021129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <linux-media@vger.kernel.org>; Tue, 10 Nov 2009 08:45:50 -0600 Received: from localhost.localdomain (localhost [127.0.0.1]) by dbdp31.itg.ti.com (8.13.8/8.13.8) with ESMTP id nAAEjjMn009725; Tue, 10 Nov 2009 20:15:46 +0530 (IST) From: hvaibhav@ti.com To: linux-media@vger.kernel.org Cc: Vaibhav Hiremath <hvaibhav@ti.com> Subject: [PATCH] v4l2 doc: Added FBUF_CAP_SRC_CHROMAKEY/FLAG_SRC_CHROMAKEY Date: Tue, 10 Nov 2009 20:15:45 +0530 Message-Id: <1257864345-13595-1-git-send-email-hvaibhav@ti.com> X-Mailer: git-send-email 1.6.2.4 In-Reply-To: <hvaibhav@ti.com> References: <hvaibhav@ti.com> Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org |
Commit Message
Hiremath, Vaibhav
Nov. 10, 2009, 2:45 p.m. UTC
From: Vaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> --- linux/Documentation/DocBook/v4l/videodev2.h.xml | 2 ++ linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml | 17 +++++++++++++++++ 2 files changed, 19 insertions(+), 0 deletions(-)
Comments
Hi Vaibhav! This is a bit of a 'blast from the past', but when I went through the documentation of the framebuffer flags in the V4L2 spec I noticed that the definition of V4L2_FBUF_CAP_SRC_CHROMAKEY seemed to be wrong. The definition of V4L2_FBUF_CAP_CHROMAKEY says: 'The device supports clipping by chroma-keying the images. That is, image pixels replace pixels in the VGA or video signal only where the latter assume a certain color. Chroma-keying makes no sense for destructive overlays.' The definition of V4L2_FBUF_CAP_SRC_CHROMAKEY says: '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.' As far as I can tell these definitions are really the same. I would expect that V4L2_FBUF_CAP_SRC_CHROMAKEY was defined as: 'The device supports Source Chroma-keying. Video pixels with the chroma-key colors are replaced by framebuffer pixels, which is exactly opposite of V4L2_FBUF_CAP_CHROMAKEY.' The only driver that implements this is omap_vout.c. So is the mistake in the documentation or in the driver? I think the documentation is wrong in this case. Regards, Hans On Tuesday, November 10, 2009 15:45:45 hvaibhav@ti.com wrote: > From: Vaibhav Hiremath <hvaibhav@ti.com> > > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> > --- > linux/Documentation/DocBook/v4l/videodev2.h.xml | 2 ++ > linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml | 17 +++++++++++++++++ > 2 files changed, 19 insertions(+), 0 deletions(-) > > diff --git a/linux/Documentation/DocBook/v4l/videodev2.h.xml b/linux/Documentation/DocBook/v4l/videodev2.h.xml > index 9700206..eef7ba4 100644 > --- a/linux/Documentation/DocBook/v4l/videodev2.h.xml > +++ b/linux/Documentation/DocBook/v4l/videodev2.h.xml > @@ -565,6 +565,7 @@ struct <link linkend="v4l2-framebuffer">v4l2_framebuffer</link> { > #define V4L2_FBUF_CAP_LOCAL_ALPHA 0x0010 > #define V4L2_FBUF_CAP_GLOBAL_ALPHA 0x0020 > #define V4L2_FBUF_CAP_LOCAL_INV_ALPHA 0x0040 > +#define V4L2_FBUF_CAP_SRC_CHROMAKEY 0x0080 > /* Flags for the 'flags' field. */ > #define V4L2_FBUF_FLAG_PRIMARY 0x0001 > #define V4L2_FBUF_FLAG_OVERLAY 0x0002 > @@ -572,6 +573,7 @@ struct <link linkend="v4l2-framebuffer">v4l2_framebuffer</link> { > #define V4L2_FBUF_FLAG_LOCAL_ALPHA 0x0008 > #define V4L2_FBUF_FLAG_GLOBAL_ALPHA 0x0010 > #define V4L2_FBUF_FLAG_LOCAL_INV_ALPHA 0x0020 > +#define V4L2_FBUF_FLAG_SRC_CHROMAKEY 0x0040 > > struct <link linkend="v4l2-clip">v4l2_clip</link> { > struct <link linkend="v4l2-rect">v4l2_rect</link> c; > diff --git a/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml b/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml > index f701706..e7dda48 100644 > --- a/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml > +++ b/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml > @@ -336,6 +336,13 @@ alpha value. Alpha blending makes no sense for destructive overlays.</entry> > inverted alpha channel of the framebuffer or VGA signal. Alpha > blending makes no sense for destructive overlays.</entry> > </row> > + <row> > + <entry><constant>V4L2_FBUF_CAP_SRC_CHROMAKEY</constant></entry> > + <entry>0x0080</entry> > + <entry>The device supports Source Chroma-keying. Framebuffer pixels > +with the chroma-key colors are replaced by video pixels, which is exactly opposite of > +<constant>V4L2_FBUF_CAP_CHROMAKEY</constant></entry> > + </row> > </tbody> > </tgroup> > </table> > @@ -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.</entry> > </row> > + <row> > + <entry><constant>V4L2_FBUF_FLAG_SRC_CHROMAKEY</constant></entry> > + <entry>0x0040</entry> > + <entry>Use source chroma-keying. The source chroma-key color is > +determined by the <structfield>chromakey</structfield> field of > +&v4l2-window; and negotiated with the &VIDIOC-S-FMT; ioctl, see <xref > +linkend="overlay" /> and <xref linkend="osd" />. > +Both chroma-keying are mutual exclusive to each other, so same > +<structfield>chromakey</structfield> field of &v4l2-window; is being used.</entry> > + </row> > </tbody> > </tgroup> > </table> > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Hans Verkuil [mailto:hverkuil@xs4all.nl] > Sent: Monday, November 07, 2011 7:06 PM > To: Hiremath, Vaibhav > Cc: linux-media@vger.kernel.org > Subject: Re: [PATCH] v4l2 doc: Added > FBUF_CAP_SRC_CHROMAKEY/FLAG_SRC_CHROMAKEY > > Hi Vaibhav! > > This is a bit of a 'blast from the past', but when I went through the > documentation of the framebuffer flags in the V4L2 spec I noticed that the > definition of V4L2_FBUF_CAP_SRC_CHROMAKEY seemed to be wrong. > > The definition of V4L2_FBUF_CAP_CHROMAKEY says: > > 'The device supports clipping by chroma-keying the > images. That is, image pixels replace pixels in the VGA or video > signal only where the latter assume a certain color. Chroma-keying > makes no sense for destructive overlays.' > > The definition of V4L2_FBUF_CAP_SRC_CHROMAKEY says: > > '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.' > > As far as I can tell these definitions are really the same. I would expect > that V4L2_FBUF_CAP_SRC_CHROMAKEY was defined as: > > 'The device supports Source Chroma-keying. Video pixels > with the chroma-key colors are replaced by framebuffer pixels, which > is exactly opposite of V4L2_FBUF_CAP_CHROMAKEY.' > > The only driver that implements this is omap_vout.c. So is the mistake > in the documentation or in the driver? I think the documentation is wrong > in this case. > I remember long time back we had discussion on this, we consider V4L2_FBUF_CAP_CHROMAKEY as a destination color keying (term used in OMAP spec) and V4L2_FBUF_CAP_SRC_CHROMAKEY as a source color keying(term used in OMAP spec). As per OMAP spec the source color key is, replace video pixels by underneath gfx pixels based on chroma-key color. I think we aligned in this at that time, isn't it? AM I missing something? FYI, as per OMAP spec, Destination color keying: The graphics destination transparency color key value defines the encoded pixels in the video layers to be displayed. The encoded pixel values with the destination color key value are pixels not visible on the screen and the pixels different from the transparency color key are displayed over the video layers. The destination transparency color key is applicable only in the graphics region when graphics and video overlap; otherwise, the destination transparency color key is ignored. Source color keying: The video source transparency color key value defines the encoded pixel data considered as the transparent pixel. The encoded pixel values with the source color key value are pixels not visible on the screen, and the underlayer encoded pixel values or solid background color are visible. Thanks, Vaibhav > Regards, > > Hans > > On Tuesday, November 10, 2009 15:45:45 hvaibhav@ti.com wrote: > > From: Vaibhav Hiremath <hvaibhav@ti.com> > > > > > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> > > --- > > linux/Documentation/DocBook/v4l/videodev2.h.xml | 2 ++ > > linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml | 17 > +++++++++++++++++ > > 2 files changed, 19 insertions(+), 0 deletions(-) > > > > diff --git a/linux/Documentation/DocBook/v4l/videodev2.h.xml > b/linux/Documentation/DocBook/v4l/videodev2.h.xml > > index 9700206..eef7ba4 100644 > > --- a/linux/Documentation/DocBook/v4l/videodev2.h.xml > > +++ b/linux/Documentation/DocBook/v4l/videodev2.h.xml > > @@ -565,6 +565,7 @@ struct <link linkend="v4l2- > framebuffer">v4l2_framebuffer</link> { > > #define V4L2_FBUF_CAP_LOCAL_ALPHA 0x0010 > > #define V4L2_FBUF_CAP_GLOBAL_ALPHA 0x0020 > > #define V4L2_FBUF_CAP_LOCAL_INV_ALPHA 0x0040 > > +#define V4L2_FBUF_CAP_SRC_CHROMAKEY 0x0080 > > /* Flags for the 'flags' field. */ > > #define V4L2_FBUF_FLAG_PRIMARY 0x0001 > > #define V4L2_FBUF_FLAG_OVERLAY 0x0002 > > @@ -572,6 +573,7 @@ struct <link linkend="v4l2- > framebuffer">v4l2_framebuffer</link> { > > #define V4L2_FBUF_FLAG_LOCAL_ALPHA 0x0008 > > #define V4L2_FBUF_FLAG_GLOBAL_ALPHA 0x0010 > > #define V4L2_FBUF_FLAG_LOCAL_INV_ALPHA 0x0020 > > +#define V4L2_FBUF_FLAG_SRC_CHROMAKEY 0x0040 > > > > struct <link linkend="v4l2-clip">v4l2_clip</link> { > > struct <link linkend="v4l2-rect">v4l2_rect</link> c; > > diff --git a/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml > b/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml > > index f701706..e7dda48 100644 > > --- a/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml > > +++ b/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml > > @@ -336,6 +336,13 @@ alpha value. Alpha blending makes no sense for > destructive overlays.</entry> > > inverted alpha channel of the framebuffer or VGA signal. Alpha > > blending makes no sense for destructive overlays.</entry> > > </row> > > + <row> > > + <entry><constant>V4L2_FBUF_CAP_SRC_CHROMAKEY</constant></entry> > > + <entry>0x0080</entry> > > + <entry>The device supports Source Chroma-keying. Framebuffer > pixels > > +with the chroma-key colors are replaced by video pixels, which is > exactly opposite of > > +<constant>V4L2_FBUF_CAP_CHROMAKEY</constant></entry> > > + </row> > > </tbody> > > </tgroup> > > </table> > > @@ -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.</entry> > > </row> > > + <row> > > + <entry><constant>V4L2_FBUF_FLAG_SRC_CHROMAKEY</constant></entry> > > + <entry>0x0040</entry> > > + <entry>Use source chroma-keying. The source chroma-key color is > > +determined by the <structfield>chromakey</structfield> field of > > +&v4l2-window; and negotiated with the &VIDIOC-S-FMT; ioctl, see <xref > > +linkend="overlay" /> and <xref linkend="osd" />. > > +Both chroma-keying are mutual exclusive to each other, so same > > +<structfield>chromakey</structfield> field of &v4l2-window; is being > used.</entry> > > + </row> > > </tbody> > > </tgroup> > > </table> > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday, November 08, 2011 12:46:32 Hiremath, Vaibhav wrote: > > -----Original Message----- > > From: Hans Verkuil [mailto:hverkuil@xs4all.nl] > > Sent: Monday, November 07, 2011 7:06 PM > > To: Hiremath, Vaibhav > > Cc: linux-media@vger.kernel.org > > Subject: Re: [PATCH] v4l2 doc: Added > > FBUF_CAP_SRC_CHROMAKEY/FLAG_SRC_CHROMAKEY > > > > Hi Vaibhav! > > > > This is a bit of a 'blast from the past', but when I went through the > > documentation of the framebuffer flags in the V4L2 spec I noticed that the > > definition of V4L2_FBUF_CAP_SRC_CHROMAKEY seemed to be wrong. > > > > The definition of V4L2_FBUF_CAP_CHROMAKEY says: > > > > 'The device supports clipping by chroma-keying the > > images. That is, image pixels replace pixels in the VGA or video > > signal only where the latter assume a certain color. Chroma-keying > > makes no sense for destructive overlays.' > > > > The definition of V4L2_FBUF_CAP_SRC_CHROMAKEY says: > > > > '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.' > > > > As far as I can tell these definitions are really the same. I would expect > > that V4L2_FBUF_CAP_SRC_CHROMAKEY was defined as: > > > > 'The device supports Source Chroma-keying. Video pixels > > with the chroma-key colors are replaced by framebuffer pixels, which > > is exactly opposite of V4L2_FBUF_CAP_CHROMAKEY.' > > > > The only driver that implements this is omap_vout.c. So is the mistake > > in the documentation or in the driver? I think the documentation is wrong > > in this case. > > > I remember long time back we had discussion on this, we consider > V4L2_FBUF_CAP_CHROMAKEY as a destination color keying (term used in OMAP > spec) and V4L2_FBUF_CAP_SRC_CHROMAKEY as a source color keying(term used in > OMAP spec). > > As per OMAP spec the source color key is, replace video pixels by underneath gfx pixels based on chroma-key color. I think we aligned in this at that time, isn't it? AM I missing something? No, just that the current definition in the spec for V4L2_FBUF_CAP_SRC_CHROMAKEY is indeed the wrong way around. It should read: 'The device supports Source Chroma-keying. Video pixels with the chroma-key colors are replaced by framebuffer pixels, which is exactly opposite of V4L2_FBUF_CAP_CHROMAKEY.' I'll make a patch fixing this. Regards, Hans > > > FYI, as per OMAP spec, > > Destination color keying: > The graphics destination transparency color key value defines the encoded > pixels in the video layers to be displayed. The encoded pixel values with > the destination color key value are pixels not visible on the screen and the > pixels different from the transparency color key are displayed over the > video layers. The destination transparency color key is applicable only in > the graphics region when graphics and video overlap; otherwise, the > destination transparency color key is ignored. > > > Source color keying: > The video source transparency color key value defines the encoded pixel data > considered as the transparent pixel. The encoded pixel values with the > source color key value are pixels not visible on the screen, and the > underlayer encoded pixel values or solid background color are visible. > > > Thanks, > Vaibhav > > > Regards, > > > > Hans > > > > On Tuesday, November 10, 2009 15:45:45 hvaibhav@ti.com wrote: > > > From: Vaibhav Hiremath <hvaibhav@ti.com> > > > > > > > > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> > > > --- > > > linux/Documentation/DocBook/v4l/videodev2.h.xml | 2 ++ > > > linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml | 17 > > +++++++++++++++++ > > > 2 files changed, 19 insertions(+), 0 deletions(-) > > > > > > diff --git a/linux/Documentation/DocBook/v4l/videodev2.h.xml > > b/linux/Documentation/DocBook/v4l/videodev2.h.xml > > > index 9700206..eef7ba4 100644 > > > --- a/linux/Documentation/DocBook/v4l/videodev2.h.xml > > > +++ b/linux/Documentation/DocBook/v4l/videodev2.h.xml > > > @@ -565,6 +565,7 @@ struct <link linkend="v4l2- > > framebuffer">v4l2_framebuffer</link> { > > > #define V4L2_FBUF_CAP_LOCAL_ALPHA 0x0010 > > > #define V4L2_FBUF_CAP_GLOBAL_ALPHA 0x0020 > > > #define V4L2_FBUF_CAP_LOCAL_INV_ALPHA 0x0040 > > > +#define V4L2_FBUF_CAP_SRC_CHROMAKEY 0x0080 > > > /* Flags for the 'flags' field. */ > > > #define V4L2_FBUF_FLAG_PRIMARY 0x0001 > > > #define V4L2_FBUF_FLAG_OVERLAY 0x0002 > > > @@ -572,6 +573,7 @@ struct <link linkend="v4l2- > > framebuffer">v4l2_framebuffer</link> { > > > #define V4L2_FBUF_FLAG_LOCAL_ALPHA 0x0008 > > > #define V4L2_FBUF_FLAG_GLOBAL_ALPHA 0x0010 > > > #define V4L2_FBUF_FLAG_LOCAL_INV_ALPHA 0x0020 > > > +#define V4L2_FBUF_FLAG_SRC_CHROMAKEY 0x0040 > > > > > > struct <link linkend="v4l2-clip">v4l2_clip</link> { > > > struct <link linkend="v4l2-rect">v4l2_rect</link> c; > > > diff --git a/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml > > b/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml > > > index f701706..e7dda48 100644 > > > --- a/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml > > > +++ b/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml > > > @@ -336,6 +336,13 @@ alpha value. Alpha blending makes no sense for > > destructive overlays.</entry> > > > inverted alpha channel of the framebuffer or VGA signal. Alpha > > > blending makes no sense for destructive overlays.</entry> > > > </row> > > > + <row> > > > + <entry><constant>V4L2_FBUF_CAP_SRC_CHROMAKEY</constant></entry> > > > + <entry>0x0080</entry> > > > + <entry>The device supports Source Chroma-keying. Framebuffer > > pixels > > > +with the chroma-key colors are replaced by video pixels, which is > > exactly opposite of > > > +<constant>V4L2_FBUF_CAP_CHROMAKEY</constant></entry> > > > + </row> > > > </tbody> > > > </tgroup> > > > </table> > > > @@ -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.</entry> > > > </row> > > > + <row> > > > + <entry><constant>V4L2_FBUF_FLAG_SRC_CHROMAKEY</constant></entry> > > > + <entry>0x0040</entry> > > > + <entry>Use source chroma-keying. The source chroma-key color is > > > +determined by the <structfield>chromakey</structfield> field of > > > +&v4l2-window; and negotiated with the &VIDIOC-S-FMT; ioctl, see <xref > > > +linkend="overlay" /> and <xref linkend="osd" />. > > > +Both chroma-keying are mutual exclusive to each other, so same > > > +<structfield>chromakey</structfield> field of &v4l2-window; is being > > used.</entry> > > > + </row> > > > </tbody> > > > </tgroup> > > > </table> > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/linux/Documentation/DocBook/v4l/videodev2.h.xml b/linux/Documentation/DocBook/v4l/videodev2.h.xml index 9700206..eef7ba4 100644 --- a/linux/Documentation/DocBook/v4l/videodev2.h.xml +++ b/linux/Documentation/DocBook/v4l/videodev2.h.xml @@ -565,6 +565,7 @@ struct <link linkend="v4l2-framebuffer">v4l2_framebuffer</link> { #define V4L2_FBUF_CAP_LOCAL_ALPHA 0x0010 #define V4L2_FBUF_CAP_GLOBAL_ALPHA 0x0020 #define V4L2_FBUF_CAP_LOCAL_INV_ALPHA 0x0040 +#define V4L2_FBUF_CAP_SRC_CHROMAKEY 0x0080 /* Flags for the 'flags' field. */ #define V4L2_FBUF_FLAG_PRIMARY 0x0001 #define V4L2_FBUF_FLAG_OVERLAY 0x0002 @@ -572,6 +573,7 @@ struct <link linkend="v4l2-framebuffer">v4l2_framebuffer</link> { #define V4L2_FBUF_FLAG_LOCAL_ALPHA 0x0008 #define V4L2_FBUF_FLAG_GLOBAL_ALPHA 0x0010 #define V4L2_FBUF_FLAG_LOCAL_INV_ALPHA 0x0020 +#define V4L2_FBUF_FLAG_SRC_CHROMAKEY 0x0040 struct <link linkend="v4l2-clip">v4l2_clip</link> { struct <link linkend="v4l2-rect">v4l2_rect</link> c; diff --git a/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml b/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml index f701706..e7dda48 100644 --- a/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml +++ b/linux/Documentation/DocBook/v4l/vidioc-g-fbuf.xml @@ -336,6 +336,13 @@ alpha value. Alpha blending makes no sense for destructive overlays.</entry> inverted alpha channel of the framebuffer or VGA signal. Alpha blending makes no sense for destructive overlays.</entry> </row> + <row> + <entry><constant>V4L2_FBUF_CAP_SRC_CHROMAKEY</constant></entry> + <entry>0x0080</entry> + <entry>The device supports Source Chroma-keying. Framebuffer pixels +with the chroma-key colors are replaced by video pixels, which is exactly opposite of +<constant>V4L2_FBUF_CAP_CHROMAKEY</constant></entry> + </row> </tbody> </tgroup> </table> @@ -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.</entry> </row> + <row> + <entry><constant>V4L2_FBUF_FLAG_SRC_CHROMAKEY</constant></entry> + <entry>0x0040</entry> + <entry>Use source chroma-keying. The source chroma-key color is +determined by the <structfield>chromakey</structfield> field of +&v4l2-window; and negotiated with the &VIDIOC-S-FMT; ioctl, see <xref +linkend="overlay" /> and <xref linkend="osd" />. +Both chroma-keying are mutual exclusive to each other, so same +<structfield>chromakey</structfield> field of &v4l2-window; is being used.</entry> + </row> </tbody> </tgroup> </table>