[PATCH 0/3] Fix erroneous borderSize usage in event processing
Adam Jackson
ajax at redhat.com
Thu Aug 7 13:39:32 PDT 2014
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...
> 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.
> 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. borderClip, classically,
is borderSize clipped by siblings. In a RedirectNone world, these regions
are identical for both output clipping and input 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?
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.
- ajax
More information about the xorg-devel
mailing list