The RandR-"unable to set rotation" issue in AMD Geode LX platform
Cui, Hunk
Hunk.Cui at amd.com
Mon Jun 7 18:33:04 PDT 2010
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:alexdeucher at gmail.com]
Sent: Monday, June 07, 2010 10:59 PM
To: Cui, Hunk
Cc: xorg-devel at lists.x.org; Kai-Uwe Behrmann; Adam Jackson; yangman at gmail.com
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 <Hunk.Cui at amd.com> 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: 'xorg-devel at lists.x.org'; 'Kai-Uwe Behrmann'; 'Adam Jackson'; 'yangman at gmail.com'
> 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: xorg-devel at lists.x.org; Kai-Uwe Behrmann; Adam Jackson; yangman at gmail.com
> 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:alexdeucher at gmail.com]
> Sent: Saturday, June 05, 2010 12:23 AM
> To: Cui, Hunk
> Cc: xorg-devel at lists.x.org; Kai-Uwe Behrmann; Adam Jackson; yangman at gmail.com
> 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 <Hunk.Cui at amd.com> 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:alexdeucher at gmail.com]
>> Sent: Friday, June 04, 2010 12:39 AM
>> To: Cui, Hunk
>> Cc: xorg-devel at lists.x.org; Kai-Uwe Behrmann; Adam Jackson; yangman at gmail.com
>> 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 <Hunk.Cui at amd.com> 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:alexdeucher at gmail.com]
>>> Sent: Wednesday, June 02, 2010 10:45 PM
>>> To: Cui, Hunk
>>> Cc: xorg-devel at lists.x.org; xorg at lists.freedesktop.org; Kai-Uwe Behrmann; Adam Jackson; yangman at gmail.com
>>> 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 <Hunk.Cui at amd.com> 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:alexdeucher at gmail.com]
>>>> Sent: Thursday, May 27, 2010 10:57 PM
>>>> To: Cui, Hunk
>>>> Cc: xorg-devel at lists.x.org; xorg at lists.freedesktop.org; Kai-Uwe Behrmann; Adam Jackson; yangman at gmail.com
>>>> 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 <Hunk.Cui at amd.com> 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
>>>>
>>>>
>>>
>>>
>>
>>
>
>
More information about the xorg-devel
mailing list