summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Bump version to 42.942.9Florian Müllner2023-03-192-1/+15
| | | | Update NEWS.
* 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)
* backends: Do not require a physical device to update pointer visibilityCarlos Garnacho2023-03-191-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)
* 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)
* wayland/pointer-constraints: Adjustments for subsurface supportRobert Mader2023-03-191-3/+4
| | | | | | | | | | After the commit "wayland/subsurface: Implement meta_wayland_surface_get_window()" subsurfaces are supported. Adjust some comments and fix a warning that could occur when closing a window. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2717> (cherry picked from commit 08a4caff6f89d1b8f1fd614ef02b6ca49f1e8c98)
* wayland/subsurface: Check ancestor instead of toplevel window for actor syncRobert Mader2023-03-191-3/+1
| | | | | | | | | | | | | The intention here was to check if the subsurface belongs to a window. Thus it didn't behave as expected for subsurfaces belonging to non-toplevel windows. After the previous commit we can use `get_window()` to check for what we actually want here. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2717> (cherry picked from commit 225f7d46a33f7bb88c44fbefc70e7e44eb82aabf)
* wayland/subsurface: Implement meta_wayland_surface_get_window()Robert Mader2023-03-191-0/+15
| | | | | | | | | | | | | | | Subsurfaces are special regarding windows as they don't have a window, but usually have an ancestor which does. All current users of `get_window()` are either used for known surface roles, such as xdg-* ones, or, as is the case for pointer constrains, would actually want to get the ancestors window. Thus implement `get_window()` to allow pointer constrains to work. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2223 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2717> (cherry picked from commit 8af356c2c791a236977bbcc347e8d4378b6587ea)
* 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)
* data/udev: Don't disable KMS modifiers on newer i915 systemsSameer Lattannavar2023-02-211-1/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When modifiers are enabled on mutter on some of the older i915 systems observed Black-screen on 2nd monitor during multi-head use cases, upon debugging observed that disabling modifiers on these systems resolved the Black-screen issue:!1618. This issue depends whether we have enough DBuf space to provide required bandwidth for the userspace demands. Those platforms which have less Display Buffer, will just have more chance to face lack of it. However it still depends on various factors like amount of planes(i.e the more planes we have, the more we divide the buffer), refresh rate, bpp and so on. This affects watermark calculations and the minimum blocks required for at least wm level 0. If we don't have sufficient ddb at least for wm0 for all planes in the configuration then it is rejected. Until we have TEST_ONLY commit solution is built we could make sure to disable modifiers support on these older i915 systems based on udev rules defined in this commit. This commit makes sure that modifiers are still usable on latest i915 systems. List of PCI-IDs are referred from: https://gitlab.freedesktop.org/mesa/mesa/-/blob/f8bf2a9a15d2572974448ed67a282f195d490323/include/pci_ids/iris_pci_ids.h Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/1618 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2641> (cherry picked from commit: 9fab8410d794344b6d953e577b1dedbb21b855b2)
* 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 42.842.8Florian Müllner2023-02-132-1/+22
| | | | 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)
* x11/session: Set the context as client data on connection watchJonas Ådahl2023-02-071-3/+3
| | | | | | | | | | | | | It was already assumed to be the context, but we never set it as such, so things just crashed instead. Now when we set it up correctly, hopefully that won't happen anymore. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2406 Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2267 Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5078 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2609> (cherry picked from commit 60b382c4e36fbcdb4d7e98d5590650890b9243e8)
* 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)
* 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: 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)
* core: Consider ClutterGrabs checking whether windows are interactiveCarlos Garnacho2023-01-061-2/+6
| | | | | | | | | | | | | | | | | | There's 2 users of this, meta_display_sync_wayland_input_focus() which does already perform these checks on its own, and MetaCursorTracker's update_displayed_cursor() to determine whether it should go with the Wayland client's cursor. This second check should also consider the existing ClutterGrabs, so make meta_display_windows_are_interactable() handle them for both callers. Fixes the cursor shown over windows while e.g. there are menus opened. Close: https://gitlab.gnome.org/GNOME/mutter/-/issues/2553 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2754> (cherry picked from commit 02d4a07822de2fb0002186df62bb0c8127555085)
* wayland/actor-surface: Optimize update schedulingRobert Mader2023-01-061-3/+8
| | | | | | | | | | | This code path is important for "empty" commits to ensure we schedule frame callbacks even if previous commits didn't cause stage redraws. There is, however, no reason to schedule updates on all stage views instead of only those the actor is on. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671> (cherry picked from commit 35ecaafd6b41bdb0e465f255801ca4e7148ad638)
* surface-actor-wayland: Clean up and optimize check for primary viewRobert Mader2023-01-064-39/+54
| | | | | | | | | | | | | | | | | | | | | | Avoid some allocations, save some CPU cycles and make the code easier to read. Behaviourwise the only expected change is that now, if there are mapped clones, we unconditionally choose the view with the highest refresh rate the actor (or one of its clones) is on and don't check the obscurred region any more. Thus in some cases a client may receive a higher rate of frame callbacks when obscured on a faster view while a clone is present on a slower one. The assumption is that cases like this are relatively rare and that the reduction of code complexity, the reduction of allocations in `meta_surface_actor_is_obscured_on_stage_view()` whenever the actor is not fully obscured and has clones on other views, as well as generally fewer lookups and less code in most common cases, compensate for that. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671> (cherry picked from commit 292a8500ed45598d05fea954678e74cec9078e01)
* clutter/actor: Make is_effectively_on_stage_view() match has_mapped_clones()Robert Mader2023-01-061-0/+10
| | | | | | | | | | The clone handling did not take certain cases into consideration, thus copy over some extra checks from `has_mapped_clones()`, ensuring consistent behavior. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671> (cherry picked from commit cef925c37f30431f51799ed2e5f3e18a8f2f9c1b)
* feedback-actor: Disable direct scanout during lifetimeRobert Mader2023-01-061-0/+10
| | | | | | | | | | | | | | | | | | We only support feedback-actors, such as DnD-icons, in the compositing path at the moment. The approach is similar to how we handle certain shell elements. Implementations need to ensure no references to the object keep around longer that necessary. Arguably this should be replaced by a more robust and implicit actor hierachy detection in the direct scanout code at some point. Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/2470 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2677> (cherry picked from commit 04655c8bffc2e9dd4842f344637022e66d7ebcf1)
* Add Abkhazian translationNart Tlisha2023-01-062-0/+727
|
* tiling: Remove unnecessary update_edge_constraints().Michael Webster2022-12-091-3/+0
| | | | | | | | | | Both meta_window_maximize and meta_window_tile use meta_window_maximize_internal(), and edge constraints are already recalculated and updated there. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2579> (cherry picked from commit ec17d19c76fdb53e5b0a96d3783403c7517abc26)
* tiling: Skip the resize effect for tiled windows during user grabs.Michael Webster2022-12-091-6/+10
| | | | | | | | | | meta_window_tile gets called by the grabbed window's match during tile resizing. These incremental changes don't need to be animated. Closes: #2246 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2579> (cherry picked from commit 559e6ff327a358a6daa4b0683fee95700591749f)
* Bump version to 42.742.7Florian Müllner2022-12-052-1/+17
| | | | Update NEWS.
* display: Freeze stack when closing X11 displayJonas Ådahl2022-12-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | If two X11 windows were the last two, we'd remove them from the stack while unmanaging them. That'd hit an assert in meta_stack_tracker_restack_managed(), resulting in the following crash when Xwayland exited unexpectedly with two or more X11 windows being the only windows on the stack: #1 g_assertion_message() at ../glib/gtestutils.c:3256 #2 g_assertion_message_expr() at ../glib/gtestutils.c:3282 #3 meta_stack_tracker_restack_managed() at ../src/core/stack-tracker.c:1210 #4 on_stack_changed() at ../src/core/stack.c:142 #5 _g_closure_invoke_va() at ../gobject/gclosure.c:895 #6 g_signal_emit_valist() at ../gobject/gsignal.c:3456 #7 g_signal_emit() at ../gobject/gsignal.c:3606 #8 meta_stack_changed() at ../src/core/stack.c:265 #9 meta_stack_remove() at ../src/core/stack.c:324 #10 meta_window_unmanage() at ../src/core/window.c:1542 #11 meta_x11_display_unmanage_windows() at ../src/x11/meta-x11-display.c:111 #12 meta_x11_display_dispose() at ../src/x11/meta-x11-display.c:141 #13 g_object_run_dispose() at ../gobject/gobject.c:1448 #14 meta_display_shutdown_x11() at ../src/core/display.c:831 The added test specifically checks that this scenario is handled gracefully. Related: https://bugzilla.redhat.com/show_bug.cgi?id=2143637 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2704>
* shaped-texture: Reset pipelines after setting a texture with new sizeSebastian Krzyszkowiak2022-12-031-0/+1
| | | | | | | | | | | | | | Attaching a new buffer with a different size than the old one means that the viewport needs to be recalculated. Not doing this caused the viewport to be incorrectly applied when viewport_src_rect remained the same after attaching such buffer. Pipeline reset usually happens when applying a new viewport, but it doesn't happen when the viewport values remain the same. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2689> (cherry picked from commit e331e38a191a36faaa5bb049157ab77f94fd7654)
* wayland/xdg-shell: Send xdg_popup.popup_done when position invalidJonas Ådahl2022-12-031-1/+38
| | | | | | | | | | | | | | | | | | | A client may provide a positioner that places the window outside of its parent. This isn't allowed, according to spec, so we hide the window and log a warning. This, however, leads these affected clients with an incorrect view of what is mapped or not, meaning it becomes harder to recover. Fix this by sending xdg_popup.done when we hide the popup due to an invalid position. Don't error out the client, let the bug slide, as that's a less jarring experience for existing applications that reproduce this than being disconnected, which practically feels like a crash. Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2408 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2645> (cherry picked from commit ac093dc65142803601838d32dd85ed993892c7f3)
* window: Avoid focusing during workspace changesJonas Dreßler2022-12-032-0/+14
| | | | | | | | | | | | | | | | | | We can land inside meta_window_focus() in the middle of changing the window workspace, because some signal handler of MetaWorkspace's "window-removed" signal triggers a focus. This can cause a crash in `g_assert (link)` when updating the MRU list because we still think we're on the old workspace when actually we are already removed from this workspaces MRU list. To avoid crashes like this, bail out of meta_window_focus() when we're in the middle of a workspace change. Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5368 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2691> (cherry picked from commit 1816f21e216d9e8f8fdadddaaad23ae8b3a5a17a)
* window: Move all single-bit booleans to the end of the structJonas Dreßler2022-12-031-156/+157
| | | | | | | | | | | | It's a bad idea to have data like this in the middle of a struct, as it will easily cause everything behind it to be badly aligned and thus increase memory access times. So move all those bitfield booleans to the end of the struct. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2691> (cherry picked from commit 098c627f119ae3679faea332a88f9730f0d887af)
* wayland/outputs: Implement wl_output v3Robert Mader2022-12-032-3/+16
| | | | | | | | | This version adds a release event, allowing clients to tell the server that it can clean up the related wl_resource. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2692> (cherry picked from commit 1b1eed0dbdbb8fdac59a2ffa66505f7d8ed9f99e)
* window/wayland: Calculate bottom and right frame extentsSebastian Keller2022-12-031-2/+20
| | | | | | | | | | | | | | The bottom and right frame extents were never calculated and thus always remained 0. This did not lead to any obvious problems until 6cbc5180 which started relying on those to calculate the buffer rect. This resulted for example in window screenshots being cut off at the bottom right corner of the window rather than the buffer. Fixes: 6cbc5180 Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6050 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2720> (cherry picked from commit f0fd013262a7cd3606936de08d61b383dba50ffe)
* core: Avoid generating XEvent from uninitialized dataBram Stolk2022-12-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The uninitialized fields in this event causes use of uninitialised data as seen in valgrind: ==71864== Syscall param writev(vector[0]) points to uninitialised byte(s) ==71864== at 0x5026EBD: __writev (writev.c:26) ==71864== by 0x5026EBD: writev (writev.c:24) ==71864== by 0x6482A3B: UnknownInlinedFun (xcb_conn.c:296) ==71864== by 0x6482A3B: _xcb_conn_wait.part.0 (xcb_conn.c:551) ==71864== by 0x6482BAF: UnknownInlinedFun (xcb_out.c:469) ==71864== by 0x6482BAF: _xcb_out_send (xcb_out.c:470) ==71864== by 0x6483DD7: UnknownInlinedFun (xcb_out.c:416) ==71864== by 0x6483DD7: xcb_writev (xcb_out.c:409) ==71864== by 0x53B79B4: _XSend (xcb_io.c:587) ==71864== by 0x53BBF38: _XReply (xcb_io.c:679) ==71864== by 0x53AFFC9: XQueryTree (QuTree.c:47) ==71864== by 0x4982A5F: query_xserver_stack (stack-tracker.c:508) ==71864== by 0x4EA1F5F: g_closure_invoke (gclosure.c:832) ==71864== by 0x4ECFD45: signal_emit_unlocked_R.isra.0 (gsignal.c:3796) ==71864== by 0x4EC0129: g_signal_emit_valist (gsignal.c:3549) ==71864== by 0x4EC03B2: g_signal_emit (gsignal.c:3606) ==71864== Address 0x287d5900 is 32 bytes inside a block of size 16,384 alloc'd ==71864== at 0x4849444: calloc (vg_replace_malloc.c:1340) ==71864== by 0x53A5FE8: XOpenDisplay (OpenDis.c:240) ==71864== by 0x6100E3C: _gdk_x11_display_open (gdkdisplay-x11.c:1565) ==71864== by 0x60CF675: gdk_display_manager_open_display (gdkdisplaymanager.c:462) ==71864== by 0x49D59F1: open_gdk_display (meta-x11-display.c:1041) ==71864== by 0x49D5D64: meta_x11_display_new (meta-x11-display.c:1156) ==71864== by 0x49564AD: meta_display_init_x11_finish (display.c:743) ==71864== by 0x495679D: on_x11_initialized (display.c:818) ==71864== by 0x4D67558: g_task_return_now (gtask.c:1232) ==71864== by 0x4D67782: UnknownInlinedFun (gtask.c:1301) ==71864== by 0x4D67782: g_task_return (gtask.c:1258) ==71864== by 0x495663C: on_xserver_started (display.c:788) ==71864== by 0x4D67558: g_task_return_now (gtask.c:1232) ==71864== Uninitialised value was created by a stack allocation ==71864== at 0x49D4A59: take_manager_selection (meta-x11-display.c:640) ==71864== To fix this, fully initialize the event struct before sending it. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2535 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2724> (cherry picked from commit 7a103bbfe9b07d125f81f275649a74a4cd167c6b)
* clutter/actor: Show on all stage-views when actors have no allocationJonas Dreßler2022-12-031-3/+4
| | | | | | | | | | | | | | | | | | | When a badly behaving ClutterActor implementation manages to invalidate the allocation after the layout phase and before painting, we have no idea where the actor should be painted without running the whole layout machinery again. For paint volumes in this case we pretend the actor covers the whole stage and queue full-stage redraws. When updating stage-views, we're also handling this case, but not in the most graceful way. Just like with paint volumes, we should assume an actor without a valid allocation is simply everywhere, so set priv->stage_views to all available stage views in that case. Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6054 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2694> (cherry picked from commit 61cc31c3ce37d6a1d977f6cdccc3703ca824a51e)
* clutter/actor: Stop transitions in children when removingJonas Ådahl2022-12-033-5/+11
| | | | | | | | | | | | | | | | When we remove a child, we stop its transitions (animations), but we didn't stop animations on grand children. What we did, however, was to clear the stage views of the grand children, and this caused a bunch of orphaned transitions (ClutterTimeline) and accompanied warnings. Make it so that if we stop transitions, and clear stage views, also stop transitions for the grand children. Detached children don't have a way to continue animating anyway, since they have no stage view (thus frame clock) to be driven by. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2716> (cherry picked from commit a8975428763a0328c8ae563d821572a43f821050)
* wayland/pointer-gestures: Fix crash in get_*_gesture after pointer is destroyedmsizanoen12022-12-033-15/+27
| | | | | | | | | | | | | Properly handle cases where the pointer object has already been destroyed to prevent the compositor from crashing with a null pointer dereference when a client invokes a get_*_gesture method after the pointer object is destroyed e.g. when the current login session is not on foreground. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2237 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2690> (cherry picked from commit 992e169d84d9bef3769da3b0e56bec1d77932379)
View Lorry Controller Status