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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
