[PATCH] RandR version 1.4 additions

[Keith Packard]

On Mon, 6 Dec 2010 09:20:29 -0800, Aaron Plattner <aplattner at nvidia.com> wrote:

> I don't see a corresponding #undef PictFormat.

Nice catch.

> This still causes pangs of worry that it's going to cause some weird
> interaction problem down the road with features like stereo or overlays or
> whatever, but I think that as long as we treat windows that are not the
> magic scanout window as being redirected, and the magic scanout window as
> being unoccluded and full-screen, then it all works out.

The whole 'associated with a window' thing is gone now, so there isn't a
magic scanout window anymore. Applications just get the pixmap.

I imagine we'll end up explicitly supporting things like multiple
scanout buffers for stereo and video overlays. Seems like we could add
additional RandR stuff for that pretty easily.

> I wonder if this'll be useful for games as the full-screen exclusive mode
> that's been so sorely missed.

Compositing managers have gotten pretty good about getting out of the
way when apps want to run full-screen, but this change allows them to
even change the depth and switch modes without affecting any other
applications.

> Can this include indexed formats?  Should there be some provision for
> specifying a colormap along with the pixmap to assign the pixel-to-color
> transfer function, or is the gamma ramp interface sufficient?

A fine question, to which I'd love to answer 'no'. How about this:

SCANOUTPIXMAPINFO { format: PICTFORMAT
		    maxWidth, maxHeight: CARD16
		    rotations: SETofROTATION }

	'format' is the format of the pixels within the scanout
	pixmap. Only 'Direct' formats are supported, this will never
	be an 'Indexed' format.

	'maxWidth' and 'maxHeight' define the largest supported
	scanout pixmap. There is no minimum size; scanout pixmaps down
	to 1x1 may be created.

	'rotations' lists the set of rotations which can be provided
	without additional latency or memory usage within the
	environment. This typically means that they are supported
	directly by the hardware. It is expected that a compositing
	manager will perform other transforms as a part of the
	compositing process in conjunction with the sprite transforms
	described in this extension.

The alternative is to provide a request to set a crtc colormap, which we
could do if there was interest.

> If somebody wants to use this for full-screen exclusive games, they'll
> probably want to install the game's colormap on that crtc and have colormap
> changes from the application apply to the CLUT hardware like they do for
> normal windows today.

RandR already supports per-crtc gamma tables, so applications can
manipulate the brightness levels easily enough.


> Aside from the minor spelling issues, the missing #undef PictFormat, and
> the colormap question above,
> 
> Reviewed-by: Aaron Plattner <aplattner at nvidia.com>

Let's get closure on the colormap issue then.

I still have a question pending about what we do when the scanout pixmap
is destroyed. Do we clean up and get the CRTC displaying screen contents
again? Or do we leave the scanout pixmap sitting there and the CRTC
displaying old contents?

-- 
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/20101206/fc0f1996/attachment.pgp>