Sprite transforms in RandR
daniel at fooishbar.org
Mon Dec 6 08:57:55 PST 2010
On Mon, Dec 06, 2010 at 08:44:41AM -0800, Keith Packard wrote:
> On Mon, 6 Dec 2010 15:20:01 +0000, Daniel Stone <daniel at fooishbar.org> 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
Fair play. :)
> > > 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.
> I'm hoping the new 'set' entry point will do what you want; it gets
> called before xf86CrtcRotate in every case now (unlike set_mode_major
> which doesn't get used when the server changes only the origin).
Sure. It does arguably disadvantage drivers which can't/won't do the
one-shot, but c'est la vie. It's like a 20-line patch anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the xorg-devel