[Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures & memory mapping)

[Benjamin Herrenschmidt]

On Wed, 2005-03-16 at 03:47 +0200, Ville Syrjälä wrote:

> There's also the case with Matrox Millennium I/II cards. They must place 
> the visible frame buffer so that no line crosses the boundary of memory 
> banks. matroxfb deals with that by moving the buffer and changing 
> smem_start and smem_len appropriately. But that is really bad for 
> DirectFB's offscreen memory management. After a mode switch the memory 
> manager would need to know what kind of initial byte offset was used. Of 
> couse it would be possible to determine that from smem_start by knowing 
> how the aperture must be aligned. Actually we already do that sort of 
> thing to allow hw accelerated rendering when used on matroxfb controlled 
> G450/G450/G550 CRTC2. But in that case the offset won't change on mode 
> switch.

So it alls end up to -> mode switch has to bust memory layout, and any
assumptions that DirectFB tries to do are incorrect.

The only sane thing that could be done is along the lines you suggested,
that is move most of "fix" into "var" so that the card can tell in
advance what the layout looks like.

But again, this is all going nowhere in the long run. One of the plans
we have is to have the mode setting be independant of the client. While
a client might "lock" it, we want a model where the user triggers a mode
setting via some mode setting & desktop geometry management library that
interfaces to fbdev, and clients be "notified". For that to work, it
also requires proper arbitration though, so we may end up again limit
that functionality to clients using the DRM for artbitration and lock
everything when some guy like DirectFB enters the picture.

> > and because
> > it seems that directFB has only been tested on little endian machines
> > (damn them !) and thus doesn't understand the problem with swapper on
> > framebuffer access).
> 
> Actually people do use it on big-endian systems but since neither the 
> mach64, ati128 or radeon drivers play with the swapper settings I can only 
> assume that they haven't been tested very extensively.

You are wrong here, all of those 3 drivers do play with the swapper
setting, they all 3 set the swapper based on the bit depth of the
screen, so writing an image to offscreen memory with a different bit
depth will be broken. See usage of SURFACE_CNTL in radeonfb for example.

Ben.