[PATCH] RandR version 1.4 additions

[Aaron Plattner]

On Mon, Dec 06, 2010 at 10:01:03AM -0800, Keith Packard wrote:
> On Mon, 6 Dec 2010 09:20:29 -0800, Aaron Plattner <aplattner at nvidia.com> wrote:
> > 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.

Fine.

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

I guess we could add that later.

> > 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.

Well, I was envisioning a game that today creates a window and installs a
DirectColor colormap.  A compositor could use the hypothetical
SetWindowPixmap to point it at the scanout pixmap and have it operate as
usual, but I think you're right -- just unredirecting the window and
pointing scanout back at the screen pixmap seems better.

> > 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'm okay with dropping that idea for now.

> 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?

I like the idea of not freezing the screen when the CM crashes.