[PATCH 0/3] Fix erroneous borderSize usage in event processing

[Keith Packard]

Adam Jackson <ajax at redhat.com> writes:

> Keith Packard <keithp at keithp.com> writes:
>
>> It seems like the old server code was just broken.
>
> In that its use of borderSize was wrong for ignoring sibling clip, yeah
> probably.  Attached series attempts to fix the bits you pointed out.
> However that only corrects the classic case...

Given that the code has operated this way since the very beginning of
the sample server development, I'm tempted to say that the code is now
the spec and that we should update the documentation and not the
code. It's a subtle change, and I think we can safely assume that
applications are not being broken by the current behavior.

>> We can almost use the borderClip saved by composite, except when there
>> are nested composited windows.
>
> ... and I think this is with reference to the redirected case.

Yup. 

>> In that case, we would need to recursively intersect the saved
>> borderClips to the root.
>
> Unfortunately my IRC client crashed between this discussion and now, so
> let's see if I remember this right.  borderSize is the total input surface
> of the window - the union of the area available for subwindows and graphics
> and the area of the border - clipped by ancestors.

borderSize can only be used for input if you walk through the siblings
From the top down and pick the first one which contains the cursor,
which is what the dix code does.

> borderClip, classically, is borderSize clipped by siblings.  In a
> RedirectNone world, these regions are identical for both output
> clipping and input hit testing.

Except for the siblings issue, which forces you to walk the sibling
windows from the top down to perform hit testing.

> Redirecting a window modifies these regions.  borderSize is no longer
> clipped by ancestors (so that drawing doesn't get discarded just because
> you moved the window offscreen), and borderClip - still derived from
> borderSize - is no longer clipped by siblings (so that drawing doesn't get
> discarded just because the window is partially obscured).  Both of these
> alterations are valid in output operations only; hit testing still wants
> classic-like definitions of the border regions, and we would need to supply
> such to the routines modified in this series to fix grabs on redirected
> windows.
>
> Right?

Right, the modifications are only valid for output clipping. Currently,
the input code only uses borderSize, but if we like, we can make it use
borderClip instead, with some modest performance impact as borderClip
often has more boxes than borderSize.

> I have some documentation in the works for this since I can't manage to
> keep it in my head, I'll send it along once I understand the Composite bits
> of mivaltree.c better.

Ok.

Given that we're going to need to walk the tree and perform multiple
region operations for hit testing, perhaps we should just continue to
use borderSize and walk up until there are no more redirects above us,
clipping to suitable borderSizes as we go. That shouldn't be much more
expensive than the current code.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140812/1df3512c/attachment.sig>