There may be a race between the ability to turn stream relative input
coordinates and turning them into screen coordinates, due to the future
scenario where the entity backing a stream is created and managed ad-hoc
depending on PipeWire stream negotiations.
When an input event is sent during this time, drop it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Intended to be used to pass state from screen cast clients down the
line. The first use case will be a boolean whether a screen cast is a
plain recording or not, e.g. letting the Shell decide whether to use a
red dot as the icon, or the generic "sharing" symbol.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1377
The 'cursor-mode', which currently is limited to RecordMonitor(), allows
the user to either do screen casts where the cursor is hidden, embedded
in the framebuffer, or sent as PipeWire stream metadata.
The latter allows the user to get cursor updates sent, including the
cursor sprite, without requiring a stage paint each frame. Currently
this is done by using the cursor sprite texture, and either reading
directly from, or drawing to an offscreen framebuffer which is read from
instead, in case the texture is scaled.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/357
Adding an internal signal and use it to update the internal state before
emitting "monitors-changed" which will be repeated by the screen to the world.
https://bugzilla.gnome.org/show_bug.cgi?id=788860
As of commit 5f5ef3de2cdc816dab82cb7eb5d7171bee0ad2c5 in pipewire the
stream creator can find out the node ID of the stream it created.
So instead of using a special purpose entry to the info property box to
let the application discover stream by monitoring added nodes searching
for the given special purpose entry, just pass the node directly.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
This commit adds basic screen casting and remote desktoping
functionalty. This works by exposing two D-Bus API services:
org.gnome.Mutter.ScreenCast and org.gnome.Mutter.RemoteDesktop.
The remote desktop API is used to create remote desktop sessions. For
each session, a D-Bus object is created, and an application can manage
the session by sending messages to the session object. A remote desktop
session the user to emit input events using the D-Bus methods on the
session object. To get framebuffer content, the application should
create an associated screen cast session.
The screen cast API is used to create screen cast sessions. One can so
far either create stand-alone screen cast sessions, or a screen cast
session associated with a remote desktop session. A remote desktop
associated screen cast session is managed by the remote desktop session.
So far only remote desktop managed screen cast sessions are implemented.
Each screen cast session may have one or more streams. A screen cast
stream is a stream of buffers of some part of the compositor content.
So far API exists for creating streams of monitors and windows, but
only monitor streams are implemented.
When a screen cast session is started, the one PipeWire stream is
created for each screen cast stream created for the session. When this
has happened, a PipeWireStreamAdded signal is emitted on the stream
object, passing a unique identifier. The application may use this
identifier to find the associated stream being advertised by the
PipeWire daemon.
The remote desktop and screen cast functionality must be explicitly be
enabled at ./configure time by passing --enable-remote-desktop to
./configure. Doing this will build both screen cast and remote desktop
support.
To actually enable the screen casting and remote desktop, the user must
enable the experimental feature. See
org.gnome.mutter.experimental-features.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
