[PATCH] Refine compositor grabs behavior

[Peter Hutterer]

On Thu, Nov 12, 2015 at 01:27:05PM +0100, Carlos Garnacho wrote:
> Hey there,
> 
> I think it is worth to bring back some discussion on the client-side
> behavior during compositor grabs which I started a few months ago, for
> reference the thread started at:
> http://lists.freedesktop.org/archives/wayland-devel/2015-April/021407.html
> 
> And the first patch sent was:
> http://lists.freedesktop.org/archives/wayland-devel/2015-June/022520.html
> 
> This patch I'm sending is the result of discussion in that last thread,
> it further documents leave events so it is made clear how to deal with the
> cases when input is taken away from the surface, and adds a missing
> wl_touch.leave event, so there's means to "cancel" individual touch points.
 
we had a bit of a discussion on IRC here, this is the attempt of a summary:
A wl_touch.enter/leave event pair makes sense for some use-cases and can fix
the xdg_popup case. The idea here is that if you move between two surfaces
*of the same client* you send a wl_touch.leave(old_surface) followed by a
wl_touch.enter(new_surface), with a wl_touch.update all within the same
frame. Both enter/leave carry the touch ID and are thus per touchpoint.

If a client is capable of handling the new enter/leave events, this is a way
to tell them that a touch has moved away and that surface doesn't have it
anymore, and for the new surface that a touch has appeared but wasn't set
down in that spot (so it won't trigger in-client gestures like tapping).
In X term, a wl_touch.enter/leave is similar to NotifyGrab.

When moving between surfaces of different clients, there is only a leave
event (where applicable) but no enter event, so you force the user to start
a new touch in the target surface. That may or may not be encoded in the
protocol, but it seems like the most sensible and side-effect free approach
in the compositor.

Next point is event symmetry: on a new client we can assume they know how to
interpret events, so we could keep the events in symmetry, i.e. forcing a
touch up/down with every leave/enter. Short of being nice, I'm not sure what
that brings us.

It does help with older clients since we can simply drop the enter/leave
event and send the fake up/down and get predictable behaviour. It'll still
be a behaviour change from the current implementation where sometimes you
don't get the touch up...

> I'm however not too thrilled about reusing leave events for these
> situations, my reasons:
> 
> - Even if these were the intended semantics, everyone (including weston) is
>   getting this wrong, so this is effectively a behavior change that
>   compositors and toolkits do need to adapt to.
> 
> - The fact that this is just a footnote in docs will make it easy to miss,
>   so there will be a time when compositors jumping early on this will confuse
>   the hell out of clients that didn't adapt yet.
> 
> - There are grabbing situations where the focus surfaces don't really change 
>   within the compositor (eg. dragging a window, it will probably "have" the
>   keyboard focus, you however don't want keypresses to trigger anything on
>   the client). I admit this is an implementation detail, but temporarily
>   unsetting focus surfaces doesn't strike me as the best solution, plus there
>   are other cases where you legitimately want to move the focus to another
>   surface.

as for pointer and keyboard leave events, afaict the ship has sailed on this
and this has been the behaviour for long enough that your additions just
document the current behaviour. Any change will likely break things, so
documenting the cases where a button or key release event gets left hanging
seems the only solution.

> My suggestion for this would be to split into a separate event per input
> interface, that'd make older clients as ignorant of these issues as they are
> now without actively breaking them. I'm however sending a patch as it was
> suggested in the previous threads.
> 
> Also, I would like to document a behavior meant for grabs, i.e. For most
> situations I think it makes sense for the compositor to grab not only the
> pointer/touchpoint triggering the grab, but all seat devices at once,
> because any of these could still be triggering stuff that renders this grab
> useless (eg. triggering an xdg_popup during window dragging). I can't think
> though of any place to put this piece of information, besides scattering it
> across the places where we expose "grabs" in wayland/xdg_shell/... protocols,
> suggestions here welcome.

There is a prose section in the documentation (in docbook form), it'd be
fairly trivial to add a "Expected Compositor Behaviours" chapter.

Cheers,
   Peter

> 
> Cheers,
>   Carlos
> 
> Carlos Garnacho (1):
>   protocol: Define further the behavior of input on the presence of
>     grabs
> 
>  protocol/wayland.xml | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 57 insertions(+)
> 
> -- 
> 2.5.0