On Mon, Jun 7, 2010 at 7:38 AM, Cui, Hunk <[email protected]> wrote: > Hi, Alex, > > BTW, In Xserver part, about the exa, > http://cgit.freedesktop.org/xorg/xserver/tree/exa/exa_classic.c > The line 40 about the ExaGetPixmapAddress function, in 1.6.4, it can use to > judge the use the pExaPixmap -> fb_ptr or use pExaPixmap -> sys_ptr, but now > it can be canceled, Can you explained it please? >
fb_ptr is the address of the pixmap in vram (the gpu's copy) and sys_ptr is the address of the pixmap in system memory. There are cases when i makes more sense to use one vs. the other. For rotation you want the fb_ptr since your crtc is presumably scanning out from vram. I think your best bet is to look at how other drivers deal with EXA rotation. For the crtc base, you'll want to translate the shadow pixmap address into a hardware address for your card which usually means subtracting the framebuffer base to get just the vram offset. In the EXA driver hooks, you should use exaGetPixmapOffset(). Alex > Looking forward to your early reply. > > Thanks > Hunk Cui > > -----Original Message----- > From: Cui, Hunk > Sent: Monday, June 07, 2010 6:20 PM > To: 'Alex Deucher' > Cc: '[email protected]'; 'Kai-Uwe Behrmann'; 'Adam Jackson'; > '[email protected]' > Subject: RE: The RandR-"unable to set rotation" issue in AMD Geode LX platform > > Hi, Alex, > > Now I trace to my exa do_composite function, I found the dstOffset > parameter are diff between Xserver 1.6.4 and 1.7.1 after GetPixmapOffset, It > can be obtained from "exa.c -> exaGetPixmapOffset". > > In 1.7.1, the value return from (CARD *)pExaPixmap->fb_ptr - pExaScr -> info > -> memoryBase. > In 1.6.4, the value return from ExaGetPixmapAddress(pPix) - pExaScr -> info > ->memoryBase; there have a judge about use pExaPixmap -> fb_ptr or use > pExaPixmap -> sys_ptr > > So I think the Xserver use the pExaPixmap -> sys_ptr (properly Rotate in > 1.6.4), Do you know where are give the value to pExaPixmap -> fb_ptr and > pExaPixmap -> sys_ptr? > > Thanks, > Hunk Cui > > -----Original Message----- > From: Cui, Hunk > Sent: Monday, June 07, 2010 10:14 AM > To: 'Alex Deucher' > Cc: [email protected]; Kai-Uwe Behrmann; Adam Jackson; [email protected] > Subject: RE: The RandR-"unable to set rotation" issue in AMD Geode LX platform > > Hi, Alex, > > I tried to trace the exa prepare composite hook about rotation work, > after check the transform is handled correctly. It does not return false. So > I think there is not the bug point. Now I doubt may be in Xserver part. Do > you have another opinion? > > Thanks, > Hunk Cui > > -----Original Message----- > From: Alex Deucher [mailto:[email protected]] > Sent: Saturday, June 05, 2010 12:23 AM > To: Cui, Hunk > Cc: [email protected]; Kai-Uwe Behrmann; Adam Jackson; [email protected] > Subject: Re: The RandR-"unable to set rotation" issue in AMD Geode LX platform > > On Fri, Jun 4, 2010 at 5:33 AM, Cui, Hunk <[email protected]> wrote: >> Hi, Alex, >> >> Thank you for you give me a guide direction, I have traced the randr >> crtc modeset function. The crtc->rotatedData is not null after run >> "xf86CrtcRotate -> crtc_shadow_allocate". The shadow is provided by the >> shadow_create function in our AMD Geode driver. Please see >> "lx_crtc_mode_set" function in >> http://cgit.freedesktop.org/xorg/driver/xf86-video-geode/tree/src/lx_display.c >> >> In line 286, there is the shadow_create function, this value represents the >> byte offset of the starting location of the displayed frame buffer. Now the >> values are the same in Xserver 1.6.4 and 1.7.1, also the 1.6.4 can natural >> rotate and 1.7.1 can not. >> >> Now I have some doubt about it, it may have another place (in Xserver) call >> this frame buffer after run the "lx_crtc_mode_set" function. Because the >> Geode driver are the same in Xserver 1.6.4 and 1.7.1. >> >> Have you another suggestion? > > If the offset is getting set correctly, check to make sure the > transform is handled correctly. Does returning false unconditionally > in your exa preparecomposite hook make rotation work? > > Alex > >> >> Thanks, >> Hunk Cui >> >> >> -----Original Message----- >> From: Alex Deucher [mailto:[email protected]] >> Sent: Friday, June 04, 2010 12:39 AM >> To: Cui, Hunk >> Cc: [email protected]; Kai-Uwe Behrmann; Adam Jackson; [email protected] >> Subject: Re: The RandR-"unable to set rotation" issue in AMD Geode LX >> platform >> >> On Wed, Jun 2, 2010 at 9:38 PM, Cui, Hunk <[email protected]> wrote: >>> Hi, Alex, >>> >>> As you said two points, I need some help, >>> 1).Deal with transforms correctly in the driver composite hook, or fallback >>> and let software handle it. >>> >>> Need help: Could you support a direction to me? In Xserver part, which >>> function deal with the composite hook for allocating the shadow pixmap? >> >> See the EXA composite functions from the radeon or siliconmotion >> drivers for example. Radeon uses the 3D engine for rotation, >> siliconmotion uses rotated blits. See: >> R*00PrepareComposite() (in >> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tree/src/r600_exa.c >> and >> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tree/src/radeon_exa_render.c) >> or: >> SMI_PrepareComposite >> (in >> http://cgit.freedesktop.org/xorg/driver/xf86-video-siliconmotion/tree/src/smi_exa.c) >> >> The picture pointers have a transform that is used for rotation, >> scaling, etc. You need to check that and make sure you can support >> the requested transform and if not, return false so that software can >> handle it. >> >> >>> >>> 2).Point the crtc offset at the offset of the rotation shadow buffer. >>> >>> Need help: The shadow_create will be called form "xf86RotateBlockHandler -> >>> xf86RotateRedisplay -> xf86RotatePrepare -> driver_crtc_shadow_create", Is >>> it the crtc offset as you said? >>> >> >> In your randr crtc modeset function, you need to check if >> crtc->rotatedData is not null, and if it's valid, then you need to >> adjust the crtc offset to point to that buffer. The location is that >> of the shadow provided by the shadow_create function. See: >> avivo_set_base_format() in >> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tree/src/atombios_crtc.c >> or: >> SMILynx_CrtcAdjustFrame() in >> http://cgit.freedesktop.org/xorg/driver/xf86-video-siliconmotion/tree/src/smilynx_crtc.c >> >> Alex >> >> >>> Thanks, >>> Hunk Cui >>> >>> -----Original Message----- >>> From: Alex Deucher [mailto:[email protected]] >>> Sent: Wednesday, June 02, 2010 10:45 PM >>> To: Cui, Hunk >>> Cc: [email protected]; [email protected]; Kai-Uwe Behrmann; >>> Adam Jackson; [email protected] >>> Subject: Re: The RandR-"unable to set rotation" issue in AMD Geode LX >>> platform >>> >>> On Wed, Jun 2, 2010 at 7:15 AM, Cui, Hunk <[email protected]> wrote: >>>> Hi, Alex, >>>> >>>> I have been established three Xorg environments, only use the >>>> XRandR client program (it can download from >>>> http://cgit.freedesktop.org/xorg/ ). >>>> The phenomenon, see below: >>>> 1).Xserver-1.6.4/Geode driver-2.11.7 >>>> Run: xrandr --output default --rotate left >>>> Phenomenon: The screen properly rotate >>>> Run: xrandr --output default --rotate normal --auto >>>> Phenomenon: The screen return to normal state >>>> 2).Xserver-1.7.1/Geode driver-2.11.7 >>>> Run: xrandr --output default --rotate left >>>> Phenomenon: The screen turn to black >>>> Run: xrandr --output default --rotate normal --auto >>>> Phenomenon: The screen return to normal state >>>> 3).Xserver-1.8.99/Geode driver-2.11.8 >>>> Run: xrandr --output default --rotate left >>>> Phenomenon: The screen turn to black >>>> Run: xrandr --output default --rotate normal --auto >>>> Phenomenon: The screen does not return to normal state, still black >>>> >>>> Now the problem become more and more urgent, I use ddd tools to >>>> trace the part of Xserver. >>>> >>>> In Xserver-1.6.4, I trace the source about the composite operation, >>>> as following: >>>> >>>> #0 lx_do_composite (pxDst=0x8bef7f0, srcX=0, srcY=0, maskX=13860, >>>> maskY=-1740, dstX=0, dstY=0, width=1024, height=768) at lx_exa.c:992 >>>> #1 exaTryDriverComposite (op=<value optimized out>, pSrc=<value optimized >>>> out>, pMask=0x0, pDst=0x8bb41c0, xSrc=0, ySrc=0, xMask=<value optimized >>>> out>, yMask=<value optimized out>, xDst=<value optimized out>, yDst=<value >>>> optimized out>, width=<value optimized out>, height=<value optimized out>) >>>> at exa_render.c:688 >>>> #2 exaComposite (op=1 '\001', pSrc=0x8bb2fc0, pMask=0x0, pDst=0x8bb41c0, >>>> xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=0, yDst=0, width=1024, height=768) >>>> at exa_render.c:935 >>>> #3 damageComposite (op=0 '\000', pSrc=0x8bb2fc0, pMask=0x0, >>>> pDst=0x8bb41c0, xSrc=<value optimized out>, ySrc=<value optimized out>, >>>> xMask=<value optimized out>, yMask=<value optimized out>, xDst=<value >>>> optimized out>, yDst=<value optimized out>, width=<value optimized out>, >>>> height=<value optimized out>) at damage.c:643 >>>> #4 CompositePicture (op=1 '\001', pSrc=0x8bb2fc0, pMask=0x0, >>>> pDst=0x8bb41c0, xSrc=0, ySrc=0, xMask=<value optimized out>, yMask=<value >>>> optimized out>, xDst=<value optimized out>, yDst=<value optimized out>, >>>> width=1024, height=768) at picture.c:1675 >>>> #5 xf86RotateCrtcRedisplay (screenNum=0, blockData=0x0, >>>> pTimeout=0xbfaa3aec, pReadmask=0x81ef240) at xf86Rotate.c:118 >>>> #6 xf86RotateRedisplay (screenNum=0, blockData=0x0, pTimeout=0xbfaa3aec, >>>> pReadmask=0x81ef240) at xf86Rotate.c:249 >>>> #7 xf86RotateBlockHandler (screenNum=0, blockData=0x0, >>>> pTimeout=0xbfaa3aec, pReadmask=0x81ef240) at xf86Rotate.c:269 >>>> #8 BlockHandler (pTimeout=0xbfaa3aec, pReadmask=0x81ef240) at >>>> dixutils.c:384 >>>> #9 WaitForSomething (pClientsReady=0x8be4900) at WaitFor.c:215 >>>> #10 Dispatch () at dispatch.c:386 >>>> #11 main (argc=1, argv=0xbfaa3c84, envp=0xbfaa3c8c) at main.c:397 >>>> >>>> The lx_do_composite function is the Geode-driver function, the >>>> others are the XServer function, when I replace to the Xsever1.7.1 or >>>> Xserver1.8.99, the maskX and maskY values are 0. That make me doubt it. >>>> Can you have some other opinion? And you said the shadow_create, What is >>>> mean about it? >>>> >>> >>> As Michel said, the mask isn't used for this operation so ignore the >>> the mask parameters. It's src/dst only. As I noted before, if >>> rotation is enabled, you need to make sure: >>> - you deal with transforms correctly in the driver composite hook, or >>> fallback and let software handle it >>> - you point the crtc offset at the offset of the rotation shadow buffer >>> >>> Alex >>> >>>> Thanks, >>>> Hunk Cui >>>> >>>> -----Original Message----- >>>> From: Alex Deucher [mailto:[email protected]] >>>> Sent: Thursday, May 27, 2010 10:57 PM >>>> To: Cui, Hunk >>>> Cc: [email protected]; [email protected]; Kai-Uwe Behrmann; >>>> Adam Jackson; [email protected] >>>> Subject: Re: The RandR-"unable to set rotation" issue in AMD Geode LX >>>> platform >>>> >>>> On Wed, May 26, 2010 at 11:40 PM, Cui, Hunk <[email protected]> wrote: >>>>> Hi, all, >>>>> >>>>> As said on Ubuntu BTS, >>>>> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-geode/+bug/377929 >>>>> >>>>> About “unable to set rotation on AMD Geode LX800”, I used Ubuntu 9.10 >>>>> which >>>>> comes with generic kernel 2.6.31-17 and Xserver 1.6.4, geode-driver >>>>> 2.11.6, >>>>> I also able to rotate the screen just fine with the default geode driver >>>>> that comes with this distribution using Xrandr. Rotation is working just >>>>> fine with 'xrandr'. I used command such as: >>>>>> xrandr -o left >>>>>> xrandr -o right >>>>>> xrandr -o inverted >>>>>> xrandr -o normal >>>>> >>>>> I gave a try with 1.7.1 server on rotation, Geode driver 2.11.7, In our >>>>> platform, the <OUTPUT> name is "default", >>>>> (BTW: In general use $ xrandr -q to discover the appropriate output names >>>>> for your configuration, the reference link: >>>>> http://www.thinkwiki.org/wiki/Xorg_RandR_1.2) >>>>> >>>>> When I tried: "xrandr --output default --rotate left". The screen turn to >>>>> black. >>>>> Then tried: "xrandr --output default --rotate normal --auto". The screen >>>>> return to normal. >>>>> >>>>> Because from 1.6.4 server to 1.7.1 server, the part of RandR have been >>>>> updated and changed from source code. >>>>> >>>>> Who know the change about the part of RandR in Xserver 1.7.1? >>>> >>>> I don't recall what might have changed with regard to rotation in >>>> xserver 1.7.1 off hand. However, randr-based rotation is implemented >>>> via composite. If your driver implements EXA, the EXA composite hook >>>> would be used, so you need to make sure your composite hook handles >>>> transforms or if not falls back properly so it can be handled by >>>> software. Also make sure you implement the randr crtc hooks for >>>> allocating the shadow pixmap used for rotation (shadow_create, >>>> shadow_allocate, shadow_destroy). Finally in your crtc mode_set >>>> function, make sure you set the crtc base address to the shadow buffer >>>> is rotation is active. >>>> >>>> Alex >>>> >>>> >>> >>> >> >> > > _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
