Re: [Linux-fbdev-devel] [PATCH] OMAP 2/3 V4L2 display driver on video planes

[Geert Uytterhoeven <geert@linux-m68k.org>]

On Mon, 6 Oct 2008, Shah, Hardik wrote:
> > -----Original Message-----
> > From: Hans Verkuil [mailto:hverkuil@xs4all.nl]
> > On Monday 06 October 2008 08:06:30 Shah, Hardik wrote:
> > > > -----Original Message-----
> > > > From: Mauro Carvalho Chehab [mailto:mchehab@infradead.org]
> > > 4.  VIDIOC_S/G_OMAP2_COLORKEY:  Color keying allows the pixels with
> > > the defined color on the video pipelines to be replaced with the
> > > pixels on the graphics pipelines.  I believe similar feature must be
> > > available on almost all next generation of video hardware. We can add
> > > new ioctl for this feature in V4L2 framework. I think VIDIOC_S_FBUF
> > > ioctl is used for setting up the buffer parameters on per buffer
> > > basis.  So IMHO this ioctl is not a natural fit for the above
> > > functionality. Please provide your comments on same.
> > 
> > Do I understand correctly that if the color in the *video* streams
> > matches the colorkey, then it is replaced by the color in the
> > *framebuffer* (aka menu/overlay)? Usually it is the other way around:
> > if the framebuffer (menu) has chromakey pixels, then those pixels are
> > replaced by pixels from the video stream. That's what the current API
> > does
> [Shah, Hardik] This is a hardware provided feature. It can be both ways as
> hardware supports both the features. It means replacing the graphics
> pipelines pixels with video pipeline pixels and other way is also true.
> When both graphics and video pipelines are going to the same output device
> and when the colorkeying is enabled then the pixels of the video pipelines
> of specific color are replaced by the pixels of the graphics pipeline.
> This is done automatically done by the overlay manager aka compositor.
> Graphics pipeline can be controlled by frame buffer interface or V4L2
> interface.
> In driver we only need to enable the color keying and state that whether
> it is a source color keying or destination color keying along with the
> color code.

As video input usually contains noise: is it an exact color match, or a
range? IIRC, I saw a similar feature on a different chip some years ago,
and there the color key was a (YCbCr) range.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds