[Xorg-driver-geode] Rendering for rotation

[Mart Raudsepp]

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