summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* compositor-view: Chain up finalize()gnome-43Jonas Ådahl2023-05-091-0/+2
| | | | | | | | The chaining up to the GObject finalize() method was missing, fix that. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2991> (cherry picked from commit 802c1baec742f467ab2da9a9c6f648dc4d921d69)
* Bump version to 43.543.5Florian Müllner2023-04-252-1/+13
| | | | Update NEWS.
* surface-actor/wayland: Ensure screen-casted surfaces have a primary viewRobert Mader2023-04-251-15/+35
| | | | | | | | | | | | | | | | | | | 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)
* wayland/actor-surface: Always schedule stage updates on frame callbacksRobert Mader2023-04-251-11/+6
| | | | | | | | | | | | | | 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-cast/window: Add API to check if stream-cast is activeRobert Mader2023-04-255-0/+66
| | | | | | | | | | | 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)
* Export meta_window_has_pointer ()Ivan Molodetskikh2023-04-252-2/+3
| | | | | | | | 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)
* wayland/cursor-surface: Update cursor on disposeJonas Ådahl2023-04-1711-0/+544
| | | | | | | | | | | | | | | | | | | | | | 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>
* cursor-tracker: Don't leak window cursor on exitJonas Ådahl2023-04-171-0/+1
| | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2969>
* clutter/actor: Get next action from list before handling current actionSebastian Keller2023-04-121-4/+5
| | | | | | | | | | | | | | 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>
* Update Abkhazian translationNart Tlisha2023-04-051-18/+4141
|
* wayland: Skip subsurface desync if parent is NULLColin Kinloch2023-03-201-2/+4
| | | | | | | 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>
* Bump version to 43.443.4Florian Müllner2023-03-192-1/+14
| | | | Update NEWS.
* clutter/text: Don't call clutter_text_set_buffer() on finalizeSebastian Keller2023-03-191-1/+0
| | | | | | | | | | | 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)
* core: Avoid focusing windows on map during grabsCarlos Garnacho2023-03-191-0/+9
| | | | | | | | | | 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)
* x11: Ignore _NET_ACTIVE_WINDOW client messages while grabbedCarlos Garnacho2023-03-191-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* Revert "x11/events: Do not update focus XWindow during grabs"Carlos Garnacho2023-03-191-5/+1
| | | | | | | This reverts commit 0e6395d93284422848ca3a5ffb88d48fbce7d471. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2878> (cherry picked from commit 92792d6850aec1347152d1b0209a233d4af15252)
* Revert "x11: Do not move X11 input focus during grabs"Carlos Garnacho2023-03-193-26/+0
| | | | | | | This reverts commit a68b8e95954772cd6f5d676a803e01c13e48c83f. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2878> (cherry picked from commit 7de834b915a0361a298d790b8d337e170cb2b99d)
* stage-impl: Transform damage region before queuingRobert Mader2023-03-192-2/+15
| | | | | | | | | | | | | 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)
* cogl/onscreen: Discard depth/stencil before swapping buffersErico Nunes2023-03-191-10/+8
| | | | | | | | | | | | | | | | | | | 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: Remove requirement to discard color bufferErico Nunes2023-03-191-2/+0
| | | | | | | | | | | 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)
* color-device: Don't close lcms profile on error from cd_icc_load_handleSimon McVittie2023-03-031-5/+3
| | | | | | | | | | | | | | | | | | | | | | | 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)
* color-device: Make sure lcms_context is not NULLSimon McVittie2023-03-031-1/+8
| | | | | | | | | | | | 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)
* x11: Avoid updating focus on wayland compositorCarlos Garnacho2023-02-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* wayland: Don't overwrite surface offsetsMatthias Clasen2023-02-141-8/+13
| | | | | | | | | | | | | | | 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)
* Bump version to 43.343.3Florian Müllner2023-02-132-1/+29
| | | | Update NEWS.
* x11: Do not move X11 input focus during grabsCarlos Garnacho2023-02-133-0/+26
| | | | | | | | | | | | | | | | | | | 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)
* x11/events: Do not update focus XWindow during grabsFlorian Müllner2023-02-131-1/+5
| | | | | | | | | | | | | | | 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)
* x11/display: Add some loggingFlorian Müllner2023-02-111-0/+8
| | | | | | | 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)
* Revert "clutter/frame-clock: Fix handling of equal next_presentation_time_us"Robert Mader2023-02-101-2/+1
| | | | | | | | | | | | | | | 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
* screen-cast: Fix warning messageJonas Ådahl2023-02-011-1/+1
| | | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2811> (cherry picked from commit 176b706e662d1cae2e7e72b4f807a76955cb2bbb)
* backend: Fix a couple of minor GError leaksJonas Ådahl2023-02-012-2/+2
| | | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2811> (cherry picked from commit c95a24f6e8b3aa7af5ba34baa3402ed0cdf66ab7)
* backends/native: Keep general direction when crossing monitorsCarlos Garnacho2023-02-011-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* backends/native: Minor refactorCarlos Garnacho2023-02-011-6/+6
| | | | | | | | | | | 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)
* color-device: Don't write to fields when cancelledJonas Ådahl2023-02-011-5/+7
| | | | | | | | | | | | | | | | | | 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)
* gles3: Ensure missing_extensions is always populatedDaniel van Vugt2023-02-011-1/+1
| | | | | | | | | | | 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)
* clutter/stage-view: Properly chain up finalizeNiels De Graef2023-01-221-1/+1
| | | | | | | | | | 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)
* backends: Distinguish "no EDID" from "any EDID" mapping tabletsCarlos Garnacho2023-01-061-4/+9
| | | | | | | | | | | | | | | | | | | | | | 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)
* backends: Only apply EDID-based tablet mapping heuristic on integrated devicesCarlos Garnacho2023-01-061-1/+1
| | | | | | | | | | | | | 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)
* backends/native: Set up keyboard a11y when keyboards are pluggedCarlos Garnacho2023-01-061-8/+12
| | | | | | | | | | | | | | 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)
* backends/native: Initialize keyboard a11y on startupCarlos Garnacho2023-01-061-0/+8
| | | | | | | | | | 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)
* backends: Do not require a physical device to update pointer visibilityCarlos Garnacho2023-01-061-3/+0
| | | | | | | | | | | 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)
* screen-cast/src: Fix unsigned integer overflowGeorges Basile Stavracas Neto2023-01-061-2/+2
| | | | | | | | | | | | | | | | 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)
* window-actor: Use logical monitor scale on cursor scaleGeorges Basile Stavracas Neto2023-01-061-5/+10
| | | | | | | | | | | | 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)
* window-actor: Apply resource scale to cursor positionGeorges Basile Stavracas Neto2023-01-061-0/+7
| | | | | | | | | | | | | | | | | 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)
* screen-cast/src: Ceil cursor buffer sizeGeorges Basile Stavracas Neto2023-01-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* workspace: Sanity check input to activate*()Jonas Ådahl2023-01-061-0/+3
| | | | | | | | | 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)
* workspace: Cleanup workspace switch sound functionJonas Ådahl2023-01-061-18/+25
| | | | | | | | Expand aggressively abbreviated variable names; some style cleanups. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2707> (cherry picked from commit 9d9fcc0bb17d7dd00040d883831fd784878b52f7)
* workspace: Warn instead of abort on incorrect API usageJonas Ådahl2023-01-061-2/+2
| | | | | | Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2707> (cherry picked from commit 8a64746ce4ccfd66762a2e15ad02106e6f92c643)
* window: Update mru list for every workspace the window is onSebastian Wick2023-01-061-14/+14
| | | | | | | | | | | 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)
* workspace: Focus the default window only if no window is focusedSebastian Wick2023-01-061-0/+25
| | | | | | | | | | | 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)
View Lorry Controller Status