We'd break the loop for moving attached windows at the first window,
meaning we'd only ever move a single attached dialogs or popup if it was
the first window in the list. This doesn't work out well when there are
multiple popups open, so don't break out of the loop at all until all
windows are potentially moved.
This fixes an issue in gtk4 where one or more non-grabbing popups would
end up unattached if there were more than one and the parent window was
moved.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/592
XkbNewKeyboardNotify informs the client that there is a new keyboard
driving the VCK. It is essentially meant to notify that the keyboard
possibly has a different range of HW keycodes and/or a different
geometry.
But the translation of those keycodes remain the same, and we don't
do range checks or geometry checks (beyond using KEY_GRAVE as "key
under Esc", but that is hardly one). It seems we can avoid the
busywork that is releasing all our passive grabs, reloading the keymap
and regenerating the keycombos and restoring the passive grabs.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/398
There is no reason why we should have an internal type enum when we have
all the infrastructure to just use multiple GObject types. Also there
was no code sharing between the old "types", the only common API was
getting the framebuffer ID, so lets make that a vfunc.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/584
In order to scale a rectangle by a double value, we can reuse a ClutterRect
to do the scale computations in floating point math and then to convert it back
using the proper strategy that will take in account the subpixel compensation.
In this way we can be sure that the resulting rectangle can fully contain the
original scaled one.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/469
This function was added for historic reasons, before that we had GSlist's
free_full function.
Since this can be now easily implemented with a function call and an explicit
GDestroyFunc, while no known dependency uses it let's move to use
g_slist_free_func instead.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/57
GList's used in legacy code were free'd using a g_slist_foreach + g_slist_free,
while we can just use g_slist_free_full as per GLib 2.28.
So replace code where we were using this legacy codepath.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/576
GList's used in legacy code were free'd using a g_list_foreach + g_list_free,
while we can just use g_list_free_full as per GLib 2.28.
So replace code where we were using this legacy codepath.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/576
This shouldn't happen frequently, but is just a sign that the source is
being replaced by something else. Just keep the warning for other possible
error situations.
Also, plug the potential GError leak.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/598
All child classes of `MetaWaylandShellSurface` as well as
`MetaWaylandSurfaceRoleXWayland` should only sync their actor if
their toplevel surface has a window. Currently this check is done
in the actor-surface class, but not all surface classes have a
toplevel window, e.g. dnd-surfaces.
Move the check to the right places.
For subsurfaces this assumes that the subsurface is not the child of
a window-less surface (like, as stated above, e.g. a dnd-surface).
If we want to support subsurfaces of window-less surfaces in the future
we have to extend the check here.
But as this is not a regression, ignore this case for now.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/537
Depending on the type of session, one or the other might be NULL, which
is not meant to be handled by these functions. Check for both DISPLAY
envvars before setting them on the GAppLaunchContext.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/586
This is 1) relatively likely as not all touchscreens are nice enough to
report a device size that will help us here and 2) Better than nothing if
everything fails anyway, as it will break on multi-monitor and non-default
monitor rotations.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/581
The check for the focus xwindow is called, but not used. Fix that by
renaming the variable to reflect better what it does and actually using
the return value of the check.
This was the original intention of the author in commit
05899596d1 and got broken in commit
8e7e1eeef5.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/535
If we update the ready time while the source is already in the
to-dispatch list, changing the ready time doesn't have any effect, and
the source will still be dispatched. This could cause incorrect idle
watch firing causing the power management plugin in
gnome-settings-daemon to sometimes turn off monitors due to it believing
the user had been idle for some time, while in fact, they just logged
back in.
Fix this by not actually dispatching the idle timeout if the ready time
is in the future when actually dispatching.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/543
meta_workspace_activate_with_focus is supposed to focus the passed window after
switching the workspace.
However if the passed workspace is already the active one, we just return
without activating the window.
So fix this calling meta_window_activate on the foucs_this window if that is
valid.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/562
Don't launch the stacking tests in one single shot, to allow better debugging
and being able to launch just one single test using meson test.
Those tests can now be all launched with:
meson test --suite stacking [single-test-name]
https://gitlab.gnome.org/GNOME/mutter/merge_requests/442
This is a simple clipboard manager implementation on top of MetaSelection.
It will inspect the clipboard content for UTF-8 text and image data whenever
any other selection source claims ownership, and claim it for itself
whenever the clipboard goes unowned.
The stored text has a maximum size of 4MB and images 200MB, to prevent the
compositor from allocating indefinite amounts of memory.
This is not quite a X11 clipboard manager, but also works there.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/320
This code takes care of both setting up X11 selection sources whenever
X11 clients claim selection ownership, and claiming selection ownership
on a mutter X11 window whenever other selection sources claim ownership.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/320
This object represents a Wayland selection owner. In order to invert the
FD direction (we hand an output fd, but want an inpu fd), create an
intermediate pipe so we can then create a GInputStream on top of it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/320
This object represents the selection ownership from an X11 client. The
list of supported targets is queried upfront, so its initialization is
asynchronous. Requests to read contents from the selection will hand
a MetaX11SelectionInputStream.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/320
MetaSelectionSource represents a primary/clipboard/dnd selection owner,
it is an abstract type so wayland/x11/etc implementations can be provided.
These 3 selections are managed by the MetaSelection object, the current
selection owners will be set there, and signals will be emitted so the
previous selection owner can clean itself up.
The actual data transfer is done through the meta_selection_transfer_async()
call, which will take a GOutputStream and create a corresponding
GInputStream from the MetaSelectionSource in order to splice them.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/320
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
When an application stops responding, the shell darkens its windows.
If a window from a not-responding application gets unmanaged
then the shell will currently throw an exception trying to retrieve
the now-dissociated window actor.
That leads to a "stuck window" ghost on screen and a traceback
in the log.
This commit addresses the problem by making sure the effect is cleaned
up before the actor is disocciated from its window.
https://gitlab.gnome.org/GNOME/mutter/issues/575
Make sure our keyboard accessibility settings structure is all zero
initialized, to avoid potential padding issues on some platform when
comparing settings.
Reported by Daniel van Vugt on IRC.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/552
This reverts a change introduced in edfe5cc3 to use `paint_clipped_rectangle()`
instead of `cogl_framebuffer_draw_rectangle()` for full paints as it
contained logic necessary for viewport src-rects. This is not longer the case.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/504
This brings the viewport src-rect code in line with how we handle
transforms, by applying a `CoglMatrix` to the pipeline instead of
changing the paint logic.
It also fixes not-y-inverted textures in combination with
transforms.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/504
When focus stealing prevention kicks in, mutter would set the demand
attention flag on the window.
Focus stealing prevention would also prevent the window from being
raised and focused, which is expected as its precisely its purpose.
Yet, when that occurs, the user expects the window which has just been
prevented from being focused to be the next one in the MRU list, so
that pressing [Alt]-[Tab] would raise and give focus to that window.
This works fine when the window is placed on the primary monitor, but
not when placed on another monitor, in which case the window which has
been denied focus is placed ahead of the MRU list and pressing
[Alt]-[Tab] would leave the focus on the current window.
This is because of a mechanism in `meta_display_get_tab_list()` which
forces the windows with the demand attention flag set to be placed first
in the MRU list when they're placed on a workspace different from the
current one.
But because workspaces apply only to the primary monitor (by default),
the windows placed on other outputs have their workspace set to `NULL`
which forces them ahead of the MRU list by mistake.
Fix this by using the appropriate `meta_window_located_on_workspace()
function to check if the window is on another workspace.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/523
The sequences may stay completed in the list (eg. pending a focus request),
it's then confusing to show the "wait" cursor icon until they are really
gone.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/541
Calculations were being done at places accounting on usec precision,
however those are still treated as having msec precision at places. Let's
consolidate for the latter since it requires less changes across the board
and usec precision doesn't buy us anything here.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/541
mutter would randomly crash in `send_xdg_output_events()` when changing
the fractional scaling:
wl_resource_post_event ()
zxdg_output_v1_send_logical_size ()
send_xdg_output_events ()
wayland_output_update_for_output ()
meta_wayland_compositor_update_outputs ()
on_monitors_changed ()
g_closure_invoke ()
signal_emit_unlocked_R ()
g_signal_emit_valist ()
_signal_emit ()
meta_monitor_manager_notify_monitors_changed ()
meta_monitor_manager_rebuild ()
This is because the xdg-output resource got freed but wasn't removed
from the list of resources.
Fix this by setting the user data of the xdg-output resource to the
corresponding `MetaWaylandOutput` so that the xdg-output resource
destructor can remove it from the list of resources.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/538
We use the combination of pressing Super and clicking+moving the mouse
to drag windows around and we also support pressing Super and using the
touchscreen to drag windows.
Since we don't want to show the overview when the Super key was used to
initiate a window drag, prevent showing the overview in case a
TOUCH_BEGIN or TOUCH_END event happened during the key was pressed.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/228https://gitlab.gnome.org/GNOME/mutter/merge_requests/495
Since "renderer/native: make EGL initialization failure not fatal" it is
possible, under specific failure conditions, to end up with a primary GPU whose
EGL initialization failed. That cannot work.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/521
The failure to initialize EGL does not necessarily mean the KMS device cannot
be used. The device could still be used as a "secondary GPU" with the CPU copy
mode.
If meta_renderer_native_create_renderer_gpu_data () fails,
meta_renderer_native_get_gpu_data () will return NULL, which may cause crashes.
This patch removes most of the failures, but does not fix the NULL dereferences
that will still happen if creating gpu data fails.
This patch reorders create_renderer_gpu_data_gbm () so that it fails hard only
if GBM device cannot be created, and otherwise always returns an initialized
gpu data structure. Users of the gpu data structure are responsible for
checking egl_display validity.
The GBM device creation failure is a hard failure because presumably GBM is
necessary for cursors.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/542https://gitlab.gnome.org/GNOME/mutter/merge_requests/521
We're currently always waiting for unfinished page flips before flipping
again. This is awkward when we are in an asynchronous retry-page-flip
loop, as we can synchronously wait for any KMS page flip event.
To avoid ending up with such situations, just freeze the frame clock
while we're retrying, then thaw it when we succeded.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
We rely on the frame clock to compress input events, thus if the frame
clock stops, input events are not dispatched. At the same time, there
is no reason to redraw at a full frame rate, as nothing will be
presented anyway, so slow down to 10Hz (compared to the most common
60Hz). Note that we'll only actually reach 10Hz if there is an active
animation being displayed, which won't happen e.g. if there is a screen
shield in the way.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
When we're in a page-flip retry loop due to the FIFO being full
(drmModePageFlip() failing with EBUSY), we should not continue to try
when starting to power save, as that means we're blocking new frames,
which itself blocks input events due to them being compressed using the
frame clock.
We'd also hit an assert assuming we only try to page flip when not power
saving.
Thus, fake we flipped if we ended up reaching a power saving state while
retrying.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/509https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
It tried to add a (implicitly casted) float to a uint64_t, and due to
floating point precision issues resulted in timestamps intended to be
in the future to actually be in the past. Fix this by first casting the
delay to an uint64_t, then add it to the time stamp.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
DPMS is configured from a bit all over the place: via D-Bus, via X11 and
when reading the current KMS state. Each of these places did it slightly
differently, directly poking at the field in MetaMonitorManager.
To make things a bit more managable, move the field into a new
MetaMonitorManagerPrivate, and add helpers to get and set the current
value. Prior to this, there were for example situations where the DPMS
setting was changed, but without signal listeners being notified about
it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/506
The 'underscan' property is a drm connector property, not a CRTC
property, so we would never find it. We also didn't advertise support
for the feature, meaning even if it was on the CRTC, Settings wouldn't
know about it.
Fix this by moving the property to where it belongs: in MetaOutputKms,
and properly advertise support for it if the property is found.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/507
Commit 8e9184b6 added filtering to avoid image jaggies when downscaling
but used `LINEAR_MIPMAP_NEAREST`. In some situations this could lead to
GL choosing a single lower resolution mipmap and then upscaling it, hence
slightly blurry.
We don't want to revert that change since it avoids aliasing jaggies, so
let's use `LINEAR_MIPMAP_LINEAR` instead. This provides the highest quality
filtering that GL can do and avoids the situation of GL using a single
mipmap that's lower resolution than the screen. Now it will blend that one
with the next mipmap which is higher resolution than the screen. This still
avoids jaggies but also maintains 1px resolution.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1105https://gitlab.gnome.org/GNOME/mutter/merge_requests/505
Use the ID_INPUT_WIDTH_MM/ID_INPUT_HEIGHT_MM udev properties to figure out
absolute input devices' physical size. This works across both backends, and
requires less moving pieces to have it get the right results.
Concretely, fixes size detection on X11/libinput, which makes touchscreen
mapping go wrong.
https://gitlab.gnome.org/GNOME/mutter/issues/514
Meson 0.50.0 made passing an absolute path to install_headers()'
subdir keyword a fatal error. This means we have to track both
relative (to includedir) paths for header subdirs and absolute
paths for generated headers now :-(
https://gitlab.gnome.org/GNOME/mutter/merge_requests/492
If an intersection is empty, the (x, y) coordinates are undefined, so
just use the work area and in-progress constrained window rect when
sliding according to the SLIDE_X or SLIDE_Y custom placement rule.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/496
When check_only is TRUE, the constraint should not be applied, just
checked. We failed to comply here when a placed transient window was
to be moved together with its parent, updating the window position
directly even if check_only was TRUE.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/496
If a client maps a persistent popup with a placement rule, then resizes
the parent window so that the popup ends up outside of the parent,
unmanage the popup and log a warning about the client being buggy.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/496
When a parent window is moved, attached windows (attached modal dialogs
or popups) is moved with it. This is problematic when such a window
hasn't been shown yet (e.g. a popup that has been configured but not
shown), as it'll mean we try to constrain an empty window. Avoid this
issue by not trying to auto-move empty windows.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/496
Currently, it is assumed that if querying the EGL_TEXTURE_FORMAT of a
Wayland buffer succeeds it is an EGLImage. However, this assumption will no
longer hold on upcoming versions of the NVIDIA EGL Wayland driver which
will include support for querying this attribute for EGLStream buffers as
well. Hence, we need to check if buffers are EGLStreams first.
Fixes#488https://gitlab.gnome.org/GNOME/mutter/merge_requests/477
Fixes condition duplicated:
/* If a contains b, just remove b */
if (meta_rectangle_contains_rect (a, b))
{
delete_me = other;
}
/* If b contains a, just remove a */
else if (meta_rectangle_contains_rect (a, b))
{
delete_me = compare;
}
Closes https://gitlab.gnome.org/GNOME/mutter/issues/480
Traditionally visual alerts were implemented by flashing the focus
window's frame. As that only works for windows that we decorate,
flashing the whole window was added as a fallback for client-decorated
windows.
However that introduces some confusing inconsistency, better to just
always flash the entire window.
https://gitlab.gnome.org/GNOME/mutter/issues/491
When commit 91c6a144da synced shadows with Adwaita, it removed the
shadow completely from attached modal dialogs. However Adwaita uses
the same shadow for all dialogs (modal or not), so do the same here.
https://gitlab.gnome.org/GNOME/mutter/issues/490
