On Wed, Jun 9, 2010 at 12:37 PM, Cui, Hunk <[email protected]> wrote: > 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). >
I am looking at your driver, and it's all a bit confusing. This will have to wait until (at least) this evening. > Thanks > Hunk Cui > > -----Original Message----- > From: Maarten Maathuis [mailto:[email protected]] > Sent: Wednesday, June 09, 2010 6:16 PM > To: Cui, Hunk > Cc: [email protected]; 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 <[email protected]> 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:[email protected]] >> Sent: Wednesday, June 09, 2010 5:47 PM >> To: Cui, Hunk >> Cc: [email protected]; 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 <[email protected]> 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. > > -- Life spent, a precious moment, in the wink of an eye we live and we die. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
