[PATCH 2/2] damageext: Xineramify (v4)
ajax at redhat.com
Thu Oct 10 04:43:07 PDT 2013
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?
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.
More information about the xorg-devel