FB model basic issues (WAS: radeon, apertures & memory mapping)
benh at kernel.crashing.org
Mon Mar 14 22:59:42 PST 2005
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.
The main issue hwoever, is access arbitration. I'd appreciate your
DirectFB point of view on these things.
More information about the xorg