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

[Dave Airlie]

>> >> 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).

/me needs to go find James's vision, but my general aim is don't have
Window infomation
pass into driver so I can later split the ScreenRec into Protocol side
and Driver side, but
I reckon cleaning up things in the current ScreenRec first might make
it an easier transition.

So at the moment the place that pixmap->window binding happens is in
the fb layer,
we also have fboverlay which does multiple pixmap->window binding in a
private. I was going to
try and move that up a layer or two, so we just handle pixmaps in fb +
all the XAs as much as possilbe.

This was why I wanted to burn miOverlay first because frankly the
interface isn't all that clear
to me, it sets a magic copyUnderlay flag, then miOverlayUnderlayPtr
picks it up later, nothing
currently open seems to pick that stuff up, maybe some of the older
DDX use it so I can go dig it out.

Maybe if we could document the expected behaviour of copy window when
that flag is set and
what drivers can do with it it might make more sense to me. (and yes
if this is documented somewhere feel free to kill me).

>> 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?

Yeah that doesn't make sense, I just though it might help the driver
distinguish pixmaps
but it would really need to know more than just an index.

Dave.