radeon tiling again...

[Roland Scheidegger]

Michel Dänzer wrote:
> On Mon, 2005-01-24 at 23:42 +0100, Roland Scheidegger wrote:
> 
>>Alex Deucher wrote:
>>
>>>actually RADEONAdjustFrame() should handle mergedfb fine. 
>>>RADEONAdjustFrame() will then call RADEONAdjustFrameMerged()
>>
>>You're right I mixed that up with DoAdjustFrame. I can't see though why
>>this shouldn't work just the same as pScrn->AdjustFrame (I don't see any 
>>code which would set that AdjustFrame function to something else).
> 
> 
> I know of at least one other AdjustFrame() wrapper, for Xv. Maybe that's
> causing trouble at the time you try calling the screen function. If all
> you want is to make sure the SAREA fields are well-defined, calling the
> driver function directly might make more sense anyway.

Ok found out what's going on. The comment is right in radeon_accel.c, 
for a different function, but that's the reason.
     /* FIXME: pScrn->pScreen has not been initialized when this is first
      * called from RADEONSelectBuffer via RADEONDRICPInit.  We could use
      * the screen index from pScrn, which is initialized, and then get
      * the screen from screenInfo.screens[index], but that is a hack.
      */
     dma.context = DRIGetContext(pScrn->pScreen);

So, pScrn->pScreen is always NULL in RADEONScreenInit (it will get 
initilialized right after that).
So DRIGetSAREAPrivate segfaults. So does the stuff in RADEONAdjustFrame.
Is there a particular reason why it's a bad idea to just use 
screenInfo.screens[index], other than it's a hack and ugly? Could bad 
things happen? I've tried that (only in DoAdjustFrame, calling 
AdjustFrameMerged directly) and this works (not only does it not 
segfault, but it actually finally fixes this stupid bug!)
Is there some better method to fix this? I guess even pScrn->pScreen 
could be hacked up, it will get overwritten right after that anyway...
As far as I can see, there is no other function which will get called 
after ScreenInit, which could be used to call AdjustFrame from there 
instead.

Roland