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

[Benjamin Herrenschmidt]

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.

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

Ben.