Skip to content
GitLab
Switch branch/tag
  1. 18 May, 2022 2 commits
  3. 17 May, 2022 20 commits
  5. 11 May, 2022 5 commits
    • Marco Trevisan's avatar
      monitor-manager: Ensure monitors settings after backend has been updated · c93e402a
      Marco Trevisan authored and Marge Bot's avatar Marge Bot committed 
      The monitors settings such as the privacy screen property is propagated
to the monitors via kms updates, however during initialization and
on monitors changes, we end up clearing the pending KMS updates because
such settings are added to the queue before the backend has fully
initialized the monitors, and this may lead to discarding all the
pending updates, including the one we've just planned.

To avoid this, move settings applications after we've both initialized
the backend and notified it about changes.

Also avoid to try set the settings during actual initialization, but
delay that after post-init.

Part-of: <GNOME/mutter!2372>
      c93e402a
    • Jonas Ådahl's avatar
      display: Unmanage windows before compositor · 8ec8a267
      Jonas Ådahl authored and Marge Bot's avatar Marge Bot committed 
      Prior to 'compositor: Destroy actors when unmanaging', window actors
were destroyed when the compositor object was destroyed, long after the
windows were unmanaged, however, when this instead changed to happen
when unmanaging, with the original goal to avoid having these actors try
to interact with the disposed MetaCompositor instance, it caused an
issue where window actors would be indirectly destroyed as a side effect
of their parents being destroyed, which caused some fallout in the logic
handling window-close animation tracking, which relies on
meta_window_actor_queue_destroy() being called before a window actor is
actually destroyed.

Fix this by unmanaging windows before unmanaging the compositor.

From an X11 point of view, this should be harmless, since all it really
do is call XCompositeUnredirectSubwindows().

For the native backend and the common behavior, all unmanaging the
compositor instance does is destroy clutter actors, so doing so after
window actors were already cleaned up should not be a problem, as this
was the case before too.

Fixes: 35ac3a09
Closes: GNOME/gnome-shell#5330
Part-of: <GNOME/mutter!2403>
      8ec8a267
    • Dor Askayo's avatar
      meson: Add -Werror=strict-aliasing · 570b94fc
      Dor Askayo authored and Marge Bot's avatar Marge Bot committed 
      This warning can point out design issues, so it should be useful to
have it treated as error.

Part-of: <GNOME/mutter!2406>
      570b94fc
    • Dor Askayo's avatar
      tests/screen-cast: Avoid undefined behavior with GSource · 40edfbcb
      Dor Askayo authored and Marge Bot's avatar Marge Bot committed 
      Follow the existing convention in Mutter and avoid downcasting
custom GSource structs.

Part-of: <GNOME/mutter!2406>
      40edfbcb
    • Dor Askayo's avatar
      screen-cast/src: Avoid undefined behavior with GSource · 61c9e344
      Dor Askayo authored and Marge Bot's avatar Marge Bot committed 
      Follow the existing convention in Mutter and avoid downcasting
custom GSource structs.

This fixes the following warning:
    ../src/backends/meta-screen-cast-stream-src.c:1301:20: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
     1301 |   g_clear_pointer ((GSource **) &priv->pipewire_source, g_source_destroy);
    /usr/include/glib-2.0/glib/glib-typeof.h:36:36: note: in definition of macro ‘glib_typeof’
       36 | #define glib_typeof(t) __typeof__ (t)
          |                                    ^
    ../src/backends/meta-screen-cast-stream-src.c:1301:3: note: in expansion of macro ‘g_clear_pointer’
     1301 |   g_clear_pointer ((GSource **) &priv->pipewire_source, g_source_destroy);
          |   ^~~~~~~~~~~~~~~

Part-of: <!2406>
      61c9e344
  7. 08 May, 2022 2 commits
  9. 07 May, 2022 1 commit
  11. 06 May, 2022 4 commits
  13. 05 May, 2022 1 commit
  15. 04 May, 2022 2 commits
  17. 03 May, 2022 2 commits
  19. 02 May, 2022 1 commit
    • Sebastian Keller's avatar
      x11/window: Update _NET_WM_DESKTOP when a window becomes all-workspace · 5e5480e6
      Sebastian Keller authored and Marge Bot's avatar Marge Bot committed 
      When an X11 window becomes an all-workspace window its `workspace` is
set to NULL before `meta_window_x11_current_workspace_changed()` is
called. The latter then checks for `workspace` being NULL (which also
happens when unmanaging) and then returns early. So this does not update
`_NET_WM_DESKTOP` to 0xFFFFFFFF. Instead it remains at the workspace the
window was on before. This was causing programs like `wmctrl` to switch
to this old workspace when activating such a window.

Fix this by checking if the window is unmanaging instead.

Fixes: #2242
Part-of: <!2387>
      5e5480e6