Proposal for per-CRTC pixmaps in RandR

[Keith Packard]

		Per-CRTC pixmaps in RandR
		   RFC Version 0.1
		      2010-03-01
		     Keith Packard
		   keithp at 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.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100301/ca8a1ef6/attachment.pgp>