Any number of touches >= 3 starts a drag operation, but the
window jumped around as new touches joined. So recalculate
the touch drag area/hotspot and tiling mode as expected
as soon as touches enter/leave the drag op.
If during a multitouch drag, the area height is 1.5x the original
size, the window is tiled to the closest side the hotspot is on
(left/right).
If both with/height are 1.5x the original, the window is maximized.
The touch sequence is possibly unhandled, but we need a call
to meta_window_end_touch() so such touch sequences are notified
to the server, this would trigger the real TouchEnd event as
the touch is rejected, but should be a no-op the second time
This function would return the slave device behind and
event, this is mostly needed for touch passive grabs,
as XIAllowTouchEvents() at the moment requires a slave
device, this has changed in the latest drafts of the
multitouch protocol.
This function tells whether an input event should be ignored,
the only current reason being the duplication of touch events
and their emulated XI2 pointer event counterparts.
This will be the device popping up the menu, gtk_menu_popup()
uses the current GTK+ event device, and that might not even be
filled up with mutter event bypassing.
Now either the current focus keyboard or the client pointer
(i.e. the pointer paired to the last keyboard that had the
window focus) are used to guess the pointer that should be
grabbed.
The client window determines the device pair that is used for
core protocol calls such as XQueryPointer(), so different
clients using the core protocol can be focused by different
devices simultaneously.
This is nothing but the beginning, things work with a single
pointer/keyboard pair, but will be largely broken with multiple
devices interacting simultaneously, so we first need a policy
to establish a sensible behavior for extra pointer/keyboard
pairs.
the MUTTER_USE_CORE_DEVICES envvar has been added to force use
of Xlib core events for devices in order to check for regressions.
There is now a MetaGrabInfo struct, holding all information about
an ongoing grab, there were unfortunately no means of making this
commit smaller, as things are too intertwined to separate it,
On places where it was most obvious, the correct device has been
used (in reaction to events, for example), in other parts, the
private API has been extended to include the MetaDevice (or device
ID for core.h functions), in other places, the virtual core
pointer/keyboard are used out of cluelessness.
This is the only use in the UI part of core functions not
exported via core.h, but this is sort of a hack within a hack,
and still better than doing the XInput2 vs core dance again.
