[Xorg-driver-geode] Rendering for rotation

[Huang, FrankR]

Jonathan,

	First of all, our driver supports rotation already. This point, I have made it clear in the previous mail. I just want to understand with srcX and srcY parameters in our lx_do_composite when rotation is happened.
	My question is that the call for the lx_do_composite(PixmapPtr pxDst, int srcX, int srcY...).
	Just as you know, in exa_render.c, there is a call for lx_do_composite().

	While (nbox--)
	{
		(*pExaScr->info->Composite) (pDstPix, pbox->x1 + xSrc,
						     pbox->y1 + ySrc,
							...);
		pbox++
	}

	The (pbox->x1 + xSrc) will be transmitted to srcX, the (pbox->y1 + ySrc) will be transmitted to srcY.

	When the pSrc->transform is not zero, the rotation will be done by lx_do_composite. But I found that that the srcX and srcY are inverted when the rotation is 90 and 270 degree. That is to say, srcX is the height's coordinate while srcY is the width's coordinate. Is it a rule? I want to know the parameters transferred to lx_do_composite. I can make our driver work correctly. Any document?

Thanks,
Frank

-----Original Message-----
From: Jonathan Morton [mailto:jonathan.morton at movial.com] 
Sent: 2010?7?10? 0:46
To: Huang, FrankR
Cc: Mart Raudsepp; xorg-driver-geode at lists.x.org; xorg-devel at lists.x.org
Subject: RE: [Xorg-driver-geode] Rendering for rotation

On Fri, 2010-07-09 at 09:17 +0800, Huang, FrankR wrote:
> 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'm still not quite clear on what your hardware expects when XRandR has
been set for rotation.

If you have a dedicated rotation system built into your RAMDAC, then you
would change the dimensions of the framebuffer but rendering would then
continue as normal.  Rendering commands given to your driver would not
be transformed if the client was not explicitly asking for a transform.
So no special handling is needed by your driver.

If, instead, you must do rotation during rendering (rather than during
scanout), then XRandR will cause some rendering commands to be provided
with a 90-, 180- or 270-degree rotate transform applied, and some
commands without it.  This depends on whether the command is from a
nominally upright pixmap to the rotated framebuffer, or vice versa, or
between two upright pixmaps.

So in that latter case, where you have rotated rendering but not rotated
scanout support, you must examine the transform matrices you are given
and understand how to apply them.  If this is what you need, say so and
I will attempt to explain it.  The matrices you will need to handle will
have unit or zero coefficients in most positions.

-- 
------
From: Jonathan Morton
      jonathan.morton at movial.com