Skip to content

screencast: Add ability to stop streams

The implementation follows here the discussed design in #2889 (comment 1855334).

Quoting the main commit here:

When a stream is destroyed by a consumer, mutter won't be able to
recognize that.
For mutter, the stream just paused, but did not disconnect, because the
connection state of a PipeWire stream only represents, whether the
respective PipeWire context is connected to PipeWire.
In addition to that, it may be the case, that the stream consumer just
recreates the stream.
So even if mutter would be able to know, when the stream consumer
destroyed a stream, but not the whole screencast or remote-desktop
session, then mutter would not know, whether the stream will be resumed
eventually or not.

So, add an explicit API call to the screencast interface to stop a
stream.
For virtual streams, this also means, that the respective virtual
monitor is destroyed.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2889

Quoting here the following fix too (needed so mutter won't crash, when destroying virtual monitors here):

When a virtual stream is destroyed, its respective virtual monitor is
destroyed too. When the virtual monitor is destroyed, mutter reloads
the monitor manager.
However, at this point, the virtual stream is not completely destroyed
yet. The viewport of the virtual monitor still exists at this point and
when the monitor manager reloads, it will try to fetch the logical
monitor of the now destroyed virtual monitor, which will fail and thus
gnome-shell will run into a segfault.

Fix this situation by reloading the monitor manager in an idle callback.
When the monitor manager reloads, the virtual monitor is completely
gone, since the viewport of the virtual monitor is destroyed after the
virtual monitor itself.

Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2864

Required for: gnome-remote-desktop!202 (merged)

Edited by Pascal Nowack

Merge request reports