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
Some output devices only advertise their preferred mode even though
they're able to display others too. This means we can include some
common modes in each output's supported list.
This is particularly important for mirroring, since we can only mirror
outputs which are using the same resolution.
https://bugzilla.gnome.org/show_bug.cgi?id=744544
Port the xdg_shell implementation to use the unstable v6 protocol. This
includes:
- making xdg_surface a generic base interface for xdg_shell surface
roles
- create a xdg_toplevel role replacing the old xdg_surface
- change the xdg_opup role to be based on xdg_surface
- make xdg_popup not grab by default
- add support for xdg_positioner
https://bugzilla.gnome.org/show_bug.cgi?id=769936
This commits adds support for exporting xdg_surface handles via
xdg_exporter and importing them via xdg_importer.
This bumps the required wayland-protocols version to 1.6.
https://bugzilla.gnome.org/show_bug.cgi?id=769786
intltool is unmaintained nowadays while upstream gettext gained
support for formats like GSettings schemas and .desktop files,
and offers a mechanism to teach it about other XML formats not
yet supported out of the box which we can use for the rest.
So there's nothing stopping us, just make the switch ...
https://bugzilla.gnome.org/show_bug.cgi?id=769073
Support changing the mouse and trackball acceleration profile. This
makes it possible to for example disable pointer acceleration by
choosing the 'flat' profile.
This adds an optional dependency on gudev. Gudev is used by the X11
backend to detect whether a device is a mouse or not. Without gudev
support, the accel profile settings has have effect for mouse devices.
Trackball still uses the "strstr" approach, since udev doesn't support
tagging devices as trackball devices yet.
https://bugzilla.gnome.org/show_bug.cgi?id=769179
