Best way to support mulitple planes?

Best way to support mulitple planes?

[Timur Tabi]

Hi, I'm new to the framebuffer subsystem, so forgive me if this is a FAQ. 
I've spent the past couple hours scouring web sites and sample code, but I 
don't have a definitive answer to my question.

I have a device that supports three planes - memory areas that the hardware 
reads from to generate the physical image.  Each plane supports an alpha 
channel for each pixel, and the hardware just blends all three planes together 
when it draws the image.

Currently, our driver create three framebuffer devices, /dev/fb0, /dev/fb1, 
and /dev/fb2, which means three calls to register_framebuffer().  Is this the 
correct way to do it?

The reason I ask is that our hardware can only handle three planes if the 
resolution is 1024x768 or below.  I can't figure out any way of telling the 
framebuffer subsystem that if it switches to 1280x1024 in plane 0, that plane 
1 and 2 no longer exist.  Any suggestions on how to handle that?

-- 
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/

Re: Best way to support mulitple planes?

[Ville Syrjälä]

On Thu, Sep 13, 2007 at 02:50:54PM -0500, Timur Tabi wrote:
> Hi, I'm new to the framebuffer subsystem, so forgive me if this is a FAQ. 
> I've spent the past couple hours scouring web sites and sample code, but I 
> don't have a definitive answer to my question.
> 
> I have a device that supports three planes - memory areas that the hardware 
> reads from to generate the physical image.  Each plane supports an alpha 
> channel for each pixel, and the hardware just blends all three planes together 
> when it draws the image.
> 
> Currently, our driver create three framebuffer devices, /dev/fb0, /dev/fb1, 
> and /dev/fb2, which means three calls to register_framebuffer().  Is this the 
> correct way to do it?

It is one way. At least omapfb does things the same way, and it has some
custom ioctls to control the planes. Another way would be to have one
fb device and implement support for the extra planes in user space.

> The reason I ask is that our hardware can only handle three planes if the 
> resolution is 1024x768 or below.  I can't figure out any way of telling the 
> framebuffer subsystem that if it switches to 1280x1024 in plane 0, that plane 
> 1 and 2 no longer exist.  Any suggestions on how to handle that?

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).

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/

-------------------------------------------------------------------------
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/

Re: Best way to support mulitple planes?

[Timur Tabi]

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/

Re: Best way to support mulitple planes?

[Antonino A. Daplas]

On Thu, 2007-09-13 at 14:50 -0500, Timur Tabi wrote:
> Hi, I'm new to the framebuffer subsystem, so forgive me if this is a FAQ. 
> I've spent the past couple hours scouring web sites and sample code, but I 
> don't have a definitive answer to my question.
> 
> I have a device that supports three planes - memory areas that the hardware 
> reads from to generate the physical image.  Each plane supports an alpha 
> channel for each pixel, and the hardware just blends all three planes together 
> when it draws the image.
> 
> Currently, our driver create three framebuffer devices, /dev/fb0, /dev/fb1, 
> and /dev/fb2, which means three calls to register_framebuffer().  Is this the 
> correct way to do it?

One method is to create device, /dev/fb0, then create a custom fb_mmap()
that, depending on the parameters, will return a different address for
each of the 3 planes. (We already mmap the framebuffer and the MMIO
separately by this method). Then it is up to the user application to
call mmap() 3x for each plane and what to write to those planes.

Or, assuming each plane is located in single framebuffer region with
just different offsets, then instead of creating a custom fb_mmap(),
create a custom ioctl that will return the offsets relative to the start
of the framebuffer of each plane.

> 
> The reason I ask is that our hardware can only handle three planes if the 
> resolution is 1024x768 or below.  I can't figure out any way of telling the 
> framebuffer subsystem that if it switches to 1280x1024 in plane 0, that plane 
> 1 and 2 no longer exist.  Any suggestions on how to handle that?

You can change the type from FB_TYPE_PLANES to FB_TYPE_PACKED_PIXELS in
fb_fix_screeninfo.  That implies that for each SET_VAR ioctl, you do a
GET_FIX ioctl.

Tony


-------------------------------------------------------------------------
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/

Re: Best way to support mulitple planes?

[Antonino A. Daplas]

On Thu, 2007-09-13 at 16:29 -0500, Timur Tabi wrote:
> Ville Syrjälä wrote:
> 

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

That's not necessarily true. In the strictest sense, each /dev/fbx
device represents one memory region.  Whether that memory region is
attached to zero, one or more monitors is up to the driver.

We do not have the infrastructure yet to separate output devices from
the framebuffer so multi-head/mergefb implementations will still be
driver specific.

Tony



-------------------------------------------------------------------------
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/
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: Best way to support mulitple planes?

[Antonino A. Daplas]

On Sun, 2007-09-16 at 10:32 +0800, Antonino A. Daplas wrote:
> On Thu, 2007-09-13 at 14:50 -0500, Timur Tabi wrote:
> > 
> > The reason I ask is that our hardware can only handle three planes if the 
> > resolution is 1024x768 or below.  I can't figure out any way of telling the 
> > framebuffer subsystem that if it switches to 1280x1024 in plane 0, that plane 
> > 1 and 2 no longer exist.  Any suggestions on how to handle that?
> 
> You can change the type from FB_TYPE_PLANES to FB_TYPE_PACKED_PIXELS in
> fb_fix_screeninfo.  That implies that for each SET_VAR ioctl, you do a
> GET_FIX ioctl.
> 

If you want separate /dev/fb's for each plane, then setup your own
notifier system so each of the /dev/fb's  can communicate with each
other.

See drivers/video/fb_notify.c, and look at
drivers/video/backlight/backlight.c, drivers/video/fbmem.c and
drivers/video/console/fbcon.c on how this communication is done.

Tony



-------------------------------------------------------------------------
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/

Re: Best way to support mulitple planes?

[Ondrej Zajicek]

[-- Attachment #1.1: Type: text/plain, Size: 1593 bytes --]

On Sun, Sep 16, 2007 at 10:38:30AM +0800, Antonino A. Daplas wrote:
> On Thu, 2007-09-13 at 16:29 -0500, Timur Tabi wrote:
> > Ville Syrjälä wrote:
> > 
> > Would it be correct to say that applications expect the separate devices 
> > (/dev/fb0, /dev/fb1, etc) to represent different monitors?
> 
> That's not necessarily true. In the strictest sense, each /dev/fbx
> device represents one memory region.  Whether that memory region is
> attached to zero, one or more monitors is up to the driver.

I always perceived fb device as a representation of a sequencer/scanner -
probably because almost all ioctls on a fbdev device make sense for
sequencer (and associated CRT controller and DAC).

> We do not have the infrastructure yet to separate output devices from
> the framebuffer so multi-head/mergefb implementations will still be
> driver specific.

I think it can be done with (almost) present infrastructure - 
one fb device per sequencer (sharing all memory of a card). We can
do  most of multi-head/mergedfb configurations using appropriate vxyres/pan
setting. Perhaps one new ioctl to assign output ports to sequencers and
one new sysfs option for optional memory split (separate parts of memory
accessible through each fb device instead of all memory accessible through
both fb devices).

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org, jabber: santiago@njs.netlab.cz)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel