[PATCH] [RFC] dix: don't use CopyWindow in driver level interface.

[Aaron Plattner]

On Thu, Mar 31, 2011 at 05:01:20PM -0700, Keith Packard wrote:
> On Thu, 31 Mar 2011 15:49:36 -0700, Aaron Plattner <aplattner at nvidia.com> wrote:
> > Would this be multiple backing pixmaps like how James envisioned, or
> > something else?  The problem here is that while pWin may be in the overlay,
> > it may have child windows in the underlay so the driver needs to copy
> > those pixels around too.
>
> It seems like the driver should have sufficient information based on the
> pixmap it is passed -- pass one of the scanout pixmaps and it should
> know to copy bits in the other scanout pixmaps.

That's not enough information to know how much of each plane need copying,
though.  Say you have an overlay window with a main-plane child window
punching a hole through it.  You want to copy around only the main plane
pixels covered by the visible areas of the child window, and not anything
else (since that's the whole point of having an overlay).  The driver won't
be able to figure that out if all it gets is a pixmap and a region to copy
that covers the whole parent window.

I agree that the "copyUnderlay" stuff in mioverlay is hacky, but it does at
least tell the driver which pieces are where.

(Dave: the mioverlay layer wraps CopyWindow and then calls down twice, once
for the overlay and once for the underlay.  It communicates this to the
driver by setting that "copyUnderlay" flag that the driver is expected to
query via miOverlayCopyUnderlay).

> The goal is to eliminate all protocol objects from the driver interface,
> it seems like the simplest way to remove the protocol Window objects
> From the driver interface is to expose only pixmaps.

I agree.  We just need to make sure the driver still has everything it
needs to be able to implement everything.