Hi, Alex,
Thanks for your modest reply, but now when I translate the shadow
pixmap address into a hardware address (It is "displayed frame buffer" in my
card), in the EXA driver hooks, get just the vram offset from the sys_ptr, not
the fb_ptr.
So I will look at how other drivers deal with EXA rotation.
Thanks,
Hunk Cui
-----Original Message-----
From: Alex Deucher [mailto:[email protected]]
Sent: Monday, June 07, 2010 10:59 PM
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 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
