FB model basic issues (WAS: radeon, apertures & memory mapping)

[Ville Syrjälä]

On Tue, Mar 15, 2005 at 05:59:42PM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2005-03-15 at 08:01 +0200, Ville Syrjälä wrote:
> 
> > If radeonfb will allocate the buffer for the second head from the top of 
> > the memory users would basically have to guess it's location. matroxfb 
> > simply cuts the memory in two pieces and allocates the buffers from the 
> > start of each piece. I don't really like that approach. Adding a simple 
> > byte_offset field to fb_var_screeninfo would solve the problem quite 
> > nicely but I don't know if such API changes are acceptable at this stage.
> 
> And we don't know if all HW would support it anyway.

Such hardware would be free to ignore any user supplied byte_offset and 
place the buffer anywhere it wants. Even a read-only byte_offset field 
would help. But using the second head would require all apps to be updated 
to be aware of byte_offset :( Maybe some kind of API version thing could 
help here ie. User sets flag X somewhere indicating byte_offset should be 
used instead of changing smem_start.

> > > > We are thinking with the "new model" in mind, and so far, a mode setting 
> > > > is under control of the framebuffer. Content of video memory (framebuffer,
> > > > textures, overlay, whatever) simply cannot be considered as preserved
> > > > accross mode switches.
> > > > 
> > > > We can't also block all evolutions just because we have to support a
> > > > broken model. 
> > > 
> > > I'm not suggesting that, but I do think that tying together mode
> > > switching and memory allocation would be a big mistake.
> > 
> > Indeed.
> 
> The main issue hwoever, is access arbitration. I'd appreciate your
> DirectFB point of view on these things.

DirectFB has it's own asbitration mechanism. It doesn't support using 
multiple framebuffer devices at the same time. For that to work DirectFB 
would just have to know if some of the framebuffer devices are actually 
different outputs of the same card so that it could associate both with 
the same lock and accelerator state.

With the current system I don't see much chance of using accelerated fbcon 
on one head and accelerated DirectFB (or something else) on the other.

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