Sprite transforms in RandR

[Aaron Plattner]

On Sat, Dec 04, 2010 at 03:06:35PM -0800, Keith Packard wrote:
> To make per-crtc pixmaps actually useful for things like extended or
> rotated desktops, I've added a couple of matrices to each crtc to
> transform the sprite position and image. I suspect these will need
> documentation beyond the following:
> 
> +┌───
> +    RRSetCrtcSpriteTransform
> +       crtc: CRTC
> +       position-transform: TRANSFORM
> +       image-transform: TRANSFORM
> +└───
> +       Sets the sprite transforms for the specified crtc, any sprites
> +       presented on this crtc will have their positions transformed
> +       by the position-transform matrix. Sprite images displayed on the crtc
> +       will be transformed by the image-transform matrix.
> +
> +┌───
> +    RRGetCrtcSpriteTransform
> +       crtc: CRTC
> +      ▶
> +       position-transform: TRANSFORM
> +       image-transform: TRANSFORM
> +└───
> +       Gets the sprite transforms for the specified crtc.
> +
> 
> In any case, the position piece of this is complete, and the image piece
> is done save the actual image transforms -- the matrix gets all the way
> From the client to the cursor code.
> 
> Protocol changes:
> 
>         git://people.freedesktop.org/~keithp/randrproto master

There are a few whitespace bugs, such as this:
┌───
    RRQueryScanoutPixmaps
\twindow: WINDOW
      ▶
        infos: LISTofSCANOUTPIXMAPINFO
└───
\tErrors: Window

The actual text sounds reasonable to me, but it's not clear what the
'rotations' field of RRCreateScanoutPixmap is used for.  Is it a set of
hardware rotation modes that might be used for that crtc with that pixmap?
Also, is the set of "supported" rotations screen-wide, or associated with the
particular format passed in?  Is it possible for a driver to list multiple
SCANOUTPIXMAPINFO with matching formats?  E.g. I wonder if there's hardware
that has, say, hardware rotation for one crtc but not another.  It sounds like
RandR expects the crtcs to have matching capabilities.

The whitespace for RRCrtcSetSpriteTransform has spaces followed by tabs.

Can you clarify the distinction between the screen size and the screen pixmap
size?

Do you think it's worth making the sizes larger than CARD16 for future
expansion?  We're going to need to rev a lot of stuff if we want to move to
larger sizes, but maybe it's better to start doing it piecemeal when we're
already changing extensions.

Can you clarify the distinction between crtc (x, y) and (pixmap_x,
pixmap_y)?  I guess the (x, y) position is used to produce the input sprite
position for that crtc?  It would be nice to have that be spelled out a
little more in randrproto.txt.

> Library changes:
> 
>         git://people.freedesktop.org/~keithp/libXrandr master

There are some unrelated whitespace changes, and a tab-space-tab pattern in
the argument list for XRRSetCrtcConfigs.

> xrandr changes:
> 
>         git://people.freedesktop.org/~keithp/xrandr master

I just skimmed this.  It seemed okay.

Acked-by: Aaron Plattner <aplattner at nvidia.com>

> xserver changes:
> 
>         git://people.freedesktop.org/~keithp/xserver randr-1.4-subwork

There's a "scaout_pixmap" in randrstr.h.

The crtc shadow functions seem obsolete given the new scanout pixmap
creation function, but they can be removed in a later ABI.

Is the "client->swapped" code in the protocol handling ever used?  It
looks like the SProc versions are plugged into the dispatch vector and they
just return BadImplementation.

> This also includes all of the protocol and library bits for the rest of
> the proposed RandR changes, but the server implementation hasn't been
> merged to this branch yet.
> 
> On to the per-crtc pixmap and setcrtcconfigs pieces. Hoping to have this
> merged over today.