[PATCH 2/2] damageext: Xineramify (v4)

[Adam Jackson]

On Wed, 2013-10-09 at 13:02 -0700, Keith Packard wrote:
> Adam Jackson <ajax at redhat.com> writes:
> 
> > Well, no, but it could never matter.  The per-screen reports are already
> > clipped to their respective borderClips (which, as noted, are clipped to
> > their containing root), and then I'm unioning them all together on
> > screen 0's DamagePtr.  The union of per-root-window borderClips can't
> > exceed the Xinerama view of the border clip by definition.
> 
> Oh, so screen 0 contains all of the damage. Do internal Damage users
> handle this OK? Or are you reporting out per-physical-screen damage to
> them and only tracking this union damage for applications?

The latter.

So.  A DamagePtr is the internal listener object, and a DamageExtPtr is
a view onto a single DamagePtr on the wire.  With this patch, there's a
new type of PanoramiXRes pointing to N DamageExtPtrs, with the report
hooks wired up so that screens 1-N union (the region of) their DamagePtr
onto that of screen 0, and then immediately empty their own DamagePtr.

When damage is generated internally, we report it using one of:

    void DamageRegionAppend(DrawablePtr pDrawable, RegionPtr pRegion);
    void DamageDamageRegion(DrawablePtr pDrawable, RegionPtr pRegion);

In either case we hit damageRegionAppend() which then walks the list of
damages registered on that drawable and calls the associated report
function for each.  Internal listeners still track things per-screen
because they don't know about Xinerama; the Xinerama listeners pile on
the Xinerama listener for screen 0.

Phrased another way: miext/damage/ doesn't change here, and that's what
we use internally.  But damageext/ does, because that's the protocol,
and Xinerama needs to mangle the protocol.

- ajax