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. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
