On Tuesday 27 January 2009 15:09:34 Shah, Hardik wrote: > > -----Original Message----- > > From: Hans Verkuil [mailto:hverkuil@xxxxxxxxx] > > Sent: Tuesday, January 27, 2009 6:38 PM > > To: Shah, Hardik > > Cc: linux-media@xxxxxxxxxxxxxxx; video4linux-list@xxxxxxxxxx > > Subject: Re: [RFC] Adding new ioctl for transparency color keying > > > > On Tuesday 27 January 2009 13:53:23 Shah, Hardik wrote: > > > > -----Original Message----- > > > > From: Hans Verkuil [mailto:hverkuil@xxxxxxxxx] > > > > Sent: Tuesday, January 27, 2009 3:21 PM > > > > To: Shah, Hardik > > > > Cc: linux-media@xxxxxxxxxxxxxxx; video4linux-list@xxxxxxxxxx > > > > Subject: Re: [RFC] Adding new ioctl for transparency color keying > > > > > > > > Hi Hardik, > > > > > > > > On Thursday 22 January 2009 05:57:18 Shah, Hardik wrote: > > > > > Hi, > > > > > OMAP class of device supports transparency color keying. Color > > > > > keying can be source color keying or destination color keying. > > > > > > > > Can it be both as well? > > > > > > > > > OMAP3 has three pipelines one graphics plane and two video > > > > > planes. Any of these pipelines can go to either the TV or LCD. > > > > > > > > > > The destination transparency color key value defines the encoded > > > > > pixels in the graphics layer to become transparent and display > > > > > the underlying video pixels. While the source transparency key > > > > > value defines the encoded pixels in the video layer to become > > > > > transparent and display the underlying graphics pixels. This > > > > > color keying works only if the video and graphics planes are on > > > > > the same output like TV or LCD and images of both the pipelines > > > > > overlapped. > > > > > > > > > > I propose to have the one ioctl to set the encoded pixel value > > > > > and type of color keying source and destination. Also we should > > > > > have the CID to enable/disable the color keying functionality. > > > > > > > > > > Please let us know your opinions/comments. > > > > > > > > Destination color keying is already available through the S_FBUF > > > > and S_FMT ioctls. Selecting source color keying can easily be added > > > > to S_FBUF, but setting the actual chromakey is harder. The logical > > > > place would be the v4l2_pix_format struct, but that is already > > > > full. I guess we should make a new control to set the source > > > > chromakey. It's not ideal, but it prevents duplicating existing > > > > functionality. > > > > > > [Shah, Hardik] Hi Hans, > > > This has nothing to do with the frame buffer. Transparency key is a > > > hardware provided feature. Driver has just to give the color code > > > and whether it wants the source color keying or destination color > > > keying. Hardware will automatically make the color code transparent > > > so that the below layer color will be seen. So I don't think so that > > > S_FBUF is suitable for this kind of feature. And this will > > > automatically take effect if the graphics pipeline is on the same > > > output device as the video pipeline. > > > > Why has this nothing to do with the framebuffer? Isn't there a /dev/fbX > > device for the graphics framebuffer? If there is, then it is exactly as > > I described: a video output overlay (aka OSD). Do not confuse this with > > a video overlay which is used to accelerate displaying captured video. > > > > See also: > > > > http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec- > > single/v4l2.html#OSD > > [Shah, Hardik] Hi Hans, > Here the graphics node is created for the graphics pipeline. And graphics > pipeline will be controlled by the graphics node /dev/fbx. Application > will set the desired pixel format for the /dev/fbx node and > /dev/v4l/videox node. After that application can select that same output > device for both the nodes. And then user may want to make transparent > either the color from the video pipeline of the graphics pipeline. In > any case application will not require frame buffer parameters like base > address of the buffer as the blending/transparency processing will not be > done in driver. It will be done by hardware by setting the appropriate > register bits. So do you think that S_FBUF is required? Please let me > know if I am missing something. If you want I can forward you the link > referring to the Technical reference manual explaining the color keying > in hardware. Yes, this is exactly the same as is implemented for ivtv: ivtvfb is the framebuffer driver for the OSD and ivtv implements G/S_FBUF to set the framebuffer parameters like chromakeying. Note that the fb.h API knows nothing about video, so that cannot be used to set chromakeys and such. This has to be done from the V4L2 API. And the struct v4l2_framebuffer passed to VIDIOC_G/S_FBUF is how you do it. The capability field tells you what the device supports in the way of clipping and transparencies. The flags field lets the application select how to do e.g. transparency. The base field can be used in the case of OSDs to discover with fbX device belongs to the video device. Section 4.4.2 in the V4L2 spec shows how to do that. And finally the fmt field will tell you how the framebuffer is organized. Through VIDIOC_S_FMT and struct v4l2_window you can set the chromakey and other clipping/transparency data. So through VIDIOC_S_FBUF you select the type of chromakeying and through VIDIOC_S_FMT you actually set the chromakey. Except that we currently have no way to set the source chromakey, that's missing in the API. Everything else is there already. And these ioctls are all for hardware transparency processing, the implementation in the driver is always to set the various hardware registers according to the arguments. Regards, Hans > > Regards, > Hardik Shah > > > Regards, > > > > Hans > > > > -- > > Hans Verkuil - video4linux developer - sponsored by TANDBERG -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
