This is already taken care of in meta_backend_monitors_changed(), called
from the same code paths that emit ::monitors-changed-internal. It is
better to leave this up to backend internals.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403
Rely on the seat stage, or other ways to fetch it. Also rely that
there is actually a single stage, so that we assign the right stage
to all events going out of the seat, in a single place.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403
This is a bit scattered around, with the setter/getter in Clutter, and
it only being only directly honored in Wayland (it goes straight through
device properties in X11).
Make this private native API, and out of public ClutterInputDevice API.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403
Make the upper part agnostic about the device being relative in order
to avoid applying keep-aspect. The X11 bits already are, so make it
sure it's also the case for the native backend.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403
The semantics for libinput events are not as expected here. Besides
it's pointless, as those should arrive per-slot in a burst, and we
cancel on the first event.
We can simply use the Clutter event for this.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403
As it does seem from a read to libinput code, TOUCH_CANCEL events
actually do contain slot information, and are emitted per-slot.
This means we can avoid iterating over the slots ourselves, they
are still expected to be sent altogether.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403
We want to coalesce multiple touch events into the same wl_touch.frame
event. Instead of poking internals to peek the touch events (and their
slots) coming at us before we handle them, simplify things by queueing
the event at a slightly lower priority than events, so we are ensured
to handle all pending input events before sending the event.
If there's no pending events, we can just send the frame event. As it
doesn't make sense to hold any longer.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403
Delay the addition and removal of devices using ClutterDeviceEvent's so that
they are processed following the libinput event order, and that we don't
have to flush the events on removal.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1371
When a device is removed from the seat the events that this device may have
emitted just before being removed might still be in the stage events queue,
this may lead a to a crash because:
Once the device is removed, we dispose it and the staling event is
kept in queue and sent for processing at next loop.
During event processing we ask the backend to update the last device
with the disposed device
The device is disposed once the events referencing it, are free'd
The actual last device emission happens in an idle, but at this point
the device may have been free'd, and in any case will be still disposed
and so not providing useful informations.
To avoid this, once a device has been added/removed from the seat, we queue
ClutterDeviceEvent events to inform the stack that the device state has
changed, preserving the order with the other actual generated device events.
In this way it can't happen that we emit another event before that the
device has been added or after that it has been removed.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1345
Clutter device events are special events coming from the backend when an
input device is added or removed.
When such events are processed, we should make the seat to handle them by
calling vfunc that can be implemented by each backend and eventually
emitting the appropriate signal.
If a device is removed, we can also safely dispose it, as it can be
considered stale at this point.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1371
Add clutter device added and removed events to allow processing of them as
it happens in the backends, queuing them and performing actions in order.
This allows not to loose any event that is performed just before removing or
disabling a device, and still process the events in order in the event
queue.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1371
When removing a device that has been just marked as the last in use, we may
try to notify that a NULL device is the last one.
This is not supported, as both update_last_device() and the clients of the
"::last-device-changed" signal are assuming that the last device is always
a valid ClutterInputDevice.
So let's avoid erroring, and stop the idle when clearing the current device.
Related to: https://gitlab.gnome.org/GNOME/mutter/-/issues/1345https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1371
