On Tue, 7 Dec 2010 15:44:36 +0200, Ville Syrjälä <ville.syrj...@nokia.com> wrote:
> 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. Does the TV out support rotation in hardware at all? > 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. Hrm. Right now, there is per-CRTC rotation support information, so you can tell whether a particular CRTC does rotation at all, of course that's all mixed in with the software rotation support in the server which I'm hoping to deprecate when compositing managers gain appropriate built-in rotation support. If we remove the software rotation support, and expose only 'native' rotation in the per-CRTC information, then the question about SCANOUTPIXMAPINFO is whether two CRTCs need a *different* format for the same rotation. In you case, I think you'd set the CRTC that could drive the TV as supporting only RR_Rotation_0 and the CRTC that could drive the LCD as supporting RR_Rotation_0|RR_Rotation_90|RR_Rotation_270. Or do we need separate per-*output* rotation information which is distinct from the CRTCs too? -- keith.pack...@intel.com
pgpPBxDwamIPP.pgp
Description: PGP signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel