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
