Re: [Linux-fbdev-devel] Re: fbdev, console, (video) overlay/underlay & fbtv

[Sven <lu...@dp...>]

Sorry if i lost older mails regarding this, but i just lost my harddisk here at work yesterday
and just got the replacement today. So i must have lost all incoming mails since monday or such.

On Wed, Jul 11, 2001 at 03:51:07PM +0200, Gerd Knorr wrote:
> > /* get the hardware capability. get a 'struct fb_vidoverlay_avail' as output from the driver */ 
> > #define FBIOGET_VIDOVERLAY_CAP        0x4620
> 
> Better use the _IOR / _IOW / _IOWR macros.
> 
> > /* pixel type that can be overlaid */
> > #define FB_VIDOVERLAY_PIXELTYPE_CI8     0x0020
> 
> What is this one?

Color Index 8, it is just like the pseudocolor 8bpp used by fbdev. I think maybe we could reuse
the same color indentification as FB use, without the need of FB_VIDOVERLAY stuff ? Or is adding
all the YUV modes there a problem ?

> > #define FB_VIDOVERLAY_PIXELTYPE_YUV422  0x0040
> > #define FB_VIDOVERLAY_PIXELTYPE_YUV444  0x0080
> 
> packed pixel or planar?  yuv420 should be there too, mpeg decompressed
> gives you planar yuv420.

Packed. Permedia3 don't support planar YUV, but even if the planar to packed unit worked, it would
be done trought the bypass unit. That said i guess other hardware kind support those.

In the Xv driver, i do the planar to packed conversion by hand at copying time. I guess it is not
very heavy, but am not sure, since it happens in the processor and main memory, and don't transit
over the AGP/PCI bus.

That said, you have to provide the source buffer to the Xv putimage function, which does the copying, 
but maybe this is not the best way of doing this.

Mmm, my idea on this would have been to provide a user-land library which would contain the driver
thing for every supported card, i thought this was the right way of doing things.

Now, the Xv permedia3 driver uses some standard descriptors for the different supported YUV and co
modes, maybe we should support the same here ?

> > struct fb_vidoverlay_mem {
> > 	unsigned long omem_start;       /* Start of overlay frame buffer mem (phys add) */
> >         __u32 omem_len;                 /* (required) length of overlay frame buffer mem */
> > 	__u8  n_over;                   /* number of the overlay buffer to use */
> > };
> 
> I'd pass pixeltype + width + height here and let the driver calculate +
> return the image size and scanline length.  The driver can easily take
> care about alignment and related issues then.

Yes, the only meaningfull stuff to access memory is the bpp of the source buffer (which can be <> 
from the one of the framebuffer), the width and the height of the buffer.
Also, don't forget, most hardware can do buffer flipping. The Permedia3 has 3 VidoOverlay bases. Xv
never uses more than 2 though. Don't know what the 3rd is for, maybe for interlacing ?

> n_over == -1  =>  "give me any free one" ?
> 
> > struct fb_vidoverlay_set {
> > 	__u32 oxsize;                   /* overlay size in pixels */
> > 	__u32 oysize;
> > 	__u16 pixel_type;               /* pixeltype to use */
> 
> obviously not needed if every allocated memory area has a width and height
> as suggested above.

As X's offscreen memory manager does.

> > 	__u16 blend_factor;             /* blending factor */
> 
> add chroma key (rage) here ?

mmm, Permedia3 can do overlays as follows :

2bit alpha blending, either per pixel (using the alpha value of the pixel) or global. It can
also use keyed overlay, either the alpha channel of the framebuffer, or an RGB key for either the
framebuffer or the overlay source. The third possibility is opaque blending, but not much is needed 
for it.

Will we support all of those ? In Xv i support only opaque with mask (using a alpha channel key in
the framebuffer) or globally alpha blended.

Also either filtering or mirroring is possible. You can mirror in X or Y, and filter either only in X
or bilinear.

Friendly,

Sven Luther