When logging in from gdm to gnome, the main plane is deactivated, and
leads to the screen going blank before gnome is able to enable it
again.
Using the new CloseFB ioctl, allows to keep the gdm login screen
displayed until gnome-shell replace it.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3659>
This also gets rid of the MetaFrameSyncMode enum and instead issues a
VRR update when the requested state differs from the CRTC state.
Fixes: fee33299 ("onscreen/native: Allow requesting frame synchronization")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3646>
This includes checking the vrr_capable property on the connector as well
as the VRR_ENABLE property on any CRTC the connector might get assigned
to. Also takes into account when a GPU is tagged for broken VRR support.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3646>
As we are getting close to have a Wayland-only build, guard those usages
so we don't 'regress'.
Once Kiosk figures it use case, we can revert both this commit and the
previous one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3652>
This reverts commit 917526ee9da8a1bdadda56ddfbc5050a34f45c4e.
As it is currently used by GNOME Kiosk, until upstream figures out
how to replace that code path, let us revert the commit
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3652>
The gnome-shell magnifier listens to the `visibility-changed` signal
and calls meta_cursor_tracker_set_pointer_visible(false) when the
cursor became visible.
This leads to a reentrance in meta_cursor_tracker_set_pointer_visible()
and clutter_seat_uninhibit_unfocus() gets called twice, once from the
meta_cursor_tracker_set_pointer_visible(false) by the magnifier and then
the original meta_cursor_tracker_set_pointer_visible(true) continues,
after the first call has set is_showing to false again. This breaks the
inhibitor counting and the ability to use the cursor while using the
magnifier.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3661>
Since commit e30eb788916d `ClutterFrameClock` assumes that a valid CPU time
implies timestamp query support, which is also checked in
`cogl_onscreen_egl_swap_buffers_with_damage()`.
Unconditionally setting the CPU time on direct scanout meant that the
compositing path would be stuck on the last (direct scanout optimized)
result on GL implementations without timestamp query support since.
be0aa2976e (clutter/frame-clock: Avoid rapidly toggling dynamic max render time)
Fix that by explicitly marking the gpu rendering duration as valid when
querying the GPU timestamps is supported and check for it ClutterFrameClock.
Fixes: 56580ea7c9 ("backends/native: Assume zero rendering time for direct scanout buffers")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3655>
Some clients - notably the Gstreamer vapostproc element when using Intel
GPUs - only support BGRA, not BGRx. We already assume that we can
support this format for window screen casts, and even in case of failure
we now have a re-negotiation fallback in place. Thus it's pretty safe to
support it for all screen cast types.
The possible duplication in case of window screen casts doesn't seem to
be a problem for either Pipewire or existing clients like OBS.
Note that the implementation lays the foundation to make it easy to add
more formats in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3617>
For each libinput scroll event we generate two clutter events
(continuous and discrete), one of them marked as emulated. libei
explicitly specifies that emulation of scrolling must be done in the
client (if desired) so drop the emulated one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3637>
This is used as the minimum refresh rate in the variable refresh rate
range.
This value is expected to be found in the DisplayPort and eDP EDID of
every monitor that supports variable refresh rate.
It is also found in the HDMI EDID of some monitors that support
variable (FreeSync), but most likely not all of them. The rest require
parsing the AMD vendor extension which libdisplay-info doesn't
support.
No fallback is implemented for cases where libdisplay-info support is
disabled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3576>
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>
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>
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>
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>
