Who can explain the diff between Xserver-1.6.4 version and >1.7 version about the ExaGetPixmapAddress?

[Cui, Hunk]

Hi, Maarten,

	About the crtc->rotatedData (AMD Geode LX driver)
in http://cgit.freedesktop.org/xorg/driver/xf86-video-geode/tree/src/lx_display.c#n386
then the rotate_mem offset and shadow_allocate address will be return to xf86CrtcSetModeTransform, after run to xf86RotatePrepare, it will call lx_crtc_shadow_create -> GetScratchPixmapHeader -> exaModifyPixmapHeader_classic to write the pPixData. The pPixData will be allocated to the sys_ptr and fb_ptr(if the judge come into existence).

Thanks
Hunk Cui

-----Original Message-----
From: Maarten Maathuis [mailto:madman2003 at gmail.com] 
Sent: Wednesday, June 09, 2010 6:16 PM
To: Cui, Hunk
Cc: xorg-devel at lists.x.org; Huang, FrankR; Writer, Tim; Torres, Rigo
Subject: Re: Who can explain the diff between Xserver-1.6.4 version and >1.7 version about the ExaGetPixmapAddress?

On Wed, Jun 9, 2010 at 11:59 AM, Cui, Hunk <Hunk.Cui at amd.com> wrote:
> Hi, Maarten,
>        You can see my attachment screenshot, in this example, when run to the line 177-178, the pPixData is 0xb62b000, pExaScr->info->memoryBase is 0xb5e2b000,pExaScr->info->memorySize is 17825792, if only have "<", the judge will not come into existence.
>        You can try it. If not come into existence. The fb_ptr address value is 0x0.

How are you allocating rotatedData?

>
> Thanks,
> Hunk Cui
>
>
> -----Original Message-----
> From: Maarten Maathuis [mailto:madman2003 at gmail.com]
> Sent: Wednesday, June 09, 2010 5:47 PM
> To: Cui, Hunk
> Cc: xorg-devel at lists.x.org; Huang, FrankR; Writer, Tim; Torres, Rigo
> Subject: Re: Who can explain the diff between Xserver-1.6.4 version and >1.7 version about the ExaGetPixmapAddress?
>
> On Wed, Jun 9, 2010 at 10:23 AM, Cui, Hunk <Hunk.Cui at amd.com> wrote:
>> Hi, Maarten,
>>
>>         As your commit:
>> http://cgit.freedesktop.org/xorg/xserver/commit/?id=12aeddf5ad41902a180f8108623f356642b3e911
>>
>>         About Scratch pixmap with gpu memory – Framebuffer. Now in > 1.7
>> version, the exaModifyPixmapHeader function have been become
>> exaModifyPixmapHeader_classic (
>> http://cgit.freedesktop.org/xorg/xserver/tree/exa/exa_classic.c?id=ac7ac913fd98ea359c05c89968ab53a3223615b4
>> Line 144).
>>
>>         When I debug to this point (my AMD xf86-video-geode), the line
>> 171-172, why only have the “<” judge. For general, I think “((CARD8
>> *)pPixData - pExaScr->info->memoryBase) <= pExaScr->info->memorySize)”,
>> because rotate_mem offset should equal to the pExaScr->info->memorySize
>> (e.g: displayed frame buffer). If only have the “<”, It will not go into
>> this judge, so the fb_ptr address value is 0x0, then the value will affect
>> the exaGetPixmapOffset function (in exa.c
>> http://cgit.freedesktop.org/xorg/xserver/tree/exa/exa.c?id=ac7ac913fd98ea359c05c89968ab53a3223615b4
>> line 62) about “return (CARD8 *)pExaPixmap->fb_ptr -
>> pExaScr->info->memoryBase”, the range will be exceed, if run the
>> driver_do_composite (It is lx_do_composite in our geode_driver), the
>> dstOffset is a error value.
>>
>>         Could you explain this issue? Let me know why only have “<”.
>
> If your memory base is 20000, your offscreen memory size is 10000,
> then 20000 to 29999 are valid addresses. If you enter 30000 - 10000 <=
> 20000, then that would be true, which is wrong, that's why it's just
> "<", because addressing starts from 0 not 1.
>
>>
>> Thanks,
>>
>> Hunk Cui
>>
>>
>
>
>
> --
> Life spent, a precious moment, in the wink of an eye we live and we die.
>
>



-- 
Life spent, a precious moment, in the wink of an eye we live and we die.