On Mon, 6 Dec 2010 09:20:29 -0800, Aaron Plattner <[email protected]> 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 <[email protected]>
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?
--
[email protected]
pgp6b6xOCs68l.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
