Sprite transforms in RandR

[Aaron Plattner]

On Mon, Dec 06, 2010 at 08:44:41AM -0800, 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.

Are there really no dumb little phones or something that can rotate the
internal screen but not external displays?  I'd feel more comfortable if
someone familiar with the various embedded graphics chips would chime in
with an ack/nack.

I guess outputs have a mask of allowable rotations provided to the clients.
Maybe that's sufficient: you can only use hardware rotation if the
scanoutpixmapinfo *and* the corresponding output rotation mask say you can,
and otherwise you get to do the rotation yourself with the graphics
hardware?

One thing that reminded me of is how the requested rotation is going to be
communicated to the compositor.  Should we add something like a
RRConfigRedirectMask, or will the clients be expected to invent their own
new protocol for sending configuration requests to the compositor?