Sprite transforms in RandR

[Ville Syrjälä]

On Mon, Dec 06, 2010 at 08:44:41AM -0800, ext Keith Packard wrote:
> On Mon, 6 Dec 2010 15:20:01 +0000, Daniel Stone <daniel at fooishbar.org> wrote:
> 
> > Nope, we don't have any per-CRTC differences there, it's just that
> > rotation is essentially another property of the mode that we need to know
> > about in order to set up both the CRTC and the underlying surfaces,
> > rather than an additional BlockHandler and a transform somewhere.
> 
> If we don't have any existing hardware which requires per-CRTC scanout
> formats, I have to admit I'm tempted to leave the interface alone
> instead of making things more complicated for both applications and the
> server.

I thinkl the OMAP case could probably make use of that.

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.

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.

-- 
Ville Syrjälä