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

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.

quoted

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.