[Xorg-driver-geode] Rendering for rotation

[Huang, FrankR]

Jonathan,

	Thanks a lot for your tutorial:).
	I got a lot from your explanation. And from the debug I got the matrix you described from pSrc->transform when rotation is happening. Our driver justify how about the rotation (90,180,270) from matrix[0][0] and matrix[1][0] and does the correct rotation based on that.
	Some questions below:
	1) what's the mean for matrix[0][2] and matrix[1][2], is it the new start point? From my debug I found it is 1023 and 0 when rotation is 90 degree. Is it to say the new start point is (1023,0)? I have not seen this value is used in our driver.
	2)My screen resolution is 1280x1024. Our driver use pSrc->pDrawale->width(1024) and pSrc->pDrawable->height(1280) for new source's height and width. Are they inverted before transferring to driver?
	3)Because the screen's width is greater than height, how the driver do the stretch and squeeze of new rotation desktop? I found that(take 90 degree rotation for example) the rotation is first done. And the region of (1280-1024)x 1024 is filled with the copy one. Then this region is rendered and whole screen is stretched and squeezed. How that happened? Is our driver's work? Just very curious about that:) 


Thanks,
Frank

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

On Mon, 2010-07-12 at 14:20 +0800, Huang, FrankR wrote:
> When the pSrc->transform is not zero...

That's the information I needed.  You are doing the rotation at render
time, not at scanout time.  Therefore, I need to teach you about how to
interpret the transform matrix.

First, remember that the destination region is always untransformed.
Any transform matrix set on the destination picture is ignored.  The
x,y,w,h coordinates can be used directly for that purpose.

You cannot rely on only testing pSrc->transform for NULL or non-NULL,
and assume that if non-NULL, it has certain properties.  You must
interpret each of the nine elements of the matrix.

For the simplified cases your hardware supports, this will mostly be a
case of comparing the matrix against known patterns and rejecting
matrices that do not conform to them.

The nine-element matrix is laid out as 3x3 using 16.16 fixed-point
notation - I'll write the floating-point equivalents here for
readability.

When pSrc->transform is NULL, the identity matrix is assumed:

{ 1, 0, 0 }
{ 0, 1, 0 }
{ 0, 0, 1 }

The identity matrix has no effect; it produces output coordinates that
are identical to input coordinates.

When a 90- 180- or 270-degree rotation is required, the following three
matrix forms will be used:

{  0, -1, dX }
{  1,  0, dY }
{  0,  0,  1 }

{ -1,  0, dX }
{  0, -1, dY }
{  0,  0,  1 }

{  0,  1, dX }
{ -1,  0, dY }
{  0,  0,  1 }

Notice that each one includes dX and dY components (in the [0][2] and
[1][2] positions), which represent a post-rotation translation.  You
will need to take these into account.  For this purpose they will
normally be integers, but this must be verified.

Also notice that the third row is always the same - it only differs from
that if a perspective transform is wanted.  Reject transforms for which
this is not true.

Finally, notice that only four sets of values - to include the identity
- are used for the four top-left components.  These are what cause the
rotation to the four possible orientations, by selectively swapping and
negating the X and Y coordinates.

Do not rely on external information, such as the global rotation state,
to determine the rotation degree.  Read the pSrc->transform->matrix[][]
and recognise these patterns.  You may encounter 90, 270 and identity
transforms successively in the same rotation state, if they are being
used for different purposes.

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