Per-CRTC pixmaps in RandR RFC Version 0.1 2010-03-01 Keith Packard kei...@keithp.com
Target problem scope: 1) Driving multiple monitors where the desired screen geometry exceeds the capacity of the rendering and/or scanout engines. 2) Integrating compositing with projective transformation into a single operation. 3) Eliminating visual artifacts during rotation by eliminating all modeset operations in this path. 4) Along the way, provide an atomic multi-mode-set operation to reduce the number of visual operations required to achieve the desired configuration. Outline of the proposed solution: 1) Add a request to create a pixmap that can be used for scanout purposes. The parameters to this would be the geometry of the pixmap (WxHxD) and the set of desired hardware rotations to be supported (for hardware which has the ability to scanout in different orientations). 2) Add a request to set a window's pixmap. Composite provides a way to get the window's pixmap, this adds the ability to set the same. This isn't strictly necessary for X to perform the desired operations, but I think it will make GL happy to have a window as a double buffered target. 3) Add a new 'multi mode set' request that takes a whole pile of outputs, crtcs, modes and scanout pixmaps and mashes them all together. 4) Add a new request that changes the projective transform used to convert screen coordinates to monitor coordinates when displaying the pointer sprite. I'd suggest that we also include a transform to convert the sprite image. 5) Add suitable 'query' operations to discover the capabilities of the scanout engines in terms of maximum geometry and rotation. How would this work: The compositing manager would allocate one scanout pixmap per non-overlapping crtc, it would then create a window for each pixmap and set the window's pixmap to the per-crtc scanout pixmap. At that point, it can draw whatever it likes to the scanout pixmap using regular GL operations. An application window which spans two monitors will be drawn to both scanout pixmaps. For rotation, the compositing manager would ensure that the scanout pixmap could be used with the desired rotation, then it would set the sprite transform as needed and just start painting the window contents using the specified rotation. No mode set would be required, and the compositing manager could even smoothly animate the rotation operation. As you can see, this is just a rough sketch of an idea, but it has some nice properties: 1) It exposes what the hardware does, a classic X dodge to make applications do all of the hard work. 2) It solves several current problems with one fairly simple addition to the system. 3) It doesn't require changes to applications or direct rendering libraries. I haven't even thought about what the protocol spec will look like, or how to code this up, I'm just looking for some early feedback about the design in the hopes that we can improve it now while the improving is easy. -- keith.pack...@intel.com
pgpjxcLKS97YF.pgp
Description: PGP signature
_______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel