Frame synchronization is enabled for a view as long as it's
applicable to be enabled. It is considered applicable if it's both
requested for the onscreen and if the onscreen uses a CRTC which is
configured with a variable refresh rate mode.
When frame synchronization is enabled, it enables both the the variable
scheduling mode of ClutterFrameClock and the variable refresh rate
property for the CRTC.
Changes in the frame synchronization mode are applied asynchronously,
before the next frame is drawn.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154>
Add variable refresh rate output modes for connectors that are VRR
capable when VRR is not disabled for the GPU.
Variable refresh rate output modes are sorted before their fixed
refresh rate counterparts. They are also marked as the preferred mode
for the output between the two.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154>
When VRR is not disabled for a GPU, create two variants of every
display mode: one with fixed refresh rate and another with variable
refresh rate.
The variable refresh rate modes are not used yet. They will be used
in a following commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154>
This can be used to disable VRR in specific drivers and hardware
combinations where it is found to be problematic.
No default rules are added for now to encourage testing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154>
Require the "variable-refresh-rate" keyword under the
"experimental-features" gsetting to enable the feature for now.
It would no longer be required once the experience with variable
refresh rate is good enough for general use and handles all common
use cases well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154>
Use a sufficiently low refresh rate to calculate the CRTC deadline
when variable refresh rate is enabled. This is done to avoid cursor
updates from driving the monitor refresh rate.
It's not great solution and is sometimes not enough, but it avoids
stutter in the main content as a result of cursor movement in most
cases.
The unfortunate downside of this approach is that cursor movement
would usually only update with the main content and would not be
smooth when the main content updates are not frequent enough.
A better solution may use an approach similar to LFC (Low Framerate
Compensation) to insert cursor-only updates between updates of the
main content, but achieving adequate results with an approach of this
nature requires more research and experimentation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154>
It is not trivial to accurately estimate the expected presentation
time with variable refresh rate, and not doing so only affects debug
prints.
No change in behavior for now because the expected presentation time
is always calculated. A following commit will introduce a case where
it is not.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154>
Add functions to update and monitor the value of the "VRR_ENABLED"
KMS property.
This requires the addition of functions to process CRTC property
updates in both the atomic and the simple KMS backends. The
implementation is similar to the implemention of processing
connector updates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154>
Commit d48129f5ee broke the displaying of our own drag cursor during window
drags, as now the window cursor is always used, even during stage grabs
(window grabs are just a kind of stage grab).
To fix it, while not regressing on the intention of the other commit, unset
the MetaWaylandPointer surface in case a window drag is active (instead of
all kinds of grabs) by checking via meta_display_is_grab().
Fixes: d48129f5ee ("wayland: Fix pointer cursor during Wayland grabs")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3316
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3624>
Move the bulk of the implementation inside MetaWaylandPointer
files, like it happens in other places (e.g. MetaWaylandTabletSeat).
This avoids MetaWaylandPointer struct peeking from outside.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3627>
The _MUTTER_FRAME_EXTENTS need to have the correct size before the
window is shown, otherwise the client window size will effectively have
the headarbar height subtracted when initially syncing the frame/client
geometries.
This reverts commit f10b3eac62.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3628>
QueryDeviceString can successfully return NULL. The convention however
is that when NULL is returned, the error will be set.
This commit makes the returned string an output parameter which allows
us to return the success status and have the error set accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3614>
The convention is that when a function returns FALSE or NULL, the error
will be set. In this file we call set_egl_error but it might not set an
error. Code of the form
if (egl_do_thing (..., &error))
use_error (error);
will crash in those cases.
This commit makes sure we always set the error even if EGL doesn't give
us an error.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3614>
We depend on Gio for many introspection features (GSettings, GFile...)
without this we'd end up not having many symbols being exposed.
And errors such as
Warning: Meta: meta_display_add_keybinding: argument settings:
Unresolved type: 'GSettings*'
As per previous commit we now have this dependency implicitly, but still
it's better to make it clearer in case Clutter would drop it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3620>
This is added as a hint so that the caller can optionally use it, e.g.
in the case that a window drag is driven by the mouse. This will be used
to more accurately follow the drag position, other than starting at the
current pointer position.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3546>
Pointer constraints obey to logical pointer focus changes, and looking
up the current surface in order to maybe enable them is getting ahead
of itself, since the pointer focus might differ from the current surface
due to other factors (e.g. grabs).
Change the code checking whether constraints should be enabled to again
check the pointer logical focus, this will be influenced by the
MetaWaylandEventInterface mechanism, and correctly reflect the logical
state accounting for those factors.
Fixes: 125ba92169 ("wayland: Port pointer constraints to using MetaWaylandEventInterface")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3303
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3618>
Currently, we don't handle too well the removal of a MetaWaylandEventInterface
during meta_wayland_event_interface_invalidate_all_focus(), since the
MetaWaylandEventInterface may be freed at an intermediate point in that function
while handling the focus change for all input devices.
Turn this invalidate_all_focus() function into a MetaWaylandInput method, and
always ensure to use the currently effective MetaWaylandEventInterface when
resetting the focus for each device.
This fixes the situation through handling reentrancy naturally, a focus
sync (say, triggered by a grab) would reset a device focus (say, pointer), which
would remove an event interface (say, a pointer constraint), which would
invalidate_all_focus() again underneath using the new effective
MetaWaylandEventInterface. When that is done, the initial invalidate_all_focus()
call would re-apply the same focus to the same currently effective
MetaWaylandEventInterface, resulting in a no-op for the remainder of the function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3618>
Even though the logical focus is typically business that only the
MetaWaylandEventInterface mechanism minds about, there are some pointer
subsystems that want to look this up, as opposed to the current surface.
Add a getter to make this easier, without struct peeking.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3618>
This also removes some g_return_if_fail's because the test suite expects
to be able to create arbitrary KmsUpdates even if they don't make sense
for the real state. We just get lucky that the test suite isn't
constructing updates with color space and hdr changes, yet.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3552>
Currently querying support for some output features is done partially
through the OutputInfo and partially via KMS CRTC and Connector objects.
Let's be consistent and use OutputInfo always which works with all
backends and backend types.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3552>
We're currently pretending the gamma LUT has another size. This becomes
a problem when we try to reset the LUT to passthrough, create an
identity LUT for it and it has a size that the kernel doesn't accept.
We do track the size and have utility for creating the LUTs, so let's
just use them.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3552>
The kernel doesn't let us set gamma to passthrough with the legacy API
so we have to trick a bit and create an identity LUT, and also when we
read the KMS state, detect when an identity LUT is active.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3552>
