While it should not be expected that we pick the pointer into a
MetaSurfaceActor that is disembodied of its MetaWaylandSurface/MetaWindow,
the paths where this should be enforced are somewhat scattered.
So account for the situation in picking code, and prefer a NULL surface
over a crash. This operates on the assumption that this inconsistent state
where Mutter didn't know better to pick a correct surface actor will be fixed
by later crossing events resolving the intermediate state, and that no
other input events will be received meanwhile.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3393
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3729>
When unmapping a subsurface, it does lose early its connection to the
parent surface. This is however a deciding factor in determining whether
the surface (role) has a window.
Make the subsurface actor unreactive if its connection to the parent
MetaWindow was severed, since it should not be eligible for picking anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3729>
These actors are expected to be destroyed along with their surface, this
however happens later in the process, so there is a moment where actors
are eligible for picking, but do not have a surface anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3729>
Prior to the grabs/focus rework in !3420, Wayland grabs were handled
separately from ClutterGrabs. This required explicitly checking for
ClutterGrabs as those were expected to prevent events from reaching
Wayland clients.
Now after !3420, Wayland client grabs also result in ClutterGrabs, which
means that this check causes input events for popups with grabs to not
get sent to ibus anymore. Instead the events are getting sent to the
client directly, which results no ibus support in popups (unless the
client handles that itself by using a different GTK_IM_MODULE).
However due to the changes from !3420 checking for ClutterGrabs is also
no longer necessary and the meta_wayland_text_input_update() focus check
is now sufficient to only forward events to ibus, when the focus is
actually on a Wayland client. So to fix this we can simply remove the
check.
Fixes: 2a584a8f0 ("wayland: Make use of Wayland event grabbing mechanism")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3502
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3787>
Reads exposed size hints for the given cursor plane. Chooses nearest
minimum cursor size out of the hints with respect to the user chosen
cursor size from the UI. Allocates optimized Hardare cursor size,
hence drm buffer
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3165>
Instead use an abstract "logical monitor id" that is generated from the
logical monitor. Instead of using low level numbers from the mode
setting devices, use either data from the EDID, or the connector, if the
EDID is not useful.
This should help with windows remembering monitor positions when the
same monitor reappears but with another mode setting device ID.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3753>
Replace the sync_focus() calls with a set_focus() do-it function taking
a surface. This is in line with the rest of the things that happen at
the default MetaWaylandEventInterface.focus implementation, and will
make these correctly observe the presence of grabs, since
meta_wayland_seat_get_input_focus() will return the would-be focus
in these cases.
This change makes the "focused" client selection truly
in sync with the keyboard focus.
Fixes: 5ca10c31d1 ("wayland: Follow seat's input focus client for clipboard selections")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3490
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3789>
Replace the sync_focus() calls with a set_focus() do-it function taking
a surface. This is in line with the rest of the things that happen at
the default MetaWaylandEventInterface.focus implementation, and will
make these correctly observe the presence of grabs, since
meta_wayland_seat_get_input_focus() will return the would-be focus
in these cases.
This change makes the "focused" client selection truly
in sync with the keyboard focus.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3498
Fixes: 9bdb00c459 ("wayland: Follow seat's input focus client for primary selections")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3789>
We were leaking the color profile path keys but also it wasn't clear how
the ownership was passed to the new hash-table, so let's just remove it
from the pending hash table and add it to the new one including the
expected reference.
This is safe because we were still adding a temporary extra ref to the
profile
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3788>
The cursor was following the "current" surface (i.e. the logical
focus, unaffected by e.g. grabs), so MetaWaylandPointer was always
providing window cursors, just so the MetaCursorRenderer would maybe
discard them and show the compositor cursor instead. E.g. in the
presence of grabs.
This clear barrier between grabs being compositor business deserving
a compositor cursor, and non-grabs being client business turned a bit
blurrier in grabs-pt5 where "client" things like popups and DnD would
also involve grabs. The fixes in that regard in the branch went on
the lenient side, introducing situations where grabs do exist but we
are preferring client-side cursors anyways.
Fix this by making MetaWaylandPointer aware of grabs at the time of
updating the client-side cursor, by following the "focus" surface
(i.e. the effective focus, affected by grabs outside of MetaWaylandInput).
The focus surface and cursor will be updated on focus changes, also
induced by grab changes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3460
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3736>
In some cases, reparenting a window with its frame may fail; this seems
to happen especially during initialization of a window that may be
unmapped and re-mapped quickly and multiple times.
If this happens, we're never going to receive a remove event on the
stack tracker and so we may end up adding it twice to the list of the
windows to synchronize with the compositor, breaking its assumption that
the stack list is unique, and eventually leading to a crash because we
do not end up removing all the instances of a window on its destruction.
In particular we may end up in this situation:
Syncing Window 10485927: 0x555558863540 (actual xid is 10485927),
user time is 10485928 frame is 0x5555588715c0, frame xid 6291591
Syncing Window 14680081: 0x5555588664b0 (actual xid is 14680081),
user time is 14680082 frame is 0x555558871d80, frame xid 6291595
Syncing Window 6291460: 0x55555796dc80 (actual xid is 10485763),
user time is 10485764 frame is 0x555557a6f630, frame xid 6291460
Syncing Window 6291465: 0x555557a68af0 (actual xid is 14680067),
user time is 14680068 frame is 0x555557a73e80, frame xid 6291465
Syncing Window 6291509: 0x555557f9d830 (actual xid is 8388623),
user time is 0 frame is 0x555557fac780, frame xid 6291509
Syncing Window 6291586: 0x5555586e1690 (actual xid is 4194363),
user time is 0 frame is 0x55555886e550, frame xid 6291586
Syncing Window 6291591: 0x555558863540 (actual xid is 10485927),
user time is 10485928 frame is 0x5555588715c0, frame xid 6291591
Where the same meta window 0x555558863540 is added twice because that's
both mapped by the window itself (10485927) and by its frame (6291591).
This happens because for historical reasons the xids hash table managed
by the x11-display maps both the X11 windows, their frames and their
user time windows as the meta-window, and so if we don't filter out them
properly we end up duplicating the entries in the compositor list.
Such duplicates finally end up making mutter to crash in
meta_compositor_sync_stack() because we could end up trying to access
to an invalid window, given its actor has been destroyed but not all the
instances have been removed from the compositor windows list:
0x00007ffff71059 in meta_compositor_sync_stack (compositor=0x555555b8,
stack=0x555558701b80) at ../../mutter/src/compositor/compositor.c:773
773 if ((old_window->hidden || old_window->unmanaging) &&
(gdb) print old_window
$1 = (MetaWindow *) 0x0
So, in order to prevent this, check that XReparentWindow does not fail,
and in case of failure, reset the window state to the one it had before
we failed and more importantly, remove the association between the frame
X11 window and the MetaWindow, since this is not true anymore and so
that at the next stack synchronization there won't be any meta window
associated to that frame XID (unless there aren't further stack changes
impacting on that). Without this we would have instead waited for the
remove event that we predicted, but that could never happen because no
ReparentNotify is emitted in such case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3732>
Since we listen the X events in the same thread, and they are delivered
through the main loop, there's not any need to set the frame details on
windows before the reparent operation, because such action could fail.
So move the code order, as preparation for handling the error.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3732>
That was only there to force updating MetaFrame's bounds
but that is something that is already updated in
MetaWindowX11.move_resize_internal. So just drop all of that
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3254>
Since the `switch` didn’t have a default case, the `cull_front` and
`cull_back` variables could technically be used uninitialised if the
`cull_mode` was unrecognised.
That seems unlikely to happen as presumably other code makes sure the
`cull_mode` is valid, but it doesn’t hurt to add a `default:` case to
squash the compiler warning.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3770>
Depending on whether the input mapper was found, these variables could
indeed be used uninitialised, so this is a true positive warning.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3770>
For a Wayland only build, we would like to avoid linking against
libXcursor which on it turn, links back to some of the X11 deps.
In order to achieve that, we include a small subset of xcursor.
In case Mutter is built with X11 or with both Wayland & X11, we link
against libXcursor and don't make use of the in-tree implementation.
This patch mimics what GTK 4 do by shipping an in-tree copy of xcursor.
Especially that libwayland-cursor does not provide an alternative to
xcursor itself.
Helps #2272
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3607>
When meta_wayland_pointer_constraint_remove() is called, it can trigger
a meta_wayland_event_handler_invalidate_focus() via:
meta_wayland_pointer_constraint_destroy()
meta_wayland_pointer_constraint_disable()
meta_wayland_input_detach_event_handler()
meta_wayland_input_invalidate_all_focus()
meta_wayland_event_handler_invalidate_focus()
Which then would result in a "focus-surface-changed" signal which would
call meta_wayland_pointer_constraint_remove() a second time. This
happens after surface_remove_pointer_constraints() has already been
called in the first meta_wayland_pointer_constraint_remove() call,
leading to "data" being NULL.
To prevent this issue disconnect the signal handler before calling
meta_wayland_pointer_constraint_disable() when destroying a constraint.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3476
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3749>
In case of empty regions (e.g. when locking the pointer) the pointer
was only forced to stay within the boundaries of its current pixel
(i.e. culling subpixel position), instead of the position where the
pointer lock did start.
Fixes: 07d24fe50 ("backends/native: Allow infinitely small pointer constraint regions")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3749>
Since 07d24fe50 regions are not translated to their on-screen
coordinates anymore, but are relative to the origin stored in the
constraint. This origin however was not considered when checking whether
the pointer was within the constraint region. This meant that the
constraint region would appear to always be placed at 0,0 instead of on
the surface.
Fix this by using the cursor position relative to the origin.
Fixes: 07d24fe50 ("backends/native: Allow infinitely small pointer constraint regions")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3409
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3749>
We close wayland popups when a button or touch release happens outside
of the grab, except we don't want to close them when that button release is
actually the release of the press that was opening the grab in the first
place.
We never see the press event that opened the grab, so the first event we
see is actually always a release. Make sure to not close the popup on that
event, and instead only close the popup if we see the press count drop from
1 to 0.
This fixes a bug where popup would close right after they open. To
reproduce, click to open a popup, hold pressed and move the cursor over
shell chrome, then release. Or alternatively test with a popup that gets
opened with a long-press gesture (eg. long touch long press on libadwaita
tabs), just doing the touch long-press and then release.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3631>
Until this surface or its parent is finalized.
This makes sure that any `MetaWaylandSubsurfacePlacementOp` referencing
this surface for sibling will be applied as intended.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3737>
This reverts commit 35d92e0fac.
This turned out to cause trouble, because it can prevent
MetaWaylandSurface::applied_state.subsurface_branch_node from ever
getting linked up for a sub-surface.
It shouldn't be necessary anyway, since permanently_unmap_subsurface /
wl_subcompositor_get_subsurface reset the sub-surface state as defined
by the protocol.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3737>
GSettings overrides can be active and set the default value depending on
the XDG_CURRENT_DESKTOP environement variable. For the tests we run, we
rely on the default settings by using the GSettings memory backend but
we also need to make sure not overrides are in place.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3730>
because we want to switch between two workspaces. In some configurations
there is only a single workspace at this point so trying to get current
workspace + 1 gets us a NULL pointer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3730>
The internal representation of the min/max width of windows include what
is outside of the window geometry, so when the window geometry changes,
but the min/max size did not in the same commit, we'd be left with an
out of date min/max size, potentially causing windows to shrink when
configured.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3755>
local_error in meta_egl_query_device_string() is using g_autoptr,
meaning that it was getting freed after g_propagate_error(). This then
would result in error->message becoming invalid, causing crashes when
logging the error message later on.
Fixes: 8234f5bc7 ("egl: Return success status from meta_egl_query_device_string")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3758>
Just shovel the data through our own stdin/stdout, which will end up at
the right place (e.g. /dev/null).
This should hopefully solve `mutter-dist` failing due to a D-Bus method
call timeout in CI.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3757>
An action can be performed both on a signal emitted by a window or by
a well-known signal name, so that one can do:
[window-id]::signal => command
And so these would work:
w/1::position-changed => resize w/2 20 30
::monitors-changed => move w/1 30 40
We only support "monitors-changed" global signal name or connecting to
window signals for now, but this can be easily expanded adding support
for more global signal values or parsing other kinds of object instances
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3701>
Allows to use:
set_strut 0 0 MONITOR_WIDTH*0.5 MONITOR_HEIGHT/4 top [default]
We use the currently focused window as the reference monitor if any or
the primary one if no monitor is explicitly provided.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3701>
We may need to compare monitor size to fractions and while it can be
done using inverse divisions, they were not supported as we didn't parse
floating point values.
So, just add support for both multiplications and divisions, so that we
can easily do stuff like `MONITOR_HEIGHT*3/4`.
Additions would be easy to support too if we don't care about operator
priorities, but that's out of scope for now.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3701>
We just made an half assed attempt to wait, but e.g. when clients were
waiting for a frame event, the attempt was not enough, as the clients
would not ack any configure until the time they were scheduled to paint
again.
Fix this by actually tracking newly pending configurations, and waiting
for them to return.
On X11, still be lazy and hope for the best, as there is no similar
configuration tracking there.
Some tests were updated to use just 'wait' when there was no actual need
for any extra waiting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3701>
When a window with an input shape on its decoration window becomes
undecorated and meta_window_x11_update_input_region() gets called via
notify::decorated, the buffer_rect of the window has not been updated
yet while the decorated property has. This would lead to us comparing
the input shape of the client window to the buffer_rect which still
includes the decoration window. This would fail to detect the common
case when the client window has no input shape set, leading to the input
region being set to the size of the client window rather than NULL. If
the window is then resized later, the input shape would remain at the
previous size.
This was not a problem before 6bd920b35, because then we were (wrongly)
always comparing to the client_rect.
Fix this by choosing the correct rect for comparison depending on
whether the window is decorated.
Fixes: 6bd920b35 ("x11/window: Use correct bounding rect to determine NULL input region")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3451
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3720>
There is nothing to allocate for a 0-sized files, and indeed
posix_fallocate() will error out if the passed len isn't greater
than 0.
Now that anonymous files are used to back the memory selection
source, this fixes unsetting the selection when the screen is
locked.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3752>
When a key binding is removed, and a trigger key sequence is dispatched
before the idle callback that resolves and updates the actual binding,
we should handle that gracefully.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3711>
Two new fields: ref_count and removed, are added to MetaKeyHandler, and
it would be freed only if the ref count has reached 0. When handler is
removed from key_handlers GHashTable, key_handler_destroy() would mark
removed as TRUE, and do an unref. handler->removed is checked in
get_keybinding, and binding with handler removed would not be used.
Also in MetaKeyBinding, it now has the ownership of the name field, to
avoid it being freed before logging. Create or copy a binding would
do a ref inc for handler, and free one would unref handler.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1870.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3711>
When a client resizes on its own, make sure the new size is passed
through the window constraints machinery directly, to trigger any
potential window management rule that might apply.
Fix a couple of tests to make use of this behavior by introducing a new
'wait_size' command that waits until a window has been resized to a
expected size.
This replaces the fix introduced in 0e736af301 ("window: Ensure
constraints after a Wayland client resize").
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3700>
Starting the timeout to move from hidden to suspended before the window
is mapped means we don't have a previous window configufration which we
need to get the new window configuration with the suspended state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3731>
These functions are specific for X11 windows only so we should check
if the passed window is an X11 one, not just a MetaWindow since we're
casting to the actual type at later point.
Fixes changes part of commit e1e6534eb
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3727>
If a window sends a configure stacking request, we were comparing the
active window with the event window even though they were different
client types (e.g. wayland and x11).
This was leading to a critical error, so let's handle this by ensuring
that the active window is of the same kind of the event window before
doing x11-specific checks. Behaving as different applications in case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3727>
Because `meta_kms_impl_device_simple_initable_init` is called in the
middle of `meta_kms_device_new`, the crtcs list for `MetaKmsDevice`
has not been populated yet. And thus the loop to detect missing
cursor planes and create fake ones never iterated. But the crtcs list
does already exist in `MetaKmsImplDevice` so iterate over that instead.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3264
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3676>
Prior to commit 5dfed8a431, the MetaWaylandKeyboard would always remember
the last key press serial, and consider it valid after the key was released,
as long as no other key presses/releases happened in between.
That commit improved things so that MetaWaylandKeyboard can track multiple
keys being pressed simultaneously, but also changed so that the serial for
a key press is immediately forgotten after the key press event was received.
This may break in situations like testing or keyboard macros where key
press and release is handled in a quick sucession, so the client reaction
to the key press (e.g. popping up a menu) might arrive too late.
Add a sort of spiritual successor to this handling, and make keyboard
press serials corresponding to the last key up forgotten at the next
key press/release received.
Fixes: 5dfed8a431 ("wayland: Preserve serial for all pressed keys")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3458
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3721>
We did not track the current surface (i.e. the logical focus) too
thoroughly, so there might be chances that a stale surface pointer
here becomes the focus. Track its destruction (like it's done at e.g.
MetaWaylandPointer) and unset the current surface early, in order
to avoid possible invalid memory access.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3372
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3715>
It seems only the iconcache used to use it, but this is gone since
commit d16ddc42ce.
Even before that, the Xrender usage was removed in commit 556e7694de,
albeit leaving a redundant include <X11/extensions/Xrender.h> in its
place then, which comes from libXrender.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3716>
Fix an obvious copy paste error that slipped through the cracks.
Fortunately it doesn't have a visual impact for well behaving clients
but only makes us not hit direct-scanout paths, assuming no other bugs
in the stack.
Fixes: f21762ea6e (wayland: Add support for preferred_buffer_scale/transform)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3717>
This call is meant to replace meta_wayland_keyboard_get_focus_client(),
since we will always have a MetaWaylandSeat with an input focus (or not),
but we may or may not have a MetaWaylandKeyboard.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3707>
When there is a new owner but there is no matching mime type we clear
the saved mimetype and the saved clipboard but an outstanding async
meta_selection_transfer_async can set the saved clipboard.
Abort the async transfer when we have a new owner.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3678>
The precondition checks in meta_selection_source_memory_new can return
NULL if the mimetype is NULL but callers expect the error to be set when
NULL is returned.
Let's just make sure we never call it with a NULL mimetype.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3678>
The current code checking keyboard serials for popup/grab
validation is a bit simple, tracking one key press exclusively.
This may break expectations if a client uses a serial
corresponding to a previous key that is still pressed.
Keep track of the serials corresponding to all pressed keys,
and ensure these are reset across focus changes, since the
validity of those serials is already outdated. The code does
still keep track of a single (last) key release serial, since
the validity lifetime is somewhat underdefined with those if
we keep track of multiple keys simultaneously.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3267
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3644>
Instead of initializing to 'suspended', which will send the `SUSPENDED`
xdg_toplevel state, set it to hidden at first. If the window is placed
on an inactive workspace, it'll eventually enter the 'suspended' state,
but will have had some time in non-suspended state to get map, even if
not visibly.
This fixes inital suspended state when mapping a window maximized.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3229
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3475>
This, in contrast to meta_window_should_be_showing() reports whether a
window should be showing despite not being showable. This is useful to
know the intended visibility state that should happen in the immediate
future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3475>
d991961ae changed this code from client rect to buffer rect to account
for the fact that for SSD windows the decorations are now included in
the bounding region, but it kept the variable name as client_area and
the comment was also still referring to the client rect.
Fixes: d991961ae ("x11: Use input region from frame window for decorated windows")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3697>
When updating the input region we check whether the input shape reported
by XShape matches the bounding region of a window to determine when it
was not set by the client. We would then use a NULL input region instead
which always matches the full size of the window. The code however was
using the client rect for this comparison, which does not include the
window frame. Since d991961a the frame is considered part of the input
region.
This meant that for SSD windows where the input region would match the
bounding region, we would not detect that and fail to set the input
region to NULL, but instead set it to the reported input shape.
Usually this would not be the case due to the GTK frame window having
shadows and a resize region, but in the presence of an issue that causes
GTK to wrongly detect _GTK_FRAME_EXTENTS as not supported, GTK would not
draw shadows or set an input shape. And due to GTK not updating its
input shape, there would be no further calls to
meta_window_x11_update_input_region() after the initial one.
The input region would therefore remain at the fixed size from the
initial call. This was causing windows to become click-through outside
of the region corresponding to their initial size after being resized.
Fixes: d991961ae ("x11: Use input region from frame window for decorated windows")
Related: https://gitlab.gnome.org/GNOME/gtk/-/issues/6558
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3404
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3697>
Right now we store touch serials on their according MetaWaylandTouchInfo
entries. These entries are gone as soon as the touchpoint ended though, and
it's not unlikely that clients will respond to that touch-end event after we
removed the touchpoint.
In this case we currently can't match the client provided serial to any of
our known touch sequences, which causes xdg_popup grabs that get requested
shortly after the touch-end to fail.
Let's be a bit more gentle on clients here and store the latest touch-down
serial on the MetaWaylandTouch, so that it continues to be around after the
touch-end and we can match the serial of the xdg_popup_grab() as expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2946>
In the rare event that hotplugs destroy and then create a new EGLContext
with the exactly the same ID, this ensures we will forget the old program
which presumably wouldn't work in the new context. It will be recreated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>
The EGL context can only import and blit an EGLImage if the
backing DMA buffer has a format modifier combination that is advertised
as supported and not marked as "external_only".
When the context can't blit the imported image, we can still paint using
it GL_OES_EGL_image_external using the texture target
GL_TEXTURE_EXTERNAL_OES.
However, treat drivers who doesn't support modifiers at all as if they
do support blitting, if the modifier is 'linear', to avoid regressions.
[jadahl: Make shader path a fallback to allow hardware to utilize copy
engines via blitting]
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6221
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2247
Related: https://launchpad.net/bugs/1970291
now only falls back if modifiers are supported, and they mark linear as
export only.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>
This is a critical part of any OpenGL program. Mesa allowed us to get
away without it and provided a sane default of the full buffer, but
Nvidia seems to default to an empty/zero viewport so would refuse to
paint any pixels.
In the OpenGL ES 2.0 spec this is ambiguous:
> In the initial state, w and h are set to the width and height,
> respectively, of the window into which the GL is to do its rendering.
because the first "window" used is EGL_NO_SURFACE in
init_secondary_gpu_data_gpu. It has no width or height.
In the OpenGL ES 3.0 spec the ambiguity is somewhat resolved:
> If the default framebuffer is bound but no default framebuffer is
> associated with the GL context (see chapter 4), then w and h are
> initially set to zero.
but not entirely resolved because neither spec says whether
EGL_NO_SURFACE should be treated as zero dimensions (Nvidia) or ignored
and not counted as the first "window" (Mesa).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>
As mentioned in the OES_EGL_image_external spec, there is no implicit
sync between the EGLImage producer and consumer. And in this code path
we don't have meta_drm_buffer_gbm_new_lock_front on the primary GPU to
do it for us either. So synchronization has to be done manually or else
the secondary GPU is likely to get an unfinished image.
This problem has only been observed when the secondary GPU is using the
Nvidia proprietary driver.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>
When the monitors change meta_window_update_for_monitors_changed is
called which is responsible for updating window->monitor. It however can
go through the entire window placement and constraint machinery before
it's able to do so. In this period window->monitor points to the old
MetaMonitor where the monitor number doesn't reflect the index into the
MonitorManager anymore.
Avoid relying on the window->monitor->number and go through the Monitor
directly.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3402
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3691>
In every other device and circumstance, we update the logical focus
(i.e. the surface that would be focused, if no other circumstances
applied) but let the MetaWaylandInput figure out the surface that
should be effectively focused, if at all. This is where we apply the
actual compositor state (e.g. grabs) and result in an effective focus
window.
The only exception to this is `meta_wayland_seat_set_input_focus()`
where the logical focus for keyboards and related devices is set, but
also applied as the effective surface.
We should do the same as everywhere else, and let MetaWaylandInput
focus determine whether the logical focus is also the effective focus.
These replaced set_focus() internal calls will happen through the
default MetaWaylandEventInterface.focus implementation in MetaWaylandSeat.
This resulted in keyboard focus being set on windows in circumstances
it ought not to, like in the overview. Actual key events were never
sent in these circumstances, but changes to modifier state could.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7528
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3704>
If a modal dialog (i.e. with a "revolves around center of parent window" policy)
becomes fullscreen, we cannot neatly honor both the modal dialog going fullscreen
and the window staying around the center of its parent.
In order to make fullscreening work in this situation, allow fullscreen modal
dialogs to "snap out" of the parent. This rule will become again effective after
the window is unfullscreened.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3425
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3695>
