Which got introduced in wl_compositor version 6.
Note that if the surface is visible on multiple monitors with different
transforms, we pick the transform of the monitor which we choose for the
scale as well. This doesn't really matter at the moment, as the
transform is only really relevant for direct-scanout - which we
currently only support for fullscreen clients.
Once we support direct-scanout for partially visible clients we'll
likely want to introduce a more sophisticated algorithm.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3580>
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>
The POINTER_EMULATED flag was a convenience to filter either
side of smooth/discrete events that we should ignore based on
the source.
This distinction was challenged, first by v120 mice that use
Clutter smooth events to deliver semi-discrete changes, second
by commit e0c4b2b241 ("backends/native: Mark the emulated smooth
scroll event as such") which made the smooth events be flagged
as emulated, and the discrete whole-step events marked as
real.
This distinction feels convenient for the time being, since
upper layers might be confused by real smooth scroll events
without finish flags. Adapt to this change at MetaWaylandPointer
so that we drop the POINTER_EMULATED check, and the events are
perhaps filtered based on their source and the preferred
wl_seat version of the client that we are talking to.
This handles the whole grid of combinations:
- wheel sources with wl_seat >=8 result in wl_pointer.axis_value120
from "emulated" smooth scroll events, with value120 information.
- wheel sources with wl_seat < 8 result in wl_pointer.axis_discrete
from "real" discrete scroll events.
- finger/continuous sources prefer smooth events. Previously, always
non-emulated for those.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3642>
The wl_pointer.axis_discrete axis (applicable to wl_seat <= v8) is
meant to be sent together with wl_pointer.axis events in the same
frame. And the wl_pointer.axis_value120 event replaces it in
wl_seat >= v9, but has the same relation with the other information
available in a frame.
This emission should not be conditional to anything, so drop the
various checks leading to maybe sending wl_pointer.axis or not.
This fixes emission of wl_pointer.axis in conjunction with discrete
events, for some combinations of versions and (non)value120 mice.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3642>
Unveiled by commit e0c4b2b241 ("backends/native: Mark the emulated smooth
scroll event as such"). The sudden "lack" of smooth scroll events (Used by
Clutter to forward v120 events) made it evident we silently ignore Clutter
discrete events, as we don't send wl_pointer.axis_value120 for these.
Fix this by assigning a value120 value to discrete scroll events. This
makes wl_pointer.axis_value120 events actually sent on non-v120 mice.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3642>
meta_window_handle_ungrabbed_event() triggers the show of the window menu in
gnome-shell via meta_window_show_menu() on hold of Meta + right mouse button
click.
Since meta_display_handle_event() was refactored lately and now forwards a
lot more events to Clutter (including the one triggering the window menu),
gnome-shell now sees this event after the menu has opened, figures that the
source-actor is outside of the menu, and immediately closes the menu again.
This is the correct behavior from the PopupMenuManager on the gnome-shell
side, it is the responsibility of the event handler that opens the menu (aka
meta_window_handle_ungrabbed_event()) to return CLUTTER_EVENT_STOP and stop
event propagation.
So fix this issue by adding a return value to
meta_window_handle_ungrabbed_event() and stopping event propagation in case
the event opened the window menu.
While at it, also return CLUTTER_EVENT_STOP for events triggering window
drags, so we can drop the extra check for that in
meta_display_handle_event().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3623>
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>
`meta_window_set_user_time()` will not update the window's
user time if it timestamp in the argument is before the
currently saved timestamp. However, when trying to work around
problematic timestamps, this is exactly what needs to be done.
So force the update to happen by setting the "is user time set?"
flag to false.
Fixes: 8f3da9f68a ("Use meta_window_set_user_time for setting user time consistently")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3027>
priv->current_drag is the property that
meta_compositor_get_current_window_drag() and therefore also
meta_display_is_grabbed() bases its check on. We use
meta_display_is_grabbed() to select which cursor to use (window cursor
vs root cursor) when updating the cursor in MetaCursorTracker.
Since meta_window_drag_begin() sets a new cursor, and therefore triggers the
cursor tracker to update the current visible cursor, we should set
priv->current_drag before the call to meta_window_drag_begin(). This makes
sure the cursor tracker sees that there's a window drag and changes the
cursor right away when the window drag begins (instead of doing so on
subsequent pointer events).
Fixes: 525ed1166c ("wayland/pointer: Unset current surface during window drags")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3630>
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>
Find a surface actor that meets the criteria to drive the refresh
rate for the view. If a new surface actor is found, add a
reference to it and request frame synchronization to be enabled
for the relevant MetaRendererViewNative.
Whenever the surface actor schedules a repaint or an update, and
in case frame synchronization is enabled for the
MetaRendererViewNative, schedule the update to occur "now". This
effectively makes the surface actor's frame rate drive the refresh
rate of the monitor.
If the actor is frozen or destroyed, it is no longer expected to
schedule repaints or updates and should stop driving the refresh
rate.
When there is no surface actor to drive the refresh rate, request
frame synchronization to be disabled for the MetaRendererViewNative.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154>
This makes all stage updates that result from applying the pending
state of a Wayland surface emit an "update-scheduled" signal in the
context of the relevant surface actor.
A common case where an "update-scheduled" signal is needed is
when applying "empty" client commits. In this case a
"repaint-scheduled" signal would not be emitted since the commit
doesn't trigger a repaint. However, it is still important to add
handling for such updates with variable refresh rate when the
releavnt actor is also driving the refresh rate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154>
This function allows scheduling a stage update in the context of a
surface actor and emit the "update-scheduled" signal. This signal is
similar to "repaint-scheduled", but can be used to be notified of
updates that do not necessarily result in a repaint.
With variable refresh rate, any update potentially affecting the
frame pacing of a surface actor needs to be handled differently
depending on whether that surface actor drives the refresh rate or
not.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154>
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>
