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

Dave Airlie airlied at gmail.com
Thu Mar 31 18:44:42 PDT 2011


On Fri, Apr 1, 2011 at 10:35 AM, Aaron Plattner <aplattner at nvidia.com> wrote:
> 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.
>

Can you look at xaaOverlay.c and tell me if what it does is approx
what you guys do internally?

or do you have further requirements, I'll try and make something work
that fixes this in
XAA also and you can tell me if it'll work for you.

Dave.


More information about the xorg-devel mailing list