[Xorg-driver-geode] Rendering for rotation

[Huang, FrankR]

Just as Mart reply, our driver can support 90,180,270 rotation. Using xrandr tool to do the full screen rotation.
And our framebuffer has an space named as shadow buffer to do that. So our driver can handle this.
What I am care about is the srcX and srcY which the server transmit the parameters to lx_do_composite. In my opinion, the srcX and srcY should be handled just as maskX and maskY(subtract them if they are not out of the region or in negative value). But it seems that it is wrong to do that(subtract them) if in rotation mode. I am still looking at code here(we already have the rotation and support that in our code).
Another question is same as Mart, if there is any difference between full screen rotation and part of rotation? If that is so, I still think the srcX and srcY subtraction should be done. Any comments?


Thanks,
Frank

-----Original Message-----
From: Mart Raudsepp [mailto:leio at gentoo.org] 
Sent: 2010?7?8? 19:00
To: Jonathan Morton
Cc: Huang, FrankR; xorg-driver-geode at lists.x.org; xorg-devel at lists.x.org
Subject: Re: [Xorg-driver-geode] Rendering for rotation

On N, 2010-07-08 at 13:45 +0300, Jonathan Morton wrote:
> On Thu, 2010-07-08 at 17:17 +0800, Huang, FrankR wrote:
> > Have a question for render operation on rotation.
> 
> > I fixed the bug in lx_do_composite in geode driver. srcX and
> > srcY are same as maskX and maskY. When I calculate the renderging
> > region, I need to use "maskWidth - maskX" and "maskHeight - maskY" if
> > Mask is not zero.
> 
> > Same way, when the Mask in zero, we need do "srcWidth - srcX"
> > and "srcHeight - srcY". But seems it is not reasonable for rotation in
> > this way. When it is rotation, right now I am still use srcWidth and
> > srcHeight. Is it any special for rotation?
> 
> What kind of rotation is involved here?

We support only right-hand 90, 180 and 270 degree rotation indeed in
geode - that's what the GPU can handle with some acceleration.
We swap and shift the source or mask coordinates/width/height already at
the start of our Composite vfunction
http://cgit.freedesktop.org/xorg/driver/xf86-video-geode/tree/src/lx_exa.c#n969

So to me the first question is if we need to do the same to maskX and
maskY then before subtracting from maskWidth/maskHeight (which are
currently confusingly actually srcWidth/srcHeight in the code - the
variable is shared and goes for the mask if pMsk is set), as we have
done the rotation adjustment to maskWidth/maskHeight already, but not
maskX/maskY.
Haven't spent much time on thinking about it yet though, so might be
able to figure that part out myself too after some time.

> AFAIK, XRandR will automatically apply an appropriate transform to
> operations if a rotated framebuffer scanout is not available.  So the
> situation probably depends on that.

I'm still somewhat confused about full screen rotation (xrandr --output
default --rotate right) and individual rotating transforms on Composite
operations. What operations do you refer to exactly that XRandR will
automatically apply transforms on?

> With alternate framebuffer scanout support, you would treat the
> framebuffer as a normal unrotated pixmap with different dimensions (swap
> width and height).

Is this alternate framebuffer commonly referred to as "shadow
framebuffer"?

> Without it, XRandR will cause EXA to provide operations with 90-degree
> rotate/translate transforms set on the source and mask images, and with
> the (X,Y) and (width,height) pairs of the destination area swapped.  In
> this case you would need to understand how transforms work, although it
> is unlikely that you would support anything but this specific 90-degree
> case.

Does this mean that with shadow buffer made, we will rarely get rotation
transform operations in Composite? Only if libXrender clients explicitly
ask, even if that?


Regards,
Mart Raudsepp