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

[Aaron Plattner]

On Thu, Mar 31, 2011 at 02:14:03PM -0700, Dave Airlie wrote:
> On Fri, Apr 1, 2011 at 5:05 AM, Aaron Plattner <aplattner at nvidia.com> wrote:
> > On Wed, Mar 30, 2011 at 10:21:42PM -0700, Dave Airlie wrote:
> >> From: Dave Airlie <airlied at redhat.com>
> >>
> >> This splits CopyWindow before the exa/fb layers, and uses a
> >> new interface called PixmapCopyRegion to do the actual copy.
> >>
> >> The main point of this is a step towards removing WindowPtr's
> >> from the interface that drivers see or use.
> >>
> >> I've only lightly tested this with Xephyr in fb and fakexa modes,
> >> but moving a window still moves and goes via the new paths.
> >>
> >> Open thoughts:
> >> a) exa should I restore the fallback hook for pixmapcopyregion
> >> instead of copy window? feeling I have is yes.
> >>
> >> b) should the hook take Pixmap or Drawable, it probably at least
> >> needs an assert if it takes drawable and gets passed a window.
> >>
> >> c) is PixmapCopyRegion a good enough name?
> >>
> >> uxa: left as an exercise for the reader.
> >>
> >> (not signed off yet).
> >
> > Is this what you were alluding to when you were talking about breaking the
> > overlay code?  We wrap CopyWindow so we can blit bits of the overlay and
> > underlay surfaces around as appropriate.  I guess this would translate to
> > two calls to PixmapCopyRegion on the overlay pixmap, and we'll just have to
> > figure out from the combination of pPixmap == overlay pixmap &&
> > miOverlayCopyUnderlay that we're supposed to be copying pixels around on
> > the screen pixmap instead?
> >
> 
> Well I was thinking of adding an array of pixmapptrs to WindowPtr with
> an numPixmaps,
> as a future step, then getting rid of the GetWindowPixmap call tree,
> this would then
> iterate over all the pixmaps attached to the WindowPtr for these interfaces?

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.  Maybe it would make more sense to teach mioverlay
about that, then call PixmapCopyRegion for the overlay region on the
pixmap(s) associated with pWin (i.e. the overlay pixmap), and then for the
underlay on with the screen pixmap.  Thinking about how that would interact
with Composite hurts my brain (right now we don't support overlays and
Composite at the same time).

> I suspect we might need to pass a pixmap index maybe to the PixmapCopyRegion
> or maybe the driver can stash that somewhere.

Can you clarify exactly what this index would be indexing?

> Ideas on a postcard?
> 
> Dave.