Currently, ClutterFrameClock uses g_source_set_ready_time() to determine
the usec timing of the next frame. That translates into a poll() with a
millisecond timeout if no trigger occurs to break the poll() out early.
To avoid spinning the CPU, GLib always rounds *up* to the next millisecond
value unless a timeout of 0 was provided by a GSource.
This means that timeouts for the ClutterFrameClock can easily skew beyond
their expected time as the precision is too coarse.
This applies the same concept as GNOME/glib!3949 but just for the
ClutterFrameClock. That may be more ideal than adding a timerfd for every
GMainContext, but we'll see if that lands upstream. I wanted to provide
this here because it could easily be cherry-picked in the mean time if
this is found to be useful.
From a timer stability perspective, this improves things from erratically
jumping between 100s and 1000s off of the expected awake time to single
or low double digits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3636>
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>
The default value will change from `false` to `true` in future Meson
releases, so let’s be explicit.
We don’t want to check the exit status of the program in this case, as
we parse the `--help` output instead.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3640>
`find_program().path()` was deprecated in Meson 0.55, but we depend on
Meson 0.60.
This helps fix the build with `--fatal-meson-warnings`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3640>
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>
