On Mon, Dec 06, 2010 at 10:01:03AM -0800, Keith Packard wrote: > On Mon, 6 Dec 2010 09:20:29 -0800, Aaron Plattner <[email protected]> > 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 <[email protected]> > > 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. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
