[Xorg-driver-geode] Rendering for rotation

Mart Raudsepp leio at gentoo.org
Thu Jul 8 04:00:19 PDT 2010


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



More information about the Xorg-driver-geode mailing list