1. 20 May, 2022 1 commit
  2. 18 May, 2022 2 commits
  3. 17 May, 2022 20 commits
  4. 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: <!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-shell#5330
      Part-of: <!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: <!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: <!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
  5. 08 May, 2022 2 commits
  6. 07 May, 2022 1 commit
  7. 06 May, 2022 4 commits
  8. 05 May, 2022 1 commit
  9. 04 May, 2022 2 commits
  10. 03 May, 2022 2 commits