One of the current limitations of EGLStreams is that there's no way to
resize a surface consumer without re-creating the entire stream.
Therefore, while resizing, clients will send wl_surface::attach requests
so the compositor can re-create its endpoint of the stream, but no
buffer will be available actually. If we proceed with the rest of the
attach operation we'll be presenting an empty buffer.
In order to fix this, a separate wl_eglstream_controller protocol has
been introduced that clients can use to request a stream re-creation
without overloading wl_surface::attach for that purpose.
This change adds the required logic to create the corresponding
wl_eglstream_controller global interface that clients can bind to.
Whenever a client requests a stream to be created, we just need to
create and realize the new EGLStream buffer. The same buffer resource
will be given at a later time to wl_surface::attach, whenever new
content is made available by the application, so we can proceed to
acquire the stream buffer and update the surface state.
https://bugzilla.gnome.org/show_bug.cgi?id=782575
We require logind for the native backend, but the backend itself is
optional. However since commit 06c357d78, we will always throw an
error if neither logind nor elogind are available, even when the
backend is disabled.
As we still support "auto" - that is, whether the native backend is
enabled depends on whether its dependencies are available - the
easiest option is to make sure we always include either elogind or
libsystemd in the dependency check rather than erring out explicitly
if neither is found.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/96
This commit allows building mutter with elogind, which is
systemd-logind extracted into a standalone package. This
allows using mutter with its native-backend ( and consequently
wayland ) enabled on distros which use init systems other than
systemd.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/46
Instead of bailing out when a seemingly random file is missing, require
the version of wayland-protocols that includes the source to create that
built file.
Introduced in d714a94
Newer versions of GBM support buffer modifiers, including multi-plane
buffers. Use this new API to explicitly pull the information from GBM,
and feed it to drmModeAddFB2WithModifiers.
https://bugzilla.gnome.org/show_bug.cgi?id=785779
The KMS IN_FORMATS blob property contains a structure defining which
format/modifier combinations are supported for each plane. Use this to
extract a list of acceptable modifiers to use for the primary plane for
XRGB8888, so we can ask EGL to allocate tiled/compressed buffers for
scanout when available.
https://bugzilla.gnome.org/show_bug.cgi?id=785779
The xdg-output protocol aims at describing outputs in way which is
more in line with the concept of an output on desktop oriented systems.
For now it just features the position and logical size which describe
the output position and size in the global compositor space.
This is however much useful for Xwayland to advertise the output size
and position to X11 clients which need this to configure their surfaces
in the global compositor space as the compositor may apply a different
scale from what is advertised by the output scaling property (to achieve
fractional scaling, for example).
This was added in wayland-protocols 1.10.
https://bugzilla.gnome.org/show_bug.cgi?id=787363
Pipewire doesn't export its version defines, so the API checks added
in commit f0c6c4eb1f effectively disable screencasting, whoops.
Breaking changes like this should disappear once the library stabilizes,
so simply define the version ourselves instead of writing a "proper"
test with AC_COMPILE_IFELSE() ...
https://bugzilla.gnome.org/show_bug.cgi?id=788572
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
Raise wayland-server requirement to 1.13.0 to use the new API to control
wl_global visibility, so that we can hide Xwayland specific protocols
from other regular clients.
https://bugzilla.gnome.org/show_bug.cgi?id=783342
Some distros such as Ubuntu and Debian set it to 'no',
while others might keep it to 'unknown' (which defaults to
'yes'). And this causes troubles when linking with mutter-clutter
in some tests.
https://bugzilla.gnome.org/show_bug.cgi?id=782821
In order to minimize the amount of breakage, while at the same time
making it easier to make backward incompatible changes needed to
continue turning libmutter into a capable Wayland compositor, make the
libmutter and friends (libmutter-clutter, libmutter-cogl*) parallel
installable by adding a version number to the name. This changes
various filenames, for example what previously was libmutter.so is now
libmutter-0.so (assuming the version for now is 0), and
libmutter-clutter-1.0.so is now libmutter-clutter-0.so. The pkg-config
filenames and GObject introspection has been renamed to reflect this as
well.
This enables a downstream compositor rely on a specific version of the
libmutter API, while gracefully handling API/ABI changes by having to
update to the new version at their own pace.
https://bugzilla.gnome.org/show_bug.cgi?id=777317
It is often useful to identify the client process that created
a particular window, however the existing meta_window_get_pid()
method relies on _NET_WM_PID, which is only available on X11 and
depends on applications to set it correctly (which may not even
be possible when the app runs in its own PID namespace as Flatpak
apps do). So add a get_client_pid() method that uses windowing
system facilities to resolve the PID associated with a particular
window.
https://bugzilla.gnome.org/show_bug.cgi?id=772613
