The service channel D-Bus interface aims to be a "back door" for
services that needs special casing in Mutter, e.g. have custom private
protocols only meant to be used by that particular service.
There are currently no special casing implemented; only the basic
service channel infrastructure is added. There is a single method on the
interface, that is meant to eventually be used by
xdg-desktop-portal-gnome to open a Wayland connection with a private
protocol needed for the portal backend's rather special window
management needs.
The service channel Wayland client works by allowing one instance of
each "type", where each time needs to be defined to work in parallel. If
a new service client connects, the old one will be disconnected.
MetaWaylandClient's are used to manage the service clients, and are
assigned the service client type.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
Currently, the peripheral "output" setting will be unset if Mutter is
deciding automatically the mapped output of a tablet device. In that
case, gnome-control-center will have a hard time figuring out itself
the better output to show the tablet calibration UI, unless it's hand
held by Mutter.
Add this private D-Bus interface so that gnome-control-center can look
up the output as determined by Mutter to bring the missing harmony
between both. This interface consists of a simple method to get the
mapped output for a input device node.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2605>
It uses the org.gnome.SettingsDaemon.Power.Screen D-Bus API. Currently
brightness set if the proxy is not ready are ignored; whether the
brightness value should be cached and set once it appears or whether
color profiles should be reapplied is yet to be decided.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
gsd-color provides this API, which exposes details about the night light
state. Currently, gsd-color also turns this state into CRTC gamma
changes, but this will eventually change, and this is a preparation for
this.
The proxy isn't yet used for anything.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
Adding a <dbus/> element containing a boolean (yes/no) determines
whether org.gnome.Mutter.DisplayConfig ApplyMonitorsConfig will be
callable. The state is also introspectable via the
ApplyMonitorsConfigAllowed property on the same interface.
For example
<monitors version="2">
<policy>
<dbus>no</dbus>
</policy>
</monitors>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
The code style in the remote-desktop API is currently a mess.
While, the overall code style in mutter and gnome-remote-desktop is to
use spaces as tabulator, the remote-desktop API is mixed with both
spaces as tabulators and actual tabulators.
In addition to that, the code style in the XDG desktop portal APIs uses
spaces as tabulators as well.
To unify the code style, replace all actual tabulators with spaces.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2255>
The code style in the screencast API is currently a mess.
While, the overall code style in mutter and gnome-remote-desktop is to
use spaces as tabulator, the remote-desktop API is mixed with both
spaces as tabulators and actual tabulators.
In addition to that, the code style in the XDG desktop portal APIs uses
spaces as tabulators as well.
To unify the code style, replace all actual tabulators with spaces.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2255>
