With the ability to query the renderer for DMA-BUF support we can
announce support for implicit modifiers. This allows PipeWire to check
for matching modifiers while negotiation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1939>
Returns TRUE if the active renderer backend can allocate DMA buffers.
This is the case hardware accelerated GBM backends, but FALSE for
surfaceless (i.e. no render node) and EGLDevice (legacy NVIDIA paths).
While software based gbm devices can allocate DMA buffers, we don't want
to allocate them for offscreen rendering, as we really only use these
for inter process transfers, and as buffers allocated for scanout
doesn't use the relevant API, making it return FALSE for these solves
that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1939>
Because both code paths require the existence of `GL_TIMESTAMP[_EXT]`
which is only guaranteed if `ARB_timer_query` (included in GL core 3.3)
is implemented.
We know when that is true because `context->glGenQueries` and
`context->glQueryCounter` are non-NULL. So that is the minimum
requirement for any use of `GL_TIMESTAMP`, even when it is used in
`glGetInteger64v`.
Until now, Raspberry Pi (OpenGL 2.1) would find a working implementation
of `glGetInteger64v` but failed to check whether the driver understands
`GL_TIMESTAMP` (it doesn't).
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2107
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2253>
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>
This adds a way to define a way, at the system level, to define a policy
of how monitor configuration files are loaded.
The intended use case is to e.g. either prefer system level monitor
configurations before user levels, or only allow system level
configurations.
Examples:
Prefer system over user level configurations:
<monitors version="2">
<policy>
<stores>
<store>system</store>
<store>user</store>
</stores>
</policy>
<configuration>
...
</configuration>
</monitors>
Only allow system level configurations:
<monitors version="2">
<policy>
<stores>
<store>system</store>
</stores>
</policy>
<configuration>
...
</configuration>
</monitors>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
strncmp() always return 0 if the passed length is 0. What this means is
that whatever the first string check happens to be, if the parsed XML
cdata was empty (e.g. if we got <element></element>), the first
condition would evaluate to true, which is rather unexpected.
Fix this by making sure the string length is correct first. Also move it
into a helper so we don't need to repeat the same strlen() check every
time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
The way device backends implement power saving differ, and power saving
needs to contain nothing incompatible in the same update. Make it
impossible to e.g. mode set, page flip, etc while entering power save by
not using MetaKmsUpdate's at all for this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
When we're predicting state, i.e. when having posted an update while
avoiding reading KMS state, copy the predicted state, update the actual
state, and check that the predicted state matches the newly updated one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
It was a bit scattered, with it being split between MetaKms and
MetaKmsImpl, dealing with MetaKmsDevice and MetaKmsImplDevice
differentation. Replace this by, for now, single entry point on
MetaKmsDevice: meta_kms_device_process_update_sync() that does the right
thing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
As other KMS tests, depends on being DRM master and vkms being loaded.
Currently consists of a sanity check that checks for the expected set of
connectors, CRTCs, planes, etc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
Right now gamma is set only via the D-Bus API (from gsd-color), but the
actual gamma isn't right after SetCrtcGamma(), meaning if one would call
GetCrtcGamma() right after setting it, one would get the old result.
Avoid this by getting the "current" CRTC gamma from the cache we manage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
When privacy screen is changed and this happens on explicit user request
(that is not a setting change) we should notify about this via an OSD.
To perform this, we keep track of the reason that lead to a privacy
screen change, and when we record it we try to notify the user about.
When the hardware has not an explicit hotkey signal but we record a
change we must still fallback to this case.
Fixes: #2105
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
Privacy screen events on connector are handled as notification events
that won't cause any monitors reconfiguration but will emit monitors
changed on DBus, so that the new value can be fetched.
We monitor the hardware state so that we can also handle the case of
devices with hw-switchers only.
In case a software state is available it means we can also support
changing the state, and if so expose the state as unlocked.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
When both a setting change and a monitor change happens we need to
ensure that the monitor settings are applied.
This is currently only related to privacy settings, but will in future
also handle other monitor parameters such as brightness.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
Some monitors support hardware features to enable the privacy screen
mode that allows users to toggle (via software or hardware button) a
state in which the display may be harder to see to people not sitting
in front of it.
Expose then this capability to the monitor level so that we can get its
state and set it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
In some cases mutter is started in the user scope from a TTY (for
example using toolbox). Using sd_pid_get_session fails because it's not
in the session scope so it falls back to the primary session
(sd_uid_get_display). We want to start mutter on the TTY we started
mutter on however. Instead of relying on the scope to figure out the
correct session we first look at $XDG_SESSION_ID which is set by
systemd_pam.so.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2254>
At first glance the `goto` looks like a loop, or potentially an infinite
loop. It's not a loop because the mode has changed at that point to
`META_SHARED_FRAMEBUFFER_COPY_MODE_PRIMARY`. But we can make it more
obvious and avoid the need for a goto.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2240>
The stage window is an interface, that added properties, that were only
then actually managed by MetaStageImpl. Shuffle things slightly, and let
the MetaStageImpl object deal with these things itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2014>
What the keymap eventually is after, are things handled by the actual
backend (MetaBackendX11), so let it keep a pointer to that. This
eliminates some usages of globals.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2014>
