Commits on Source (29)
-
Florian Müllner authored
Once we are no longer managing a window, we have no business in dealing with it anymore, and operations like focusing, raising or pinging the window aren't expected to work, and can go horribly wrong if we try. https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2467 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1676> (cherry picked from commit e7b58c23)
dd2f4963 -
Florian Müllner authored
We remove pending pings when unmanaging a window, but currently don't prevent new pings to be scheduled after that. The previous commit fixed a code path where this did indeed happen, but as the result of gnome-shell trying to attach a Clutter actor to a non-existent window actor is pretty bad, also guard can_ping() against being called for an unmanaging window. https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2467 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1676> (cherry picked from commit 81f36948)
75c3fc56 -
Thomas Mühlbacher authored
Makes sure that monitor specs which may be read from EDID data do not contain characters that are invalid in XML. Makes it possible to restore monitor configs of monitor models with characters such as '&' in them. To make this change not break any tests, the sample monitor configs need to be adjusted as well. Apostrophes don't strictly have to be escaped in XML text elements. However, we now do escape the elements in `<monitorspec>` specifically. Closes: <https://gitlab.gnome.org/GNOME/mutter/-/issues/1011> (cherry picked from commit 70cdd720) Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1694>
c5617502 -
Thomas Mühlbacher authored
`g_free()` alone can't help if the value it gets is `NULL` + the offset of the struct members. This prevents gnome-shell from segfaulting if `monitors.xml` contains invalid XML. Closes: <https://gitlab.gnome.org/GNOME/mutter/-/issues/1011> (cherry picked from commit 88647ae2) Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1694>
8af95b4c -
Thomas Mühlbacher authored
Make it easier to find out what went wrong with `migrated_data` by having it included in the debug logs. Closes: <https://gitlab.gnome.org/GNOME/mutter/-/issues/1011> (cherry picked from commit 180e6251) Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1694>
015acbbc -
Jonas Ådahl authored
An extension can by accident cause us to end up in a state where we try to add the same window to a workspace twice. When this happens we shouldn't crash, but instead complain loudly. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/992 Related: https://gitlab.gnome.org/GNOME/gnome-shell-extensions/-/merge_requests/157 (cherry picked from commit b55b2666) Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1694>
93a210fd -
Jonas Ådahl authored
(cherry picked from commit 9f6a4416) Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1694>
6724bbe4 -
Jonas Ådahl authored
If the monitor configuration changed, even though the streamed monitor didn't change, we'd still fail to continue streaming, as we failed to update the stage watchers, meaning we wouldn't be notified about when the stage views were painted. Fix this by reattaching the stage watches, i.e. update the painted signalling listeners to listen to the right views, when monitor changes happens. (cherry picked from commit e877b06f) Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1694>
d3b386c5 -
Jonas Ådahl authored
Like with the monitor source, we need to reattach to the new views after monitor changes, otherwise the screen cast will get stuck. (cherry picked from commit 893c0cd2) Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1694>
d881fcde -
Jonas Ådahl authored
Constantly manipulating the stack caused severe stalls (several seconds) with many open windows when switching workspaces. The cause for this was that each show/hide call dealt with the stack in isolation, meaning if you hid N windows, we'd manipulate and synchronize the stack N times, potentially doing synchronous calls to the X server while doing so. Avoid the most severe stalls by freezing the stack while calculating showing; this made the worst case go from several seconds to around 10-20 ms, which is still bad, but by far not as bad. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1616> (cherry picked from commit d43c8cd8)
f68f0607 -
Mutter freezes Xwayland commits when resizing windows, and thaw them in the window actors' after_paint() for X11. Yet, after_paint() could be never called, as when a new window is mapped while the overview is active in gnome-shell. As a result, the content of the X11 window will remain invisible to the overview. Add a new window actor API to tell whether commits can be frozen. For Wayland window actors, this always return FALSE, whereas for X11 window actors, it checks whether the Clutter actor is mapped. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1678> (cherry picked from commit df5a5d27)
2d47adc1 -
Now that we have a window actor API that can hint whether or not the window actor would support freezing commits, use it to avoid freezing Xwayland commit on actors that will not be thawed after paint. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1615 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1678> (cherry picked from commit a2e2cfe4)
2d424a73 -
Robert Mader authored
Analogous to MetaWindowActor. Also take it into account for positioning when an anchor is set. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1683> (cherry picked from commit dfa659b5)
989ef121 -
Robert Mader authored
The removed parts are now all handled in MetaFeedbackActor. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1683> (cherry picked from commit 04eeeb78)
5628d042 -
Robert Mader authored
Technically this is still wrong if the source actor or dnd actor are transformed in other ways. However geometry scale is the by far most common case and we currently lack convenience API in Clutter to easily compute the right values. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1683> (cherry picked from commit 7da34f15)
22ab643c -
Jonas Ådahl authored
We might have a stage view listener attached to the stage itself if the actor didn't have a suitable frame clock when the actor was associated with the timeline. We'd then listen to stage-views-changed signals on the stage itself to be able to attach to a frame clock when one appeared. What went wrong is that if an actor that didn't have a frameclock was associated with a timeline, but then destroyed, the timeline would disassociate itself from the actor, but it'd still listen on the stage-views-changed signal on the stage. This would be in itself harmless, until the timeline itself is destroyed, as at this point, it wouldn't clean up the stage-views-changed listener on the stage, as it's assumed to only be valid when there is an actor attached. Fix this issue by cleaning up the stage's stage-views-changed listener when the actor is destroyed, as we wouldn't be able to make use of it by then anyway. Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3323 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1719> (cherry picked from commit 4145fbba)
78c61f55 -
This currently happens by default whenever the grab is finished. We want to eventually do this manually everywhere, so start here. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1720> (cherry picked from 3799606f)
26008c45 -
This object is just being detached, with no code unref'ing it. Do this whenever the XDnD selection goes unowned, usually a good indication that the drag source no longer is one. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1720> (cherry-picked from 8e01ea1e)
ee26aea1 -
Adapt more paths to manual detaching of source/offer. This is still done automatically when the grab is finished. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1720> (cherry picked from commit 0f9dc84d)
6f5832da -
In the case that DnD is performed and succeeds, we want to release the grab early, and let the transfer IPC happen in the back. For that to happen without a hitch, drag source and offer must be left related to each other after undoing the grab, even though the default ungrabbing code does that automatically (indirectly, by unsetting the drag focus). In these cases, we used to manually unset the current source, so this decoupling was skipped. Notably, one missed case is X11 DnD, so we might end up with the situation there that DnD did succeed, transfer is ongoing, but the source and offer are already decoupled, this confused the machinery and missed the finishing XdndFinished to be emitted to the X11 drag source. The prior commits prepared for this source/offer decoupling being a manual operation, this commit avoids doing this automatically when ungrabbing. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1720> (cherry picked from commit 698fe3f1)
2818cfda -
Olivier Fourdan authored
X11 clients can use different models of input handling, of which some may not result focus being set synchronously. For such clients, meta_focus_window() will not change the focus itself but rely on the client itself to set the input focus on the desired window. Add a new MetaWindow API to check when dealing with such a window. Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1716> (cherry picked from commit 6438919a)
cb7ac99f -
Olivier Fourdan authored
Commit afa43154 tried to make sure the focus was properly changed when calling focus_default_window() by checking the focused window just after trying to set the focus. However, the X11 “Inter-Client Communication Conventions Manual” version 2.0 (ICCCM 2 for short) states that some X11 client may want to use a so called “globally active input” model in which case the client expects keyboard input and set input focus even when it's not one of its own window. To comply with this, when dealing with such clients, mutter will not change the focus and send a WM_TAKE_FOCUS message instead. That mechanism will defeat the logic introduced by commit afa43154 because the focused window is not changed in this case. As a result, the input focus will fallback to the no-focus window. To avoid this, only check that the focus change occurred for windows using a synchronous focus model. v2: Split specific test for "globally active input" model (Florian). v3: Remove the check for window->unmanaging which is useless (Jonas). Fixes: afa43154 - "core: Make sure focus_default_window() worked" Close: https://gitlab.gnome.org/GNOME/mutter/-/issues/1620 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1716> (cherry picked from commit 2432508d)
2d34ee08 -
Jonas Ådahl authored
To make the double buffered shadow buffer damaged tiles detection feasable, a new EGL extension is needed for creating FBO's backed by a custom CPU memory buffer, instead of DMA buffers, as DMA buffers can be very slow to read, much slower than just painting the shadow buffer directly. Leave the code there, since such an EGL extension is intended to be added, but hide it behind an env var so that it isn't enabled by accident. (cherry picked from commit ad5b5f2c57dd0dcb9e586ea09486eebff89fb94d) https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1724 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1743>
95b683ae -
Jonas Ådahl authored
The sync ring has an API about "frames", where it is notified about the end of frames. However, its "insert wait" call is done before updates, meaning that some "insert waits" will never see the "after frame" if there was no frame drawn. This will cause mismatching in the frame counting, causing freezes in the synchronization until something else triggers an actual frame, effectively "unfreezing" the sync ring. Fix this by not only notifying the sync ring about frames when there were actual frames drawn, but also on plain updates which didn't result in a drawn frame. Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/1516 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1754> (cherry picked from commit 44a4e616)
b4192c45 -
Jonas Ådahl authored
With frame timings, we might end up in a situation where a frame drawn is expected, but no damage was posted. Up until now, mutter handled this, if the window wasn't completely hidden, by posting a 1x1 pixel damage region. The problem with this is that we now are a bit more aggressive optimizing away no-op redraws, meaning we still might end up not drawing, making things get stuck. Fix this by doing a full actor redraw, as that is the only reliable way to both a new frame being drawn, as well as the actor in question itself getting redrawn. Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1516 Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3369 Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1471 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1754> (cherry picked from commit 9b90b5a1)
894a6d09 -
Sebastian Keller authored
When a gtk theme uses larger shadows for the unfocused state than for the focused one, this can cause a crash in meta_frame_left_click_event. Since whether to call meta_frame_left_click_event is decided based on the decoration size before focusing and the control that was clicked on after focusing, this can result in an event handled in meta_frame_left_click_event being on the client area. Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1668 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1748> (cherry picked from commit c2968c89)
30c542dd -
Robert Mader authored
Unlike other subsurface state, placement operations need to get applied in order. As per spec: ``` Requests are handled in order and applied immediately to a pending state. The final pending state is copied to the active state the next time the state of the parent surface is applied. ``` Having placement operations being part of the subsurface state makes it difficult to support arbitrary orderings. Make them part of the parents surface pending state instead. Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1691 Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1768> (cherry picked from commit ba8499f9)
695be17a -
Florian Müllner authored
Update NEWS.
ffd8b25c -
Simon McVittie authoredc8d0dcf5