The RandR-"unable to set rotation" issue in AMD Geode LX platform

Sun Jun 6 19:14:29 PDT 2010

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
>>>
>>>
>>
>>
>
>