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 <[email protected]> > 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
signature.asc
Description: Digital signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
