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

[Gerd K. <kr...@by...>]

On Wed, Jul 11, 2001 at 04:35:07PM +0200, Romain Dolbeau wrote:
> Gerd Knorr wrote:
> 
> > Better use the _IOR / _IOW / _IOWR macros.
> 
> ATM FB doesn't use them, so I picked up a bunch of value
> in sequence.

That's IMHO no excuse.  The old ones can't be changed without breaking
compatibility of course, but for new ones it should be done the
RightWay[tm].

> Packed Pixel was in my mind. I'll add the other.
> (the pm3 doesn't have YUV420 :-( )

And please add some comments saying which is planar/packed.

> > 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.
> 
> The idea was the App could allow an arbitrary buffer and
> do whatever it pleases in it, including somthing entirely
> different from overlay. It might be useful if one
> add a in-FB-memory copy IOCTL or API.

There still would be image data in the buffer, and the image has some
width / height.  Even if you are going to use that image buffer for
something else than overlay (texture, bitblit or whatever).

> Also I though that the only overlay-related info
> would be put in FBIOPUT_VIDOVERLAY_START, and
> never stored in the driver (except for buffer
> data), only in the app.

IMHO it is important to let the driver pick the buffer size to avoid
trouble due to hardware limitations / alignment issues / ...
which the application doesn't know about.

> > >       __u16 blend_factor;             /* blending factor */
> > 
> > add chroma key (rage) here ?
> 
> The problem is, how to handle the mix between the overlay
> and the console layer.

Hmm, is this _really_ a problem?  Do you want to mix that with
console?  I'd expect graphic applications whould use that only,
like fbtv, dvd players (there is a fb-based one IIRC), ...

  Gerd

-- 
Damn lot people confuse usability and eye-candy.