Sprite transforms in RandR

[Daniel Stone]

Hi,

On Sun, Dec 05, 2010 at 06:15:04PM -0800, Keith Packard wrote:
> On Sun, 5 Dec 2010 16:38:52 -0800, Aaron Plattner <aplattner at nvidia.com> wrote:
> > 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?
> 
> Yes. Daniel Stone was working with some whacky omap hardware last year
> and if he wanted to have a scanout pixmap that *could* be rotated, he'd
> need to know in advance.

Yep, the OMAP handles rotation by accessing through a special memory
window set up by the SDRAM scheduler: you tell it the mode associated
with it, and it translates the reads and writes for you.  It also has
its own pitch alignment requirements, etc, so we need to know in advance
if it's going to be used.

(Also, memory is fairly tight, so the aim was to be able to go from an
 800x480 unrotated screen with a matching-sized pixmap, to a 90°
 rotation - 480x800.  Previously, this required you to disable the CRTC,
 change the screen size, and then re-enable with the new configuration.)

> > 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.
> 
> Good point. I hadn't considered the case where different crtcs would
> have different rotation support. Definitely seems possible
> though. The current design doesn't tie the scanout pixmaps to a specific
> crtc, so I didn't think of having per-crtc scanout pixmap formats.
> 
> I don't want to design beyond the hardware, so perhaps Daniel will know
> if this was the case in the hardware he was dealing with.

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.

This also required a patch to add a rotate hook to the RandR CRTC API
which let the driver deal with rotation requests and skip the whole
shadow + copy nightmare.  I did have this on p.fd.o at one point, but it
appears to have been lost; Tiago might know where it is.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101206/804e8786/attachment.pgp>