This allows to verify which window should have the focus, which might not
be the same as the top of the stack.
It's possible to assert the case where there's no focused window using
"NONE" as parameter.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/307
(cherry picked from commit 51f9e04ef1)
Allow to set/unset WM_TAKE_FOCUS from client window.
This is added by default by gtk, but this might not happen in other toolkits,
so add an ability to (un)set this.
So fetch the protocols with XGetWMProtocols and unset the atom.
test-client now needs to depend on Xlib directly in meson build.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/307
(cherry picked from commit f2d2d473b7)
When destroying a window that has a parent, we initially try to focus one of
its ancestors. However if no ancestor can be focused, then we should instead
focus the default focus window instead of trying to request focus for a window
that can't get focus anyways.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/308
(cherry picked from commit eccc791f3b)
Currently the EGLDevice code gets the display and calls eglInitialize.
As a follow-up it checks the required EGL extensions - technically it
could check the EGL device extensions earlier.
In either case, eglTerminate is missing. Thus the connection to the
display was still bound.
This was highlighted with Mesa commit d6edccee8da ("egl: add
EGL_platform_device support") + amdgpu.
In that case, since the eglTerminate is missing, we end up reusing the
underlying amdgpu_device due to some caching in libdrm_amdgpu. The
latter in itself being a good solution since it allows buffer sharing
across primary and render node of the same device.
Note: we should really get this in branches all the way back to 3.30.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/619
Fixes: 934184e23 ("MetaRendererNative: Add EGLDevice based rendering support")
Cc: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit 9213574870)
When free'ing a pipeline we destroy the BigState first and then the fragment and
vertex snippets lists using the big state pointer which is now invalid.
This causes a crash when G_SLICE=always-malloc is set and using MALLOC_CHECK_.
So, invert the operations by free'ing the snippet lists first, and the big state
afterwards.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/581
(cherry picked from commit 7e0d185120)
Keycode lookup can fail for serveral reasons, e.g. if there is no combination of
modifiers and keycodes that can produce the target keysym with the current
keyboard layout.
In case the keycode lookup fails, remap temporarily the keysym to an unused
keycodes.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/109
(cherry-picked from commit e3e933c47a)
When the compositor is destroyed we should cleanup the list of window actors we
created and destroy them.
Since all the actors are added to the window_group or top_window_group we can
just destroy these containers (together with the feedback_group), and simply
free the windows list.
This is particularly needed under X11 because before we destroy the display, we
might do some cleanups as detaching the surface pixmaps and freeing the damages
and if this happens at later point (for example when triggered by garbage
collector in gnome-shell), we might crash because the x11 dpy reference is
already gone.
Destroying the window actors instead, ensures we avoid any further call to X11
related functions and that we release the actors XServer resources.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/576
(cherry picked from commit 7718e67f5c)
Since e3e933c4 a keyval can be temporarily remapped to an unused keycode. Due to
some limitations in XTestFakeKeyEvent, the remapping has to be done in the first
xkb group/layout. In case there are two or more keyboard layouts enabled and the
selected keyboard layout is not the first, clutter_keymap_x11_keycode_for_keyval
will fail to retrieve the correct keycode for a remapped keyval. Let's use the
reserved_keycodes map in order to retrieve the correct keycode if needed.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/443
(cherry picked from commit e0811ce141)
Enabling keyboard accessibility features on Wayland from the keyboard
was wrongly assumed to be controlled by the "togglekeys" setting,
whereas it should be simply controlled by the "enable" setting.
As "togglekeys" is off by default and doesn't have a UI option to
enable, that would prevent turning on or off the keyboard accessibility
features using the keyboard.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/501
Switch-configs are only to be used in certain circumstances (see
meta_monitor_manager_can_switch_config()) so when ensuring
configuration and attempting to create a linear configuration, use the
linear configuration constructor function directly without going via the
switch config method, otherwise we might incorrectly fall back to the
fallback configuration (only enable primary monitor).
This is a regression introduced by 6267732bec.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/342
(cherry picked from commit 149e4d6934)
It scaled the logical monitor rect with scale to get the stream
dimensions, but that is only valid when having
'scale-monitor-framebuffers' enabled. Even when it was, it didn't work
properly, as clutter_stage_capture_into() doesn't work properly with
scaled monitor framebuffers yet.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/415
(cherry picked from commit 3fa6a92cc5)
The actor-shader-effect test actors are 50px wide, but we check the 51st
pixel. This went along undetected until "clutter: Avoid rounding
compensation when invalidating 2D actors" because the paint volumes were
made slightly bigger and the shaders paint all over them (I guess nobody
noticed those actors being actually ~52px wide).
Update the test to check the middle of the opposite edge, so we keep neatly
rounded numbers.
(cherry picked from commit 1d73533f78)
This allows the redraw clip to be more constrained, so MetaCullable doesn't
end up rendering portions of window shadows, frame and background when a
window invalidates (part of) its contents.
https://bugzilla.gnome.org/show_bug.cgi?id=782344
(cherry picked from commit a7df459416)
If texture allocation fails (e.g. on an old GPU with size limit 2048)
then `update_fbo` would return `FALSE` but leaves `priv->offscreen`
as non-NULL. So the next paint will try to use the offscreen with a
`NULL` texture and crashes. The solution is simply to ensure that
`priv->offscreen` is NULL if there is no `priv->texture`, so the default
(non-offscreen) paint path gets used instead.
Bug reported and fix provided by Gert van de Kraats.
https://launchpad.net/bugs/1795774
(cherry picked from commit f31cf0c3ef)
(cherry picked from commit 1b78ca8c5e)
If texture allocation fails (e.g. on an old GPU with size limit 2048)
then `cogl_texture_new_with_size` was trying to use the same CoglError
twice. The second time was after it had already been freed.
Bug reported and fix provided by Gert van de Kraats.
https://launchpad.net/bugs/1790525
(cherry picked from commit d21478b0f0)
Commit 8d3e05305 ("window: Force update monitor on hot plugs") added the
flag `META_WINDOW_UPDATE_MONITOR_FLAGS_FORCE` passed to
`update_monitor()` from `update_for_monitors_changed()`.
However, `update_for_monitors_changed()` may choose to call another code
path to `move_between_rects()` and `meta_window_move_resize_internal()`
eventually.
As `meta_window_move_resize_internal()` does not use the "force" flag,
we may still end up in case where the window->monitor is left unchanged.
To avoid that problem, add a new `MetaMoveResizeFlags` that
`update_for_monitors_changed()` can use to force the monitor update from
`meta_window_move_resize_internal()`.
Fixes: 8d3e05305 ("window: Force update monitor on hot plugs")
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/189
(cherry picked from commit fa495286a1)
Closing a GdkDisplay during an event handler is not currently supported by Gdk
and it will result in a crash when doing e.g. 'mutter --replace'. Using an idle
function will close it safely in a subsequent main loop iteration.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/595
IBus naturally doesn't know how to implement the text-input protocol,
and some input methods emit event streams that are incompatible with the
protocol, if not assumed to be part of an grouped series of events. As
IBus doesn't have any API to let us know about such groupings, let's
fake it by adding a specially crafted idle callback.
The idle callback has a known limitation; if there is an idle callback
with a higher priority, that either doesn't remove itself, or
reschedules itself before the next idle, we'll never get triggered.
This, however, is unlikely to actually be the bigger problem in such
situations, as it'd likely mean we'd have a 100% CPU bug.
https://gitlab.gnome.org/GNOME/gtk/issues/1365
Commit 840378ae68 changed the code to use XmbTextPropertyToTextList()
instead of gdk_text_property_to_utf8_list_for_display(), but didn't
take into account that the replacement returns text in the current
locale's encoding, while any callers (rightfully) expect UTF8.
Fix this by converting the text if necessary.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/227
The WM_NAME property is of type TEXT_PROPERTY, which is supposed to be
returned as UTF-8. Commit 840378ae68 broke that assumption, resulting
in crashes with non-UTF8 locales; however the "fix" of converting from
LATIN1 to UTF8 is wrong as well, as the conversion will spit out garbage
when the input encoding isn't actually LATIN1.
Now that the original issue in text_property_to_utf8() has been fixed,
we can simply revert the relevant bits of commit d62491f46e.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/227
This allows input methods to inject key events with specific keyval/keycode,
those events will be flagged with CLUTTER_EVENT_FLAG_INPUT_METHOD so they
won't be processed by the IM again.
https://gitlab.gnome.org/GNOME/gnome-shell/issues/531
If the user maps eg. Alt+F2 to a pad button, the MetaInputSettings will
send the full Alt press, F2 press, F2 release, Alt release sequence.
However the keycode corresponding to Alt is found in level 1, so the
Shift modifier gets unintendedly latched in addition to the Alt key
press/release pair.
We could probably improve keycode lookup heuristics so level=0 (and
no modifier latching) is preferred, but we can do without it altogether
for modifier keys.
In order to allow a window with a custom rule placement to be moved
together with its parent, the final rule used derived from the
constraining were used for subsequent constraints. This was not enough
as some constraining cannot be translated into a rule, such as sliding
across some axis.
Instead, make it a bit simpler and just remember the position relative
to the parent window, and use that the next time.
This is a rework of 5376c31a33 which
caused the unwanted side effects.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/332
When constructing MetaMonitorsConfig objects, store which type
of switch_config they are for (or UNKNOWN if it is not such
type of config).
Stop unconditionally setting current_switch_config to UNKNOWN when
handling monitors changed events. Instead, set it to the switch_config
type stored in the MonitorsConfig in the codepath that updates logical
state. In addition to being called in the hotplug case along the same
code flow that generates monitors changed events, this is also called
in the coldplug case where a secondary monitor was connected before
mutter was started.
When creating the default linear display config, create it as a
switch_config so that internal state gets updated to represent
linear mode when this config is used.
The previous behaviour of unconditionally resetting current_switch_config
to UNKNOWN was breaking the internal state machine for display config
switching, causing misbehaviour in gnome-shell's switchMonitor UI when
using display switch hotkeys. The lack of internal tracking when the
displays are already in the default "Join Displays" linear mode was
then causing the first display switch hotkey press to do nothing
(it would attempt to select "Join Displays" mode, but that was already
active).
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/281https://gitlab.gnome.org/GNOME/mutter/merge_requests/213
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
With Wayland, a window is not showing until it's shown. Until this
patch, the initial state of MetaWindow, on the other hand, was that a
window is initialized as showing. This means that for a window to
actually be classified as shown (MetaWindow::hidden set to FALSE),
something would first have to hide it.
Normally, this wasn't an issue, as normally we'd first create a window,
determine it shouldn't be visible (due to missing buffer), hide it
before the next paint, then eventually show it. This doesn't work if
mutter isn't drawing any frames at the moment (e.g. the user switched
VT), as we'd miss the hiding before showing as e result of a buffer
being attached. The most visible side effect is that a window can't be
moved as the window actor remains frozen.
This commit fixes this issue by correctly classifying a newly created
Wayland window as "hidden".
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/331
The clip and opaque region are both in a translated stage coordinate
space, where the origin is in the top left corner of the painted
texture. The painting, however, is in the texture coordinate space,
so when the texture is scaled, the coordinate spaces differ.
Handle this by transforming the clip and opaque region to texture
coordinate space before computing the blend region and the opaque region
to paint.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/300
They were int before entering MetaShapedTexture, used as ints in the
cairo regions and rectangles, so there is no reason they should be
stored as unsigned.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/300
meta_renderer_native_gles3_read_pixels() was assuming that the target
buffer stride == width * 4. This is not generally true. When a DRM
driver allocates a dumb buffer, it is free to choose a stride so that
the buffer can actually work on the hardware.
Record the driver chosen stride in MetaDumbBuffer, and use it in the CPU
copy path. This should fix any possible stride issues in
meta_renderer_native_gles3_read_pixels().
