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

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:

quoted

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.

quoted

quoted

quoted

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@sci.fi
http://www.sci.fi/~syrjala/