It relied on indices in arrays determining tile direction and
non-obvious bitmask logic to translate to _GTK_EDGE_CONSTRAINTS. Change
this to explicitly named edge constraints, and clear translation methods
that converts between mutters and GTK+s edge constraint formats.
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.
We might unset focus, or already be out of focus (e.g. an X11 client or
clutter text entry is focused) when a text-input state is committed by
the client. We handled this before, except when text input was
explicitly disabled by the client, the Wayland text-input was in focus
by the input method, and it focused itself out.
Simplify the logic a bit by just dropping the state on the floor in all
cases where after any potential focus changes were done, we are not
focused.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/353
When repicking after a surface was destroyed, if the destroyed surface
was the drag focus, we'd try to focus-out from it after it was
destroyed, causing a NULL pointer dereference.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/336
To avoid a known race condition in the wl_output protocol documented in
https://phabricator.freedesktop.org/T7722, mutter delays the `wl_output`
destruction but nullify the `logical_monitor` associated with the
`wl_output` and the binding routine `bind_output()` makes sure not to
send wl_output events if the `logical_monitor` is `NULL` (see commit
1923db97).
The binding routine for `xdg_output` however does not check for such a
condition, hence if the output configuration changes while a client is
binding to xdg-output (typically Xwayland at startup), mutter would
crash while trying to access the `logical_monitor` which was nullified
by the change in configuration.
Just like `bind_output()` does for wl_output, do not send xdg-output
events if there is no `logical_monitor` yet.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/194
When we update the main monitor, there is a rule that makes it so that
popup windows use the same main monitor as their parent. In the commit
f4d07caa38 the call that updates and
fetches the main monitor of the toplevel accidentally changed to update
from itself, causing a indefinite recursion eventually resulting in a
crash.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/279
As with xdg-toplevel, a gtk-surface can be unmanaged by the compositor
without the client knowing about it, meaning the client may still send
updates and make requests. Handle this gracefully by ignoring them. The
client needs to reset all the state anyway, if it wants to remap the
same surface.
https://gitlab.gnome.org/GNOME/mutter/issues/240
As with xdg-toplevel proper, a legacy xdg-toplevel can be unmanaged by
the compositor without the client knowing about it, meaning the client
may still send updates and make requests. Handle this gracefully by
ignoring them. The client needs to reassign the surface the legacy
xdg-toplevel role again, if it wants to remap the same surface, meaning
all state would be reset anyway.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/240
A toplevel window can be unmanaged without the client knowing it (e.g. a
modal dialog being unmapped together with its parent. When this has
happened, take frame callbacks queued on a commit and cache them on the
generic surface queue. If the toplevel is to be remapped because the
surface was reassigned the toplevel role, the cached frame callbacks
will be queued on the surface actor and dispatched accordingly.
https://gitlab.gnome.org/GNOME/mutter/issues/240
A window can be unmanaged without asking the client to do it, for
example as a side effect of a parent window being unmanaged, if the
child window was a attached dialog.
This means that the client might still make requests post updates to it
after that it was unmapped. Handle this gracefully by NULL-checking the
surface's MetaWindow pointer. We're not loosing any state due to this,
as if the client wants to map the same surface again, it needs to either
reassign it the toplevel role, or reset the xdg-toplevel, both resulting
in all state being lost anyway.
https://gitlab.gnome.org/GNOME/mutter/issues/240
A toplevel window can be unmanaged without the client knowing it (e.g. a
modal dialog being unmapped together with its parent. When this has
happened, take frame callbacks queued on a commit and cache them on the
generic surface queue. If the toplevel is to be remapped, either because
the surface was reassigned the toplevel role, or if it was reset and
remapped, the cached frame callbacks will be queued on the surface actor
and dispatched accordingly.
https://gitlab.gnome.org/GNOME/mutter/issues/240
A popup can be reset, and when that happens, window and actor are
destroyed, and won't be created again unless it is reassigned the
popup role.
If a client queued frame callbacks when resetting a popup, the frame
callbacks would be left in the pending state, as they were not queued on
the actor, meaning we'd hit an assert about the frame callbacks not
being handled. Fix this by caching them on the MetaWaylandSurface, so
that they either are cleaned up on destruction, or queued on the actor
would the surface be re-assigned the popup role.
https://gitlab.gnome.org/GNOME/mutter/issues/240
Sometimes it may be useful for roles to put callbacks in the generic
surface frame callback queue. The surface frame callback queue will
either eventually be processed on the next surface role assignment that
places the frame callbacks in a role specific queue, processed at some
other point in time by a role, or cleaned up on surface destruction.
https://gitlab.gnome.org/GNOME/mutter/issues/240
When a xdg-toplevel is reset, the window and actor are recreated, and
all state is cleared. When this happened, we earlied out from the
xdg-toplevel commit handler, which would mean that if the client had
queued frame callbacks when resetting, they'd be left in the pending
commit state, later hitting an assert as they were not handled.
Fix this by queuing the frame callbacks no the new actor, so that they
are emitted whenever the actor is eventually painted.
https://gitlab.gnome.org/GNOME/mutter/issues/240
This was done for input regions in commit 718a89eb2f (Thanks Jonas
for the archaeology!) but opaque regions follow the same scaling.
This brings less evident issues as opaque regions are just used for
culling optimizations.
Commit 6a92c6f83 unintendedly broke input/opaque region calculations
on hidpi. Most visible side effect is that clicking is only allowed
in the upper-left quarter of windows.
The surface coordinates are returned in logical unscaled buffer
size. We're however interested in actor coordinates (thus real
pixels) here.
As it is a bit of a detour how the scale to be applied is calculated,
refactor a meta_wayland_actor_surface_get_geometry_scale() function
that we can use it here, and use it consistently for surface size and
the given regions.
Commit a3da4b8d5b changed updating of
window monitors to always use take affect when it was done from a
non-user operation. This could cause feed back loops when a non-user
driven operation would trigger the changing of a monitor, which itself
would trigger changing of the monitor again due to a window scale
change.
The reason for the change, was that when the window monitor changed due
to a hot plug, if it didn't actually change, eventually the window
monitor pointer would be pointing to freed memory.
Instead of force updating the monitor on all non-user operations, just
do it on hot plugs. This allows for the feedback loop preventing logic
to still do what its supposed to do, without risking dangling pointers
on hot plugs.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/189
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/192
The bool determines whether the call was directly from a user operation
or not. To add more state into the call without having to add more
boolenas, change the boolean to a flag (so far with 'none' and 'user-op'
as possible values). No functional changes were made.
https://gitlab.gnome.org/GNOME/mutter/issues/192
As per specification
> The compositor ignores the parts of the input region that
> fall outside of the surface.
> The compositor ignores the parts of the opaque region that
> fall outside of the surface
This fixes culling problems under certain conditions.
Currently xdg-shell applies a geometry set with set_window_geometry
unconditionally. But the specification requires:
> When applied, the effective window geometry will be
> the set window geometry clamped to the bounding rectangle of the
> combined geometry of the surface of the xdg_surface and the
> associated subsurfaces.
This is especially important to implement viewporter and
transformation.
By using the shm file when sending the keymap to all clients, we
effectively allows any client to change the keymap, as any client has
the ability to change the content of the file. Sending a read-only file
descriptor, or making the file itself read-only before unlinking, can
be worked around by the client by using chmod(2) and open(2) on
/proc/<pid>/<fd>.
Using memfd could potentially solve this issue, but as the usage of
mmap with MAP_SHARED is wide spread among clients, such a change can
not be introduced without causing wide spread compatibility issues.
So, to avoid allowing clients to interfere with each other, create a
separate shm file for each wl_keyboard resource when sending the
keymap. We could eventually do this per client, but in most cases,
there will only be one wl_keyboard resource per client anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=784206
If a client maps a popup in response to a key-down event, but the
mapping doesn't occur until after the user has already released the same
button, we'd immediately dismiss the popup. This is problematic, as one
often presses and releases a key quite quickly, meaning any popup mapped
on key-down are likely to be dismissed.
Avoid this race condition by accepting serials for key down events, if
the most recent key-up event had the same keycode.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/180
This protocol supersedes the internal gtk_text_input protocol that
was in place. Functionally it is very similar, with just some more
verbosity in both ways (text_change_cause, .done event), and some
improvements wrt the pre-edit text styling.
If the surface is gone before `meta_xwayland_keyboard_grab_end()` is
called, we would bail out early leaving an empty grab, which will cause
a segfault as soon as a key is pressed later on.
Make sure we clean up the keyboard grab even if the surface is gone.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/255
The string used to point to memory owned by libwayland-server, but
with the ability to override the display name, we took over ownership
by copying the string as necessary.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/176
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 a client asks for xdg-output before we have set the output's logical
monitor, we would end up crashing with a NULL pointer dereference.
Make sure we clear the resource's user data when marking an output as
inert on monitor change so that we don't end up with a Wayland output
without a logical monitor.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/194
meta_window_wayland_update_main_monitor() would skip the monitor update
if the difference in scale between the old and the new monitor would
cause another monitor change.
While this is suitable when the monitor change results from a user
interactively moving the surface between monitors of different scales,
this can leave dangling pointers to freed monitors when this is
triggered by a change of monitor configuration.
Make sure we update the monitor unconditionally if not from a user
operation.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/189
