| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Update NEWS.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Surfaces belonging to a screen-casted window should always be considered
visible even if they are not visible on any stage view - be it because
they are on a different workspace, minimized or occluded.
Doing this in an optimal fashion is highly complex right now -
interdependent with (and somewhat similar to) ClutterClones. Thus treat
stream-casted surfaces similar to those with clones, with the small
difference that even a fully invisible surface still gets a primary view
- the fastest one. This ensures that clients never refresh too slow for a
screen-cast, at the cost of sometimes refreshing too fast.
The later only happens on certain multi-monitor setups and should thus be
acceptable.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
(cherry picked from commit 4409dd24b640ecf44d158e2d1ee6f23ee778ce4e)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is an increasing number of cases where we want the frame callback
logic to run for a stage-view and the complexity needed to avoid these,
combined with the likelyhood of bugs, arguably does not justify the
benefit any more.
Thus unconditionally schedule updates for all stage-views when frame
callbacks are requested.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
(cherry picked from commit fe17dbc322480d811d0bbf256a26c7c4b1fa4110)
|
|
|
|
|
|
|
|
|
|
|
| |
Screen-casted windows need to be considered visible in various situations
but existing APIs such as `clutter_actor_is_effectively_on_stage_view()`
don't do so. Add new API that allows checking if a surface belongs to a
screen-casted window for the respective cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
(cherry picked from commit 2d5dd06a507b95c0d9f580be76f79cb5f52ab6e6)
|
|
|
|
|
|
|
|
| |
It is needed in gnome-shell in the screenshot UI to tell which window has a pointer over it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2928>
(cherry picked from commit 4f47ba26be8ba7e2da09360ca67190a90589a065)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise we'll have a cursor sprite backed by a surface that no longer
exist. This usually doesn't happen, but can happen in rare situations
related to pointer capability changes Wayland client cursor changes and
hotplugs.
Fixes the following crash:
#0 meta_wayland_surface_get_buffer at ../src/wayland/meta-wayland-surface.c:441
#1 meta_cursor_sprite_wayland_get_buffer at ../src/wayland/meta-cursor-sprite-wayland.c:83
#2 realize_cursor_sprite_from_wl_buffer_for_gpu at ../src/backends/native/meta-cursor-renderer-native.c:1612
#3 realize_cursor_sprite_for_gpu at ../src/backends/native/meta-cursor-renderer-native.c:1836
#4 realize_cursor_sprite at ../src/backends/native/meta-cursor-renderer-native.c:1854
#5 meta_cursor_renderer_native_update_cursor at ../src/backends/native/meta-cursor-renderer-native.c:1087
#6 meta_cursor_renderer_update_cursor at ../src/backends/meta-cursor-renderer.c:413
#7 meta_cursor_renderer_force_update at ../src/backends/meta-cursor-renderer.c:448
#8 update_cursors at ../src/backends/meta-backend.c:344
#9 meta_backend_monitors_changed at ../src/backends/meta-backend.c:354
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2969>
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2969>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Handling the current action might end up removing the current element
from the list, which would result in an invalid read when trying to get
the next element. Before glib 2.76 this was covered up by the use of the
slice allocator, but now this leads to a crash.
This was happening with the click action on the clear icon in the shell
search entry, which when clicked results in the clear icon being removed
along with the corresponding action.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6552
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2955>
|
| |
|
|
|
|
|
|
|
| |
In order to avoid crashes when a client already destroyed the parent
wl_surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2917>
|
|
|
|
| |
Update NEWS.
|
|
|
|
|
|
|
|
|
|
|
| |
clutter_text_set_buffer() tries to freeze/thaw notify, which is not
allowed during finalize and recent glib versions started warning about
this. This call can simply be removed, because the buffer is already set
to NULL on dispose, making the call in finalize redundant.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2566
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2790>
(cherry picked from commit cff631cb39b1b9d66b791fb51a6f2c3db8e60917)
|
|
|
|
|
|
|
|
|
|
| |
Normally, mutter implicitly allows a window being shown to take
focus. This is normally desired, except it steals input from
GNOME Shell self. Avoid focusing the just shown window in those
situations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2878>
(cherry picked from commit 3ac82a58c51a5c8db6b49e89a1232f99c79644cc)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a X11 application is started, typically what happens is:
- A startup notification token is created, with a _TIME%d suffix
- The application being spawned receives it through the environment
- (dbus piping, maybe)
- The application replies the startup notification token, and
fetches the timestamp from it
- The application makes a _NET_ACTIVE_WINDOW client message request
with this timestamp
- Mutter handles this client request and activates/focuses the window
Prevent this last step if windows are not interactable (e.g. there is
a compositor grab) and ignore the focus request. This specifically
applies to X11 clients requesting focus themselves, and unlike previous
approaches, doesn't try to prevent focus changes that do come through
interaction with Mutter/GNOME Shell.
This should only break if applications do not observe _NET_ACTIVE_WINDOW
and perform XSetInputFocus on themselves, but in that case the X11
keyboard focus is stolen from our hands already.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2878>
(cherry picked from commit 608d3019b6c8288fbfc7a916efcb8f55d5db040c)
|
|
|
|
|
|
|
| |
This reverts commit 0e6395d93284422848ca3a5ffb88d48fbce7d471.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2878>
(cherry picked from commit 92792d6850aec1347152d1b0209a233d4af15252)
|
|
|
|
|
|
|
| |
This reverts commit a68b8e95954772cd6f5d676a803e01c13e48c83f.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2878>
(cherry picked from commit 7de834b915a0361a298d790b8d337e170cb2b99d)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to queue the right values for transformed `MetaRendererView`s.
While on it ensure we query the framebuffers width/height only once,
saving some cpu cycles.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/2557
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2860>
(cherry picked from commit 943fcc7c1a5e9b7ca7cf815c9adbd35de6ab14b2)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Marking the the depth/stencil as discarded before swapping buffers for
the screen signals the GPU that we don't need to keep them around for
the future.
This helps performance by reducing memory bandwidth usage in some GPUs
which may optimize to not write those buffers back to memory at all
after rendering, when they would just be cleared right after that
anyway.
It is not necessary to mark buffers as discarded after swapping buffers.
This should have no effect according to the spec (since that is going to
be followed by new rendering commands which make the buffer valid again)
and removing that has shown no impact in performance tests.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2091>
(cherry picked from commit 523b27e2672efa1a2a1901fb6352e6c50f57f039)
|
|
|
|
|
|
|
|
|
|
|
| |
cogl_framebuffer_discard_buffers required that the color buffer is
passed, although users might want to discard e.g. just depth and/or
stencil buffers.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2091>
(cherry picked from commit 5fedd065c97a0d1ebba0062a8077a01a9bcf06b1)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As implemented in colord 1.4.6, cd_icc_load_handle() has three possible
results:
1. success, taking ownership of the profile;
2. failure because cmsGetProfileContextID returns NULL, *not* taking
ownership of the profile;
3. failure in cd_icc_load(), taking ownership of the profile.
The previous commit ensures that we are not in case 2.
In case 3 where cd_icc_load() fails, ownership was already given to
the colord CdIcc object, so it will be freed when the g_autoptr unrefs
the CdIcc, and we must not free it again: that would be a double-free,
potentially resulting in memory corruption.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/2659
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2877>
(cherry picked from commit ed12df1099d2c9b524c48d989f30c7ce1a8b1459)
|
|
|
|
|
|
|
|
|
|
|
|
| |
lcms interprets a NULL context as using a default, non-thread-safe
context, which is unsuitable for mutter's use. Make sure we're always
using a non-trivial context.
Helps: https://gitlab.gnome.org/GNOME/mutter/-/issues/2659
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2877>
(cherry picked from commit e2be2d271b9fe79e456628f58ef5d828a27edb0d)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reading upon the history of this code branch (commits 6891ce95dce
and 7a4c808e43d4 are most relevant), it seems this code is meant to
synchronize Mutter focus state taking the Xserver state as true.
That is, if Mutter tried to change the focus but something truncated
that action, Mutter focus will be changed to be in sync with the
Xserver again.
This sounds backwards in a Wayland session. Mutter focus should be
the canonical source, and not second-guessed from the current Xserver
focus window. These race conditions might still apply between X11
clients, so make these paths only apply in that case.
An example of this breaking can be reproduced with a Spotify and
Firefox window, moving the focus from the first to the second by
going to the GNOME Shell overview in between, and clicking the
Firefox window from there. The Firefox window will be raised, but
refuse to take focus.
It's unclear what made this an issue recently, perhaps commit
0e6395d9328 since the now possibly ignored XI_FocusIn/Out events
affect this accounting of the Xserver focused window. Anyhow it
sounds better to ignore these paths for Wayland/native altogether.
(cherry picked from commit 81c0cf0834e5b11ad8674accf5d143725c19d5ae)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2848>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The intention when the offset request was added to protocol was
that the attach request in a new enough protocol version should
require dx/dy to be zero, but ignore them otherwise.
The current code checks for 0, but then overwrites the existing
dx/dy with it, which renders an earlier wl_surface_offset() call
ineffective.
Fixes: #2622
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2843>
(cherry picked from commit ea373cb0590dbf5f857f6d96b10759f005b4fc93)
|
|
|
|
| |
Update NEWS.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On X11, the stage itself is backed by an XWindow, and moving the
input focus elsewhere will bypass any Clutter-level grabs.
This effectively allows newly opened windows to steal the focus
from gnome-shell itself, which is clearly undesirable. To prevent
that, only allow moving the X11 focus to a Window when no grab is
in place, just like commit 50e89e376 did for the stage focus.
But particularly the updating of x11_display->focus_xwindow is not
prevented. Since it's more consistent to the MetaDisplay/MetaX11Display
dual focus tracking and across Wayland/X11 backends, ensure the X11
input focus is actually set on the last focus Window after the
grabs are gone and windows became interactable again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2832>
(cherry picked from commit a68b8e95954772cd6f5d676a803e01c13e48c83f)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During grabs, it is expected that the X11 focus does not correspond
to the display's focus window, as focus should be on the stage's
XWindow instead.
This still messes up the keyboard focus even after we stopped moving
the X11 focus, because we end up with a presumed X11 focus window
of None, and as a result the stage is considered unfocused.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5932
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2776>
(cherry picked from commit 0e6395d93284422848ca3a5ffb88d48fbce7d471)
|
|
|
|
|
|
|
| |
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5932
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2776>
(cherry picked from commit 24f796a30c8ecc62ecd38d72b00c2342ee5558a7)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 1f7527bbc4d74cbb4d79c7e21e549ef984b36e3a.
Not waiting till the next refresh cycle can cause feedback loops with
Wayland clients using "empty" commits for frame events - notably
Firefox, but possibly many other clients as well under certain
conditions.
While for Gnome 44 a more sophisticated solution is in development, lets
go with a simple and tested one for Gnome 43, going back to Gnome 42
behavior, slightly increasing the chance for frame skips.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6137
|
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2811>
(cherry picked from commit 176b706e662d1cae2e7e72b4f807a76955cb2bbb)
|
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2811>
(cherry picked from commit c95a24f6e8b3aa7af5ba34baa3402ed0cdf66ab7)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the pointer crosses monitors, we account for a single motion event
resulting in the pointer moving across more than 2 monitors, in order
to correctly account each monitor scale and the distance traversed
across each monitor in the resulting relative motion vector.
However, memory on the direction is kept short, each iteration to
find the target view just remembers the direction it came from. This
brings a pathological case with 4 monitors with the same resolution
in a 2x2 grid, and a motion vector that crosses monitors at the
intersection of all 4 in a perfect diagonal. (Say, monitors are
all 1920x1080 and pointer moves from 1920,1080 to 1919,1079).
In that case, the intersection point at the crossing between 4
monitors (say, 1920,1080) will be considered to intersect with 2
edges of each view. Since there is always at least 2 directions to
try, the loop will always find the direction other than the one
it came from, and as a result endlessly jump across all 4 possible
choices.
In order to fix this, consider only the global v/h directions,
we already know if the pointer moves left/right or up/down, so
only consider those directions to jump across monitors.
For the case at hand, this will result in three monitors visited,
(either bottomright/bottomleft/topleft, or bottomright/topright/topleft)
with a total distance of 0,0 in the middle one, effectively
resulting in a correct diagonal motion.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2598
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2803>
(cherry picked from commit 8f268f2930b15bdf974395e0c27085c69d35b99e)
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor code so that variables don't depend the on motion line
content, but the other way around. This makes it clearer what each
vector means.
This has no functional changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2803>
(cherry picked from commit 34a9141a6c975e26b12ba5d5c6739b3d9df6a2e4)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Writing to fields (in this case the MetaColorDevice::pending_state) in
response to an asynchronous operation that was cancelled means we'll
write to an arbitrary memory location, potentially causing segmentation
faults or memory corruption.
Avoid these segfaults or memory corruption by only updating state if we
weren't cancelled. Also avoid trying to dereference the device pointer
if we're cancelled.
The memory corruption due to this has been causing test flakyness in the
monitor unit tests due, which should now hopefully be fixed.
Fixes: 19837796fe39b7ab83a10721e0c9d8fb748437c4
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2794>
(cherry picked from commit ad371a443526389e54af3743ef9cf6cef9d5adea)
|
|
|
|
|
|
|
|
|
|
|
| |
This appears to be the only explanation for `init_secondary_gpu_data_gpu`
crashing in `g_strjoinv`, but I don't know the exact conditions causing
`glGetString (GL_EXTENSIONS)` to return NULL.
https://launchpad.net/bugs/1994011
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2674>
(cherry picked from commit 89b254a74ba3b64f98f8ad0727f5e420945664c1)
|
|
|
|
|
|
|
|
|
|
| |
Fix a silly copy-paste mistake. Since `GObject` is the parent class,
chaining up to `dispose()` from within your `finalize()`
implementation just leads to a little memory leak and nothing worse.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2799>
(cherry picked from commit 768ec7b0c1128c43cd3a02b17aaccb552f9626c3)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the Wacom panel rewrite, the "output" setting is handled as
a kind of tri-state for display-integrated tablets:
- If the setting is unset, the device is automatically mapped
to an output
- If the setting is set and not empty, the device is mapped to
the output defined by the EDID data
- If the setting is ['', '', ''], the device is mapped to the
span of all displays, like opaque tablets do.
This distinction for the unset setting fell through the cracks,
so both "Automatic" and "All displays" options were handled as
the former.
Add this distinction, so that display-integrated tablets can
be used like opaque tablets of sorts with no limitations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2767>
(cherry picked from commit d15c6953d8590f41e3e8b4a97dc5f78dcedec716)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are the ones attached to a display, thus they are the ones that may need
help from this heuristic. Non-integrated tablets (e.g. Intuos) will default to
the span of all monitors.
Fixes mapping of opaque tablets if a display-integrated tablet of the same
brand is also plugged in.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2767>
(cherry picked from commit ba25271408a32a2a73a82acc6e094a611001c9f0)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 4e0ffba5c attempted to fix initialization of keyboard a11y,
but mousekeys do attempt to create a virtual input device at a
time that it is too early to try to create one.
Defer this operation until keyboard devices are added, so that
we are ensured to already have the seat input thread set up.
Fixes: 4e0ffba5c - backends/native: Initialize keyboard a11y on startup
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2778>
(cherry-picked from commit 717ee78997144e8c8497d1a4e2570cfccc1288ce)
|
|
|
|
|
|
|
|
|
|
| |
The MetaSeatImpl is tracking changes on keyboard a11y setting changes,
but missing its initialization on startup.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1858
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2750>
(cherry picked from commit 4e0ffba5c13b0cbb7501976e878db2ddbb57a86b)
|
|
|
|
|
|
|
|
|
|
|
| |
We may also want to update pointer visibility from emulated events
emitted directly on logical devices, as those we generate from XI_RawMotion
on X11 when the pointer is not over a compositor window.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2344
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2766>
(cherry picked from commit 60e0fe776d16ec78328675fc805b272a962d05c0)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fields of 'priv->video_format.max_framerate' are all of type
uint32_t. Multiplying by G_USEC_PER_SEC can overflow, and equally,
dividing a large numerical type by uint32_t can err too.
Since the variable holding the result is int64_t, cast all uint32_t
fields to int64_t before doing any maths on it.
Spotted while trying to investigating an issue with framerates on
HDMI screencasts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2762>
(cherry picked from commit abfedcb0c351bbdbc64b397f4c3e7624f186a48e)
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using 'scale-monitor-framebuffer', it's important to use the
monitor's scale on top of the cursor texture scale. This matches
what the monitor screencast source does.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1541
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2737>
(cherry picked from commit 381de44c5dd50ec61f583239a11d5a9c35c5f05d)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
meta_screen_cast_window_stream_src_set_cursor_metadata() relies
entirely on meta_screen_cast_window_transform_cursor_position()
to return the correct relative cursor position.
However, this function actually does not return the expected
values, since it does not apply the resource scale to the
transformed position.
Actually apply the cursor scale when calculating the cursor
position.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2737>
(cherry picked from commit 1f705ee10a9362abfddac3594354fe0d5a5d423e)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
meta_screen_cast_stream_src_set_cursor_sprite_metadata() receives
the cursor sprite, position, and scale, and with that it downloads
the cursor sprite by drawing it into a separate framebuffer, then
calls cogl_framebuffer_read_pixels() in it - this is the offscren
path that is very common when using screen capturing applications
such as OBS Studio.
There's a sneaky issue in this code path though: the 'scale' value
is a float. The cursor size is then determined by multiplying the
sprite width and height - two integer variables - by scale, and
this relies on standard float-to-int conversions. This is problematic
as sometimes the rounded values disagree with what is expected by
cogl_framebuffer_read_pixels(). If the packing of either the cursor
width or height is off by one, glReadPixels() will try to write into
off bounds, which crashes.
This can be reproduced by enabling fractional scaling, setting a 150%
zoom level, on a 4K screen, and opening any commit with an image diff
in gitlab.gnome.org, all while screencasting. When hovering the new
image, the cursor sprite will be such that it triggers this code path,
and reproduces this issue.
Fix this by always ceiling the cursor sprite sizes.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/2542
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2736>
(cherry picked from commit 4d4e8e586233344bf4d7d04d49b8cfb47bd98fc2)
|
|
|
|
|
|
|
|
|
| |
The passed argument should be a workspace, and it should not have been
removed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2707>
(cherry picked from commit e709853ad3d043ee2ed72e75fbda0c225e30eda7)
|
|
|
|
|
|
|
|
| |
Expand aggressively abbreviated variable names; some style cleanups.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2707>
(cherry picked from commit 9d9fcc0bb17d7dd00040d883831fd784878b52f7)
|
|
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2707>
(cherry picked from commit 8a64746ce4ccfd66762a2e15ad02106e6f92c643)
|
|
|
|
|
|
|
|
|
|
|
| |
If the window is on all workspaces we should update the mru list for all
those workspaces, otherwise the default focus window for a specific
workspace can be unexpected.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2548
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2747>
(cherry picked from commit 0d69fabbe6895fdac31e044060ed16bd1f1c344a)
|
|
|
|
|
|
|
|
|
|
|
| |
This might happen when the workspace is not switched and
focus_default_window is called or when 'workspace on primary display
only' is enabled, a secondary display exists and the workspace is
switched.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2747>
(cherry picked from commit 058981dc12b294b84040147eab247ac72da3011c)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
wl_output describes the physical attributes and the mode of an output is
such a physical attribute. Swapping the width and height creates
another, incorrect mode.
Other compositors also report the physical mode and don't try to
transform it based on the orientation of buffers.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2519
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2723>
(cherry picked from commit a2ed0f97c37c552d4e288933529a0a4f9936d1d9)
|