Proposal for per-CRTC pixmaps in RandR

[Aaron Plattner]

On Fri, 2010-03-12 at 13:46 -0800, Keith Packard wrote:
On Fri, 12 Mar 2010 12:47:13 -0800 (PST), Andy Ritger <aritger at nvidia.com> wrote:
> > Creating a window the size of the scanout pixmap and then plugging
> > the scanout pixmap in as the window's backing pixmap feels a little
> > backwards, sequentially.  If the intent is just to give the scanout
> > pixmap double buffering, you should be able to create a GLXPixmap from
> > the scanout pixmap, and create that GLXPixmap with double buffering
> > through selection of an appropriate GLXFBConfig.  However, the GLX spec
> > says that glXSwapBuffers is ignored for GLXPixmaps.
>
> Precisely. The window kludge is purely to make existing GL semantics
> work as expected.
>
> > However, a more flexible solution would be to provide a mechanism to
> > create a scanout window (or maybe a whole window tree), rather than a
> > scanout pixmap.  The proposed scanout window would not be a child of
> > the root window.
>
> All windows are children of the root window, and we already have a
> mechanism for creating windows which are drawn to alternative
> pixmaps. Using this mechanism offers a simple way to express the
> semantics of the situation using existing operations.
>
> The goal is to really get applications focused on the notion of pixmaps
> containing pixels and windows as being mapped to pixmaps.

Could we achieve this by adding a new redirection type,
CompositeRedirectManualForScanout or something?  Then the server would
create the backing pixmap for the window with a special FOR_SCANOUT usage
hint.  That way, we could avoid adding new requests or changes to the
which-pixmap-backs-this-window semantics, and it ought to make it easier to
adapt later if we add a "Create a window with N backing pixmaps" request.

You could redirect a child of the COW to keep it from interacting with
normal windows.