Re: Best way to support mulitple planes?

[Timur Tabi <timur@freescale.com>]

Ville Syrjälä wrote:

> It is one way. At least omapfb does things the same way, and it has some
> custom ioctls to control the planes. 

Thanks, I'll take a look at it.

> Another way would be to have one
> fb device and implement support for the extra planes in user space.

Can you give me more details?  How exactly would I do that in user space?

> Perhaps return an error for any ioctls when the plane is not available,
> or implement a custom ioctl which carries that information. You could
> also leave that up to user space to know. It seems to me that you'll need
> a customized user space solution anyway (eg. a DirectFB gfx driver or a
> custom kdrive X server).

You might be right.

Would it be correct to say that applications expect the separate devices 
(/dev/fb0, /dev/fb1, etc) to represent different monitors?

As I said, our hardware does alpha-channel blending of the three planes onto 
one display.  If an application opens /dev/fb1 and tries to draw on it, 
nothing appears because the alpha channel for each pixel defaults to 0, which 
means full transparency.  So our hardware ignores the alpha channel for 
/dev/fb0 but not /dev/fb1 or /dev/fb2.

In addition, if the resolution is changed on /dev/fb0, it automatically 
changes for /dev/fb1 and /dev/fb2 as well.  Is there a mechanism for telling 
the application that the resolution has changed?

Do you know how DirectFB supports layers?  That is, what mechanism does 
DirectFB use to draw to one layer versus another layer?  I tried examining the 
DirectFB source, but I couldn't figure it out.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/