summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* cally: fix state set leakcherry-pick-79e5ec57-5Ray Strode2020-10-151-11/+15
| | | | | | | | | | | cally_actor_action_do_action leaks a state set object in the case where the actor is defunct, insensitive, or hidden. This commit plugs the leak. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1225 (cherry picked from commit 79e5ec57d24f1650cdb2f23e68c9f8bf6a494283)
* compositor: Make sure _NET_WM_FRAME_DRAWN timestamp has the right scopeJonas Ådahl2020-09-283-37/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | The timestamp sent with _NET_WM_FRAME_DRAWN should be in "high resolution X server timestamps", meaning they should have the same scope as the built in X11 32 bit unsigned integer timestamps, i.e. overflow at the same time. This was not done correctly when mutter had determined the X server used the monotonic clock, where it'd just forward the monotonic clock, confusing any client using _NET_WM_FRAME_DRAWN and friends. Fix this by 1) splitting the timestamp conversiot into an X11 case and a display server case, where the display server case simply clamps the monotonic clock, as it is assumed Xwayland is always usign the monotonic clock, and 2) if we're a X11 compositing manager, if the X server is using the monotonic clock, apply the same semantics as the display server case and always just clamp, or if not, calculate the offset every 10 seconds, and offset the monotonic clock timestamp with the calculated X server timestamp offset. This fixes an issue that would occur if mutter (or rather GNOME Shell) would have been started before a X11 timestamp overflow, after the overflow happened. In this case, GTK3 clients would get unclamped timestamps, and get very confused, resulting in frames queued several weeks into the future.
* EGL: Include EGL/eglmesaext.hJan Alexander Steffens (heftig)2020-09-234-3/+13
| | | | | | | | | The eglext.h shipped by libglvnd does not include the Mesa extensions, unlike the header shipped in Mesa. Fixes https://gitlab.gnome.org/GNOME/mutter/issues/876 (cherry-picked from commit a444a4c5f58ea516ad3cd9d6ddc0056c3ca9bc90)
* monitor-config-manager: Fallback to closed laptop lid configurationMarco Trevisan (Treviño)2020-05-051-3/+15
| | | | | | | | | | | | | | | | | | | | | | | When closing the lid of a laptop, we reconfigure all the monitors in order to update the CRTCs and (if enabled) the global UI scaling factor. To do this, we try first to reuse the current configuration for the usable monitors, but if we have only monitor enabled and this one is on the laptop lid we just end up creating a new configuration where the primary monitor is the laptop one (as per find_primary_monitor() in MetaMonitorConfigManager), but ignoring the user parameters. In case the user selected a different resolution / scaling compared to the default one, while the laptop lid is closed we might change the monitors layout, causing applications to rescale or reposition. To avoid this, when creating the monitors configuration from the current current state, in case we have only one monitor available and that one is the laptop panel, let's just reuse this configuration. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1200 (cherry-picked from commit e48516679c02bb265a80d6680a4ea34d188127e0)
* window: Really propagate effective on-all-workspaces setting to transientsFlorian Müllner2020-05-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit cda9579034b fixed a corner case when setting the initial workspace state of transient windows, but it still missed a case: should_be_on_all_workspaces() returns whether the window should be on all workspaces according to its properties/placement, but it doesn't take transient relations into account. That means in case of nested transients, we can still fail the assert: 1. on-all-workspaces toplevel 2. should_be_on_all_workspaces() is TRUE for the first transient's parent, as the window from (1) has on_all_workspaces_requested == TRUE 3. should_be_on_all_workspaces() is FALSE for the second transient's parent, as the window from (2) is only on-all-workspace because of its parent We can fix this by either using the state from the root ancestor instead of the direct transient parent, or by using the parent's on_all_workspaces_state. The latter is simpler, so go with that. https://gitlab.gnome.org/GNOME/mutter/issues/1083
* core: propagate the effective on-all-workspaces setting to transient windowCarlos Garnacho2020-05-051-1/+1
| | | | | | | | | | | | | | | | | | | Commit 09bab98b1e tried to avoid several workspace changes while in window construction, but it missed a case: If we have a window on a secondary monitor with no workspaces enabled (so it implicitly gets on_all_workspaces = TRUE without requesting it) and trigger the creation of a second window that has the first as transient-for, it would first try to set the first workspace than the transient-for window and then fallback to all/current workspace. After that commit we only try to set the same workspace than the transient-for window, but it gets none as neither is on a single workspace, nor did really request to be on all workspaces. Fixes crashes when opening transient X11 dialogs in the secondary monitor. https://gitlab.gnome.org/GNOME/mutter/merge_requests/714
* core: Avoid consecutive workspace changes in window constructionCarlos Garnacho2020-05-051-2/+1
| | | | | | | | | | | | | We first set the workspace to the transient-for parent's, and then try to set on the current workspace. If both happen, we double the work on adding/removing it from the workspace, and everything that happens in result. Should reduce some activity while typing on the Epiphany address bar, as the animation results in a number of xdg_popup being created and destroyed to handle the animation. https://gitlab.gnome.org/GNOME/mutter/issues/556
* x11: Limit touch replay pointer events to when replayingJonas Ådahl2020-04-241-13/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a touch sequence was rejected, the emulated pointer events would be replayed with old timestamps. This caused issues with grabs as they would be ignored due to being too old. This was mitigated by making sure device event timestamps never travelled back in time by tampering with any event that had a timestamp seemingly in the past. This failed when the most recent timestamp that had been received were much older than the timestamp of the new event. This could for example happen when a session was left not interacted with for 40+ days or so; when interacted with again, as any new timestamp would according to XSERVER_TIME_IS_BEFORE() still be in the past compared to the "most recent" one. The effect is that we'd always use the `latest_evtime` for all new device events without ever updating it. The end result of this was that passive grabs would become active when interacted with, but would then newer be released, as the timestamps to XIAllowEvents() would out of date, resulting in the desktop effectively freezing, as the Shell would have an active pointer grab. To avoid the situation where we get stuck with an old `latest_evtime` timestamp, limit the tampering with device event timestamp to 1) only pointer events, and 2) only during the replay sequence. The second part is implemented by sending an asynchronous message via the X server after rejecting a touch sequence, only potentially tampering with the device event timestamps until the reply. This should avoid the stuck timestamp as in those situations, we'll always have a relatively up to date `latest_evtime` meaning XSERVER_TIME_IS_BEFORE() will not get confused. https://gitlab.gnome.org/GNOME/mutter/merge_requests/886
* display: Move finishing of touch sequence to the backendJonas Ådahl2020-04-246-24/+70
| | | | | | | We need to manipulate an X11 grab when a touch sequence ends; move that logic to where it belongs - in the X11 backend. https://gitlab.gnome.org/GNOME/mutter/merge_requests/886
* window-x11: Focus a window in the active workspace as take-focus fallbackMarco Trevisan (Treviño)2019-07-181-5/+11
| | | | | | | | | | | | | | | | | | Starting with commit 2db94e2e we try to focus a fallback default focus window if no take-focus window candidate gets the input focus when we request it and we limit the focus candidates to the current window's workspace. However, if the window is unmanaging, the workspace might be unset, and we could end up in deferencing a NULL pointer causing a crash. So, in case the window's workspace is unset, just use the currently active workspace for the display. Closes https://gitlab.gnome.org/GNOME/mutter/issues/687 https://gitlab.gnome.org/GNOME/mutter/merge_requests/688 (cherry picked from commit 5ca0ef078d39548edda1a97e9066d44aa8f38108)
* monitor-manager: Don't use switch-config when ensuring configurationJonas Ådahl2019-07-081-3/+1
| | | | | | | | | | | | | | | Switch-configs are only to be used in certain circumstances (see meta_monitor_manager_can_switch_config()) so when ensuring configuration and attempting to create a linear configuration, use the linear configuration constructor function directly without going via the switch config method, otherwise we might incorrectly fall back to the fallback configuration (only enable primary monitor). This is a regression introduced by 6267732bec97773. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/342 (cherry picked from commit 149e4d69345adab2bfea84a04f88511cbad62fe0)
* monitor-manager: use MonitorsConfig to track switch_configDaniel Drake2019-07-083-12/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When constructing MetaMonitorsConfig objects, store which type of switch_config they are for (or UNKNOWN if it is not such type of config). Stop unconditionally setting current_switch_config to UNKNOWN when handling monitors changed events. Instead, set it to the switch_config type stored in the MonitorsConfig in the codepath that updates logical state. In addition to being called in the hotplug case along the same code flow that generates monitors changed events, this is also called in the coldplug case where a secondary monitor was connected before mutter was started. When creating the default linear display config, create it as a switch_config so that internal state gets updated to represent linear mode when this config is used. The previous behaviour of unconditionally resetting current_switch_config to UNKNOWN was breaking the internal state machine for display config switching, causing misbehaviour in gnome-shell's switchMonitor UI when using display switch hotkeys. The lack of internal tracking when the displays are already in the default "Join Displays" linear mode was then causing the first display switch hotkey press to do nothing (it would attempt to select "Join Displays" mode, but that was already active). Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/281 https://gitlab.gnome.org/GNOME/mutter/merge_requests/213 (cherry picked from commit 6267732bec97773883ad76f99af76057a7957283)
* screen: Unset the active workspace and remove workspaces on freeMarco Trevisan (Treviño)2019-07-081-0/+11
| | | | Related to https://gitlab.gnome.org/GNOME/mutter/issues/652
* screen: Destroy window actors after windows while unmanaging compositorMarco Trevisan (Treviño)2019-07-083-13/+22
| | | | | | | | | | | | | After commit 2e64457f4 we destroy window actors as part of compositor destruction, however this might emit 'actor-removed' signals on window groups that the shell could use to access to resources that are already free'd at this point (like the destroyed screen, in gnome-shell's Panel._updateSolidStyle()). So, move the actor destructions under in a new function and destroy the window actors as part of compositor unmanage step, just after that all the windows are unmanaged (as they need to have an actor around). Fixes https://gitlab.gnome.org/GNOME/mutter/issues/652
* window-x11: Use any focusable window as fallback delayed focus windowMarco Trevisan (Treviño)2019-07-085-28/+144
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As per commit f71151a5 we focus an input window if no take-focus-window accepts it. This might lead to an infinite loop if there are various focusable but non-input windows in the stack. When the current focus window is unmanaging and we're trying to focus a WM_TAKE_FOCUS window, we intent to give the focus to the first focusable input window in the stack. However, if an application (such as the Java ones) only uses non-input WM_TAKE_FOCUS windows, are not requesting these ones to get the focus. This might lead to a state where no window is focused, or a wrong one is. So, instead of only focus the first eventually input window available, try to request to all the take-focus windows that are in the stack between the destroyed one and the first input one to acquire the input focus. Use a queue to keep track of those windows, that is passed around stealing ownership, while we protect for unmanaged queued windows. Also, reduce the default timeout value, as the previous one might lead to an excessive long wait. Added metatests verifying these situations. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/660 https://gitlab.gnome.org/GNOME/mutter/merge_requests/669 (cherry picked from commit 6d8293a422b08af97d3da985d49448db32d59248)
* stack: Add a function to get a sorted list of focus candidatesMarco Trevisan (Treviño)2019-07-082-13/+57
| | | | | | | | | Use a static function if a window can be the default focus window, and use such function to return a filtered list of the stack. https://gitlab.gnome.org/GNOME/mutter/merge_requests/669 (cherry picked from commit 2439255f32b4e775d4427c92a6797b8bd33e7d5a)
* window-x11: Accept any focusable window as fallback focusMarco Trevisan (Treviño)2019-07-083-1/+48
| | | | | | | | | | | | | | | | As per commit f71151a5 we were ignoring WM_TAKE_FOCUS-only windows as focus targets, however this might end-up in an infinite loop if there are multiple non-input windows stacked. So, accept any focusable window as fallback focus target even if it's a take-focus one (that might not reply to the request). Added a stacking test to verify this. Closes: https://gitlab.gnome.org/GNOME/mutter/issues/660 https://gitlab.gnome.org/GNOME/mutter/merge_requests/669 (cherry picked from commit c327b2df95ff9979dd22bca2e0d285e1b3ba0add)
* window-x11: Don't double-check for unmanaging windowsMarco Trevisan (Treviño)2019-07-081-3/+0
| | | | | | | | | | | | When looking for the best fallback focus window, we ignore it if it is in the unmanaging state, but meta_stack_get_default_focus_window() does this is check for us already. So, ignore the redundant test. https://gitlab.gnome.org/GNOME/mutter/merge_requests/669 (cherry picked from commit 9aee47daa984e5cc4a1ccefb3aacfbb2729cfbc1)
* window: Emit an error and return when trying to activate an unmanagedMarco Trevisan (Treviño)2019-06-281-0/+7
| | | | | | | | | | | | | If something (i.e. gnome-shell or an extension) tries to activate an unmanaged window, we should warn about this and avoid to perform further actions as this could lead to a crash of mutter, since the window has not valid flags (like workspace) set anymore at this stage. Fixes https://gitlab.gnome.org/GNOME/mutter/issues/580 https://gitlab.gnome.org/GNOME/mutter/merge_requests/564 (cherry picked from commit a6fc656e917fd48b8708b8d9f4bf9f8b15581313)
* window-x11: Focus the default window with delay while waiting for take-focusMarco Trevisan (Treviño)2019-06-244-8/+146
| | | | | | | | | | | | | | | | | When requesting to a take-focus window to acquire the input, the client may or may not respond with a SetInputFocus (this doesn't happen for no-input gtk windows in fact [to be fixed there too]), in such case we were unsetting the focus while waiting the reply. In case the client won't respond, we wait for a small delay (set to 250 ms) for the take-focus window to grab the input focus before setting it to the default window. Added a test for this behavior and for the case in which a window takes the focus meanwhile we're waiting to focus the default window. https://gitlab.gnome.org/GNOME/mutter/merge_requests/307 (cherry picked from commit f71151a5dd990d935f3fbb39451f9b41f640b625)
* test-runner: Add 'dispatch' commandMarco Trevisan (Treviño)2019-06-241-10/+28
| | | | | | | | | | This will only wait for events to be dispatched and processed by the server without waiting for client processing. Reuse the code for the wait command too. https://gitlab.gnome.org/GNOME/mutter/merge_requests/307 (cherry picked from commit 6022b23923fa6192c630920e9f895f185977beee)
* test-runner: Add 'sleep' commandMarco Trevisan (Treviño)2019-06-241-2/+27
| | | | | | | | | | This allows to sleep for a given timeout in milliseconds. Rename test_case_before_redraw to test_case_loop_quit since it's a generic function and use it for the timeout too. https://gitlab.gnome.org/GNOME/mutter/merge_requests/307 (cherry picked from commit d08763c18cb25fe250b27bf296e1607e63e86400)
* tests: Verify focused window in closed-transient testsMarco Trevisan (Treviño)2019-06-242-3/+12
| | | | | | | | Ensure that we have a focused window when closing transient windows with no-focus or no-take-focus atoms https://gitlab.gnome.org/GNOME/mutter/merge_requests/307 (cherry picked from commit fcb408ad5d8d7fec3e6a7bdaa92e5ef06b55c2c6)
* test-runner: Add 'assert_focused' commandMarco Trevisan (Treviño)2019-06-241-0/+36
| | | | | | | | | | | This allows to verify which window should have the focus, which might not be the same as the top of the stack. It's possible to assert the case where there's no focused window using "NONE" as parameter. https://gitlab.gnome.org/GNOME/mutter/merge_requests/307 (cherry picked from commit 51f9e04ef1fa8cd7298044ac8c82e83bea425770)
* tests, stacking: Add tests with no-input and no-take-focus windowsMarco Trevisan (Treviño)2019-06-244-0/+67
| | | | | | | | | | | | When a window with no frame, that doesn't accept focus and that has no take-focus atom set is destroyed, we ended up in not changing the current_focus window, causing a crash. Added test cases that verify this situation. Related to https://gitlab.gnome.org/GNOME/mutter/issues/308 https://gitlab.gnome.org/GNOME/mutter/merge_requests/307 (cherry picked from commit 2fc7760ceed6f948d4f3c1dd74d4e57c7df05eea)
* tests: Add 'can_take_focus' command to runner and clientMarco Trevisan (Treviño)2019-06-242-0/+69
| | | | | | | | | | | | | Allow to set/unset WM_TAKE_FOCUS from client window. This is added by default by gtk, but this might not happen in other toolkits, so add an ability to (un)set this. So fetch the protocols with XGetWMProtocols and unset the atom. test-client now needs to depend on Xlib directly in meson build. https://gitlab.gnome.org/GNOME/mutter/merge_requests/307 (cherry picked from commit f2d2d473b71dbdb339c80f068c5cb3e529af2478)
* tests: Add 'accept_focus' command to runner and clientMarco Trevisan (Treviño)2019-06-242-0/+37
| | | | | | | Under the hood, calls gtk_window_set_accept_focus in the client https://gitlab.gnome.org/GNOME/mutter/merge_requests/307 (cherry picked from commit e1f839f48f8e49c826ba558fbc9d6842a156b28b)
* workspace: Focus only ancestors that are focusableMarco Trevisan (Treviño)2019-06-241-10/+27
| | | | | | | | | | When destroying a window that has a parent, we initially try to focus one of its ancestors. However if no ancestor can be focused, then we should instead focus the default focus window instead of trying to request focus for a window that can't get focus anyways. Fixes https://gitlab.gnome.org/GNOME/mutter/issues/308 (cherry picked from commit eccc791f3b3451216f957e67fec47a73b65ed2b2)
* cogl/pipeline: Don't try to access to free'd pointer dataMarco Trevisan (Treviño)2019-05-271-3/+3
| | | | | | | | | | | | | When free'ing a pipeline we destroy the BigState first and then the fragment and vertex snippets lists using the big state pointer which is now invalid. This causes a crash when G_SLICE=always-malloc is set and using MALLOC_CHECK_. So, invert the operations by free'ing the snippet lists first, and the big state afterwards. https://gitlab.gnome.org/GNOME/mutter/merge_requests/581 (cherry picked from commit 7e0d185120ea116c91a8db60276971d3fecece80)
* wayland-seat: Use g_free to cleanup MetaWaylandSeatMarco Trevisan (Treviño)2019-05-271-1/+1
| | | | | | | | | MetaWaylandSeat is allocated using g_new0(), and thus we should use g_free() to destroy it. https://gitlab.gnome.org/GNOME/mutter/merge_requests/581 (cherry picked from commit 040578657309a515df4c73b51a068140ad477f03)
* cursor-renderer-native: Free MetaCursorNativePrivate structMarco Trevisan (Treviño)2019-05-271-0/+1
| | | | | | | | Fix a small leak in native renderer. https://gitlab.gnome.org/GNOME/mutter/merge_requests/581 (cherry picked from commit b016ff29f638b04d1a756b82c461563207083391)
* Bump version to 3.28.43.28.4Florian Müllner2019-05-142-1/+28
| | | | Update NEWS.
* compositor: Disconnect from stage signals on destructionMarco Trevisan (Treviño)2019-05-032-5/+19
| | | | | | | | | From this point there's not any need for the compositor to listen to signals so we can disconnect from the stage ones we are connected to. https://gitlab.gnome.org/GNOME/mutter/merge_requests/556 (cherry picked from commit 3ba79961fed2c70df3201b3e588990c92aadcd7f)
* compositor: Destroy window actors list on destructionMarco Trevisan (Treviño)2019-05-031-0/+17
| | | | | | | | | | | | | | | | | | | | | When the compositor is destroyed we should cleanup the list of window actors we created and destroy them. Since all the actors are added to the window_group or top_window_group we can just destroy these containers (together with the feedback_group), and simply free the windows list. This is particularly needed under X11 because before we destroy the display, we might do some cleanups as detaching the surface pixmaps and freeing the damages and if this happens at later point (for example when triggered by garbage collector in gnome-shell), we might crash because the x11 dpy reference is already gone. Destroying the window actors instead, ensures we avoid any further call to X11 related functions and that we release the actors XServer resources. Fixes https://gitlab.gnome.org/GNOME/mutter/issues/576 (cherry picked from commit 7718e67f5c0c78ed93e9ad04e7254b6db70a0337)
* wayland: Remove unused GList *lDaniel van Vugt2019-05-031-1/+0
| | | (cherry picked from commit db5abbb2257e0ced5157f9ab79a64eb0e5f9bfed)
* clutter/x11: Implement keycode remap to keysyms on virtual key devicesAndrea Azzarone2019-05-033-6/+186
| | | | | | | | | | | | | Keycode lookup can fail for serveral reasons, e.g. if there is no combination of modifiers and keycodes that can produce the target keysym with the current keyboard layout. In case the keycode lookup fails, remap temporarily the keysym to an unused keycodes. Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/109 (cherry-picked from commit e3e933c47a69bd137bb83b3692d105d1261d16ff)
* clutter/x11: Consider remapped keys when guessing the keycode from the keysymAndrea Azzarone2019-04-301-0/+20
| | | | | | | | | | | | | Since e3e933c4 a keyval can be temporarily remapped to an unused keycode. Due to some limitations in XTestFakeKeyEvent, the remapping has to be done in the first xkb group/layout. In case there are two or more keyboard layouts enabled and the selected keyboard layout is not the first, clutter_keymap_x11_keycode_for_keyval will fail to retrieve the correct keycode for a remapped keyval. Let's use the reserved_keycodes map in order to retrieve the correct keycode if needed. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/443 (cherry picked from commit e0811ce1416f93906026a18fda4cd6811594cfb2)
* compositor: Avoid changing pipeline/source if shadow is not being paintedCarlos Garnacho2019-01-241-3/+12
| | | | | | | | Avoids some context invalidations in cogl. https://bugzilla.gnome.org/show_bug.cgi?id=782344 (cherry picked from commit 3c6a518d40d0ed8d04343f0780100e88f8519ed1)
* tests: Don't check pixels outside actor allocationCarlos Garnacho2019-01-241-4/+4
| | | | | | | | | | | | | The actor-shader-effect test actors are 50px wide, but we check the 51st pixel. This went along undetected until "clutter: Avoid rounding compensation when invalidating 2D actors" because the paint volumes were made slightly bigger and the shaders paint all over them (I guess nobody noticed those actors being actually ~52px wide). Update the test to check the middle of the opposite edge, so we keep neatly rounded numbers. (cherry picked from commit 1d73533f786b8f83fcffae7e5f5965d3b1f4e57a)
* clutter: Avoid rounding compensation when invalidating 2D actorsCarlos Garnacho2019-01-241-0/+15
| | | | | | | | | | This allows the redraw clip to be more constrained, so MetaCullable doesn't end up rendering portions of window shadows, frame and background when a window invalidates (part of) its contents. https://bugzilla.gnome.org/show_bug.cgi?id=782344 (cherry picked from commit a7df459416dc46321204c98197e4fd84724976e0)
* wayland/data-device: Focus out when focus surface destroyedJonas Ådahl2019-01-241-0/+18
| | | | | | | | | | When repicking after a surface was destroyed, if the destroyed surface was the drag focus, we'd try to focus-out from it after it was destroyed, causing a NULL pointer dereference. Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/336 (cherry picked from commit 95649fd2bccdac66c1d383b2db4707df12752276)
* window/wayland: Don't initialize a window as showingJonas Ådahl2019-01-241-5/+11
| | | | | | | | | | | | | | | | | | | | | | | With Wayland, a window is not showing until it's shown. Until this patch, the initial state of MetaWindow, on the other hand, was that a window is initialized as showing. This means that for a window to actually be classified as shown (MetaWindow::hidden set to FALSE), something would first have to hide it. Normally, this wasn't an issue, as normally we'd first create a window, determine it shouldn't be visible (due to missing buffer), hide it before the next paint, then eventually show it. This doesn't work if mutter isn't drawing any frames at the moment (e.g. the user switched VT), as we'd miss the hiding before showing as e result of a buffer being attached. The most visible side effect is that a window can't be moved as the window actor remains frozen. This commit fixes this issue by correctly classifying a newly created Wayland window as "hidden". Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/331 (cherry picked from commit 49780245f4187a438cd311cb2faab0069bd075ba)
* x11/window-props: Do not convert WM_NAMEFlorian Müllner2019-01-241-4/+1
| | | | | | | | | | | | | | | The WM_NAME property is of type TEXT_PROPERTY, which is supposed to be returned as UTF-8. Commit 840378ae68 broke that assumption, resulting in crashes with non-UTF8 locales; however the "fix" of converting from LATIN1 to UTF8 is wrong as well, as the conversion will spit out garbage when the input encoding isn't actually LATIN1. Now that the original issue in text_property_to_utf8() has been fixed, we can simply revert the relevant bits of commit d62491f46eba748e. https://gitlab.gnome.org/GNOME/mutter/merge_requests/227 (cherry picked from commit 62775d191372da864e00797ef4d64cb22f18ccd8)
* xprops: Make sure text_property_to_utf8() returns UTF8Florian Müllner2019-01-231-1/+5
| | | | | | | | | | | | | Commit 840378ae682 changed the code to use XmbTextPropertyToTextList() instead of gdk_text_property_to_utf8_list_for_display(), but didn't take into account that the replacement returns text in the current locale's encoding, while any callers (rightfully) expect UTF8. Fix this by converting the text if necessary. https://gitlab.gnome.org/GNOME/mutter/merge_requests/227 (cherry picked from commit 76abe87090830b27e2c624b9854ca94829b04a75)
* clutter: Do not latch modifiers on modifier keysCarlos Garnacho2019-01-161-2/+4
| | | | | | | | | | | | | | If the user maps eg. Alt+F2 to a pad button, the MetaInputSettings will send the full Alt press, F2 press, F2 release, Alt release sequence. However the keycode corresponding to Alt is found in level 1, so the Shift modifier gets unintendedly latched in addition to the Alt key press/release pair. We could probably improve keycode lookup heuristics so level=0 (and no modifier latching) is preferred, but we can do without it altogether for modifier keys. (cherry picked from commit 67aab7c13812befde061f0d2068b431b04dcbc98)
* clutter-offscreen-effect: Disable if no textureDaniel van Vugt2018-12-191-3/+6
| | | | | | | | | | | | | | | If texture allocation fails (e.g. on an old GPU with size limit 2048) then `update_fbo` would return `FALSE` but leaves `priv->offscreen` as non-NULL. So the next paint will try to use the offscreen with a `NULL` texture and crashes. The solution is simply to ensure that `priv->offscreen` is NULL if there is no `priv->texture`, so the default (non-offscreen) paint path gets used instead. Bug reported and fix provided by Gert van de Kraats. https://launchpad.net/bugs/1795774 (cherry picked from commit f31cf0c3ef99b27c0b2c0161fc9fc1eb82778b2e)
* cogl-auto-texture: Avoid a double-free crashDaniel van Vugt2018-12-191-0/+1
| | | | | | | | | | | | If texture allocation fails (e.g. on an old GPU with size limit 2048) then `cogl_texture_new_with_size` was trying to use the same CoglError twice. The second time was after it had already been freed. Bug reported and fix provided by Gert van de Kraats. https://launchpad.net/bugs/1790525 (cherry picked from commit d21478b0f0163b0688abe065a7009b33453d0d00)
* window: Really force update monitor on hot plugsOlivier Fourdan2018-11-132-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | Commit 8d3e05305 ("window: Force update monitor on hot plugs") added the flag `META_WINDOW_UPDATE_MONITOR_FLAGS_FORCE` passed to `update_monitor()` from `update_for_monitors_changed()`. However, `update_for_monitors_changed()` may choose to call another code path to `move_between_rects()` and `meta_window_move_resize_internal()` eventually. As `meta_window_move_resize_internal()` does not use the "force" flag, we may still end up in case where the window->monitor is left unchanged. To avoid that problem, add a new `MetaMoveResizeFlags` that `update_for_monitors_changed()` can use to force the monitor update from `meta_window_move_resize_internal()`. Fixes: 8d3e05305 ("window: Force update monitor on hot plugs") Closes: https://gitlab.gnome.org/GNOME/mutter/issues/189 (cherry picked from commit fa495286a1037d610051ab49f0aa1e8b20e38066) (cherry picked from commit 8eabfaaa8b9469c5bdb1d8ca44b465384e8eaa9d)
* renderer/native: Also wrap flip closures for EGLStreamsJonas Ådahl2018-10-233-14/+44
| | | | | | | | | | | | When using the EGLStream backend, the MetaRendererNative passed a GClosure to KMS when using EGLStreams, but KMS flip callback event handler in meta-gpu-kms.c expected a closure wrapped in a closure container, meaning it'd instead crash when using EGLStreams. Make the flip handler get what it expects also when using EGLStreams by wrapping the flip closure in the container before handing it over to EGL. https://bugzilla.gnome.org/show_bug.cgi?id=790316 (cherry picked from commit 8ee14a7cb7e8f072d2731d59c7dc735f83a9bb0b)
* wayland/gtk-shell: Handle requests after toplevel was unmanagedJonas Ådahl2018-10-041-10/+19
| | | | | | | | | | | As with xdg-toplevel, a gtk-surface can be unmanaged by the compositor without the client knowing about it, meaning the client may still send updates and make requests. Handle this gracefully by ignoring them. The client needs to reset all the state anyway, if it wants to remap the same surface. https://gitlab.gnome.org/GNOME/mutter/issues/240 (cherry picked from commit ca5b27baf517f00354ff8811ba204fd90f1ddb38)
View Lorry Controller Status