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

[Dave Airlie]

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?

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

Ideas on a postcard?

Dave.