Need to deal with surface->resource == NULL and
surface->pending_state == NULL in some places.
v2:
* Avoid expanding conditions to multiple lines.
(Georges Basile Stavracas Neto)
v3:
* Use a single bailout condition in meta_wayland_client_owns_window as
well.
v4:
* Remove spare empty line in meta_wayland_surface_apply_state.
(Robert Mader)
* Add wl_resource_post_error calls in xdg-shell request handlers.
(Robert Mader)
* Drop checks in functions which can only be called if there's a valid
resource.
* Drop more checks which are unnecessary due to leaving the
SURFACE_DESTROY signal emission in wl_surface_destructor later.
v5:
* Move resource = surface->resource assignments to if (!resource) tests.
(Jonas Ådahl)
v6:
* Fix style issue per check-style.py.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
If we happen to handle a CLUTTER_TOUCH_BEGIN without a corresponding
CLUTTER_TOUCH_END at MetaWaylandTouch, we would still attempt to
reuse the older MetaWaylandTouchInfo, resulting in an assert triggered
as there is a stale touch reference on the previous surface.
Warn in place and create a new touch info struct to still fix the
broken surface accounting, instead of finding out the hard
way after the surface is destroyed. The assert is preserved to ensure
the accounting does not sneakily break anymore/further.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/584
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2251>
The way wl_seat capabilities work, by notifying clients of capabilities
changes, and clients consequently requesting the relevant interface
objects (pointer, keyboard, touch) is inherently racy.
On quick VT changes for example, capabilities on the seat will be added
and removed, and by the time the client receives the capability change
notification and requests the relevant keyboard, pointer or touch,
another VT switch might have occurred and the wl_pointer, wl_keyboard or
wl_touch already destroyed, leading to a protocol error which kills the
client.
To avoid this, create the objects when requested regardless of the
capabilities.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1797
Related: https://bugzilla.gnome.org/show_bug.cgi?id=790932
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/77>
We had code in both backends that sort of independently associated
sequences to slots. Make both transform slots to sequences the same
way, so they may share the implementation convert those back to slots.
This helper now lives in Clutter API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
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/1486
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/1486
The end goal is to have all clutter backend code in src/backends. Input
is the larger chunk of it, which is now part of our specific
MutterClutterBackendNative, this extends to device manager, input devices,
tools and keymap.
This was supposed to be nice and incremental, but there's no sane way
to cut this through. As a result of the refactor, a number of private
Clutter functions are now exported for external backends to be possible.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
When the touch_down event was not delivered to Wayland clients, there's
no point in keeping the touchpoint in our list, so remove it early
inside update() instead of removing it after the touch ended.
This fixes a crash inside touch_handle_surface_destroy() where the
assertion to make sure the surface is removed fails because the
touch_count of the surface never reached 0. This in turn happened
because a new sequence was added, while a (already ended one) wasn't
removed from the touch->touches list before. This caused the touch
counter to get incremented by 1 while no new sequence was added to the
list (because Clutter reuses sequence IDs, the old sequence is equal to
the new one, i.e. the new sequence already is present in the list).
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/200https://gitlab.gnome.org/GNOME/mutter/merge_requests/426
The touch handling code uses evdev API, thus will not work on other
backends. Thus, put touch handling code behind runtime backend checks
and only include the code when native backend support is enabled.
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
The function is intentionally provided as macro to not require a
cast. Recently the macro was improved to check that the passed in
pointer matches the free function, so the cast to GDestroyNotify
is now even harmful.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/176
If input happens to be grabbed somewhere along the shell, and ungrabbed
while a touch operation is ongoing, the wayland bits will happily start
sending wl_touch.update events from an undeterminate point, without
clients having ever received wl_touch.down for that id.
Consider those touches grabbed for the entirety of their lifetime, if
wl_touch.down wasn't received by the client, no other events will.
https://bugzilla.gnome.org/show_bug.cgi?id=776220
When disabling the device/capability, we can't rely on cancelled events
being emitted timely, because the capability will be already disabled by
then, all touches must be cancelled immediately then.
https://bugzilla.gnome.org/show_bug.cgi?id=772929
Make the device <-> seat association permanent, and move it into
MetaWaylandInputDevice. A device will never be disassociated with a
seat, so there is no point in unsetting it.
https://bugzilla.gnome.org/show_bug.cgi?id=771305
Add a new object class, MetaWaylandInputDevice, and make all device
classes (pointer, keyboard, touch) inherit it. In the future common
functionality may be placed there.
https://bugzilla.gnome.org/show_bug.cgi?id=771305
Right now we just check the pointer serial, so the popup will be
immediately dismissed if the client passes a serial corresponding to
another input device.
Abstract this a bit further and add a meta_wayland_seat_can_popup() call
that will check the serial all input devices. This makes it possible to
trigger menus through touch or keyboard devices.
https://bugzilla.gnome.org/show_bug.cgi?id=756296
Refuse to create a touch resource if we don't have the capability
(for misbehaving clients), and don't attempt to use touch data
structures that are not initialized.
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
Clutter touch events are translated into events being sent down
the interface resource, with the exception of FRAME/CANCEL events,
which are handled directly via an evdev event filter.
The seat now announces invariably the WL_SEAT_CAPABILITY_TOUCH
capability, this should be eventually updated as devices come and
go.
The creation of MetaWaylandTouchSurface structs is dynamic, attached
to the lifetime of first/last touch on the client surface, and only
if the surface requests the wl_touch interface. MetaWaylandTouchInfo
structs are created to track individual touches, and are locked to
a single MetaWaylandTouchSurface (the implicit grab surface) determined
on CLUTTER_TOUCH_BEGIN.
https://bugzilla.gnome.org/show_bug.cgi?id=724442
