Sprite transforms in RandR

[Keith Packard]

On Tue, 7 Dec 2010 15:44:36 +0200, Ville Syrjälä <ville.syrjala at nokia.com> wrote:

> Say, for example, that you have a portrait scanned LCD (which has it's
> own memory) and TV out, and let's say you want everything to be in
> landscape all the time. The LCD could do the required 90/270 degree
> rotation for free (since it has it's own memory), and for TV out you
> then want no rotation. In this case you probably don't want to use VRFB
> (the rotation thingy Daniel mentioned), since all memory access would
> happen in landscape direction, and VRFB's tile format would make that
> less efficient.

Does the TV out support rotation in hardware at all?

> So if you can specify 90 degree rotation for one CRTC and 0 degree for
> another, the driver could allocate the pixmap in the most efficient
> format. If you have just one rotation parameter the driver would have
> no choice but to assume that rotation will be used even with the TV out,
> and thus would be forced to use VRFB all the time.

Hrm. Right now, there is per-CRTC rotation support information, so you
can tell whether a particular CRTC does rotation at all, of course
that's all mixed in with the software rotation support in the server
which I'm hoping to deprecate when compositing managers gain appropriate
built-in rotation support.

If we remove the software rotation support, and expose only 'native'
rotation in the per-CRTC information, then the question about
SCANOUTPIXMAPINFO is whether two CRTCs need a *different* format for the
same rotation.

In you case, I think you'd set the CRTC that could drive the TV as
supporting only RR_Rotation_0 and the CRTC that could drive the LCD as
supporting RR_Rotation_0|RR_Rotation_90|RR_Rotation_270.

Or do we need separate per-*output* rotation information which is
distinct from the CRTCs too?

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101207/5ae25ed4/attachment.pgp>