Sometimes we can get a host event without having the display up and
running yet. Just don't pass it to the compositor in that case, since it
won't be possible for it to have any event that matters.
MetaGestureTracker has been separating the "did I handle an event?" and the
"should the event be filtered out?" questions, merge this and make
handle_event() reply to "should the event be only handled by me?".
If a sequence wasn't accepted yet by the gesture tracker, the event will
go through (eg. not handled exclusively by the gesture tracker) and it'll
still be processed by Clutter, triggering gesture actions, and maybe
changing the sequence into other state.
https://bugzilla.gnome.org/show_bug.cgi?id=733631
The grabbing state is now checked for both pointer/touch devices
within the seat, and the grab start coordinates returned by
meta_wayland_seat_get_grab_info().
https://bugzilla.gnome.org/show_bug.cgi?id=733631
On X11 this works because only emulated pointer events are listened for. On
wayland, the single touch behavior must be enforced in touch events, ignoring
every other sequence.
https://bugzilla.gnome.org/show_bug.cgi?id=733631
This function tells the obvious on X11, and implements a similar mechanism
on wayland to determine the "pointer emulating" sequence, or one to stick
with when implementing single-touch behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=733631
Due to the way the MetaGestureTracker processes every touch event, this
will tell as closely to Clutter as possible the current number of touches
happening on the stage.
Even though, this is subject to windowing behavior, on X11, rejected touches
will be soon followed by a XI_TouchEnd event, so the compositor will stop
seeing touch sequences that are still operating on clients. On wayland, touch
sequences are processed by the compositor during all their lifetime, so these
will stay on the MetaGestureTracker with META_SEQUENCE_PENDING_END state, yet
still tracked.
https://bugzilla.gnome.org/show_bug.cgi?id=733631
On wayland, touches are initially both handled by the compositor and sent
to clients, proceeding to cancellation on clients only after the compositor
claims the sequence for itself. Implement the cancellation detail through
MetaGestureTracker::state-changed.
https://bugzilla.gnome.org/show_bug.cgi?id=733631
The capability flags are determined from the device types of the slave devices
that are currently attached. This also happens whenever a device is added or
removed, so the capabilities are kept up to date, and clients know about these.
On VT switch, all slave devices are temporarily removed, so the cascade of
signals will make the seat end up with capabililities=0 while input is suspended.
https://bugzilla.gnome.org/show_bug.cgi?id=733563
Anytime the keymap is changed, either directly, or indirectly through the
keyboard capability being released/initialized, there should be a
notification of the modifiers being changed too.
https://bugzilla.gnome.org/show_bug.cgi?id=733563
Otherwise the focus_surface_listener list element becomes stale, and then
mangled if the devices' data is initialized again, and the memory memset().
https://bugzilla.gnome.org/show_bug.cgi?id=733563
This doesn't match what Weston does. I don't know of any apps that this
fixes (we don't have any apps that even use non-zero dx/dy, I don't
think), but this is part of a cleanup for window geometry.
