On Mon, 6 Dec 2010 09:42:24 -0800, Aaron Plattner <[email protected]> wrote: > On Mon, Dec 06, 2010 at 08:44:41AM -0800, Keith Packard wrote: > > On Mon, 6 Dec 2010 15:20:01 +0000, Daniel Stone <[email protected]> > > 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.
That's why I asked Daniel -- he was dealing with a phone that had hardware rotation support (some OMAP thing), and he says that the hardware will rotate on any CRTC (it's got TV out). > 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? Right. The question is only whether separate outputs need *different* scanout pixmap formats. > 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? I wonder how it works today; I've got a phone that appears to allow applications to rotate the screen, do they actually have applications doing the RandR calls? Sounds like we might want to consider adding a configuration redirection mechanism at some point... -- [email protected]
pgpcWIHyXS3Fv.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
