This makes sure that xdg-output.logical_size and
xdg-output.logical_position are only sent when they actually changed.
There should be no behavior change in wl_output_transform_from_transform
but it now uses the same technique of tracking the protocol state and
comparing it to the current state to compute which properties have
changed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3622>
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>
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>
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>
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>
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>
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>
Allows to mark a wayland client window as a DOCK window. The reason for
this is that in Gala (elementary OS's window manager) we would like to
continue using GTK apps as panel and dock on wayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3612>
meta_window_update_monitor() can emit "::highest-scale-monitor-changed",
and we connected to that signal right before. Let's avoid calling
meta_wayland_surface_notify_highest_scale_monitor() twice and move the
g_signal_connect() for that signal and the initial call to
meta_wayland_surface_notify_highest_scale_monitor() to happen after
meta_window_update_monitor().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3598>
Turns out there is a better solution: Almost always, MetaWindow already has
an idea on which monitor it will be, even if it isn't positioned yet. Since
the last commit we're now using that monitor for setting the
highest-output-scale of the window, so this fallback is no longer necessary.
While we could keep this fallback around and also return a valid scale in
case the surface is not even mapped yet, this means we report fractional
scale twice for new surfaces: Once from
wp_fractional_scale_manager::get_fractional_scale() (here we'll enter the
fallback), and a second time (this time with correct scale) right after
creating the MetaWindow.
Note that wp_fractional_scale_v1 doesn't specify that a preferred_scale
event must be sent immediately after
wp_fractional_scale_manager::get_fractional_scale(), so we can safely remove
the fallback.
This reverts commit 8cfbdb4313edbd7748fb21769d37bf5c35692042.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3598>
Currently, we blindly apply the transformation matrices of all parent
actors when calculating the absolute coordinates. This means if this
function is called while the window actor containing the surface is in
the middle of a transition (e.g. window open animation), it may return
incorrect values. As this function is used for calculating pointer
confinement bounds for a specific surface, this will result in incorrect
bounds value being used if pointer constraints are applied by the
application at the same time the window is created and the mouse is
inside the surface's bounds when it's created.
Fix this by only applying transformation matrices up to the window actor
of the surface and then calculating the absolute coordinates by adding
the position of the window actor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3585>
If we don't have a monitor for a surface - e.g. because the surface is
not mapped yet - return the highest scale of all outputs. This makes us
send a preferred scale before a client draws its first frame. The highest
scale is always correct in single monitor cases and arguably a good
option otherwise as scaling down usually looks better than scaling up.
Note that this is currently only used by the fractional scale protocol,
but will also be used for the core `send_preferred_scale()` once we
implement it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3217>
We've so far returned FALSE (i.e. PROPAGATE) here, somehow
oblivious of the fact that the core event handler would stop
all non-gesture events directed to windows.
Incorporate this knowledge there, in order to be able to
streamline this piece of event handling in core/ code.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
This is Wayland specific code, handle it directly in MetaWaylandPointer.
This also fixes issues with the crossing event itself managing to reach
the window occluded by modals.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
With Wayland popups and drag-and-drop using grabs, we
should let window cursors prevail when there is one
in effect.
Also, resort always to the actor as known by the
stage. This fixes the cursor lookup right after crossing
events induced by grabs, e.g. right clicking on the
gtk4-demo textview without motion would keep the I-beam
cursor, now results on the right actor/cursor for the
menu being picked.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
Enable grabbing input for popups, and drag-and-drop. Since the very
switch to using ClutterGrab underneath Wayland grabs will challenge
assumptions in existing code, these had to change in one go. A notable
one is that meta_display_windows_are_interactable() is not 100% true
anymore for xdg_popups, at least not the same.
Another change happening in lockstep is MetaDnD no longer having
to funnel events to Wayland, since the grab triggered by Wayland DnD
is now a cause of "compositor grabs", and will naturally receive events
as long as it hold. while "modal".
A number of ad-hoc checks for grabbing state has also been dropped
from src/wayland/ internals, since again Wayland grabs are a reason
for Clutter grabs, plus the mechanism itself will already take care
of focus loss and restoration.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
Add the mechanism to integrate MetaWaylandEventInterface with grabs,
callers may now specify whether a grab is required, in which case
one is created, shared by all the event interface stack.
ClutterStage grab state is also tracked, so the MetaWaylandEventInterface
in charge will focus or unfocus depending on whether input should be
handled (if ungrabbed, or grabbed by the MetaWaylandInput itself), or
not (if grabbed by something else).
At the moment nothing uses this mechanism yet, later commits will add
the first users.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
Now that the backend handles 0-size regions naturally and MetaWaylandPointer
avoids sending wl_pointer.motion on unchanged coordinates, we can use the
default motion handler for the locked pointer constraint.
And since that is the only difference with the pointer constraint event
interface, we can unify them both into a single MetaWaylandEventInterface
handling focus for them both.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
The small catch is that MtkRegion (and pixman regions) "optimize away"
0-size rectangles, so a 0-sized region will always be seen as having
a 0,0 origin. We don't want that, so transfer the origin separately from
the region.
While at it, make the Wayland pointer lock use one such 0-size region,
to avoid the 1x1px wiggle room that it currently has (accounting for subpixel
motion).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
While every kind of input is seen as coming from the Virtual
Core Pointer in the X11 case, we can largely abstract away from
that fact, and lock XDnD pointer input to the most plausible
source (e.g. a device with a pressed button), instead of only
working with pointer input.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
This collection of event handlers is the most special of them all, as
they want to unset any pointer/touch/stylus/keyboard/pad/etc focus,
and handle events from a selected device/sequence combination through
the MetaWaylandDragDest interfaces.
The same interfaces also replace the MetaWaylandKeyboardGrabInterface
in effect that handled DnD action changes.
On the XDnD special grab side, we mainly need to let the current
client (i.e. the drag source) keep receiving input events, as they
drive the DnD operation from the X11 realm.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
This is again a grab interface that mostly wants to meddle with focus,
logically setting a NULL surface if the surface client does not match
the popup client.
Since popups are meant to naturally work with any input device, the
code has been refactored to not involve the MetaWaylandPointer directly
in MetaWaylandPopup creation or getting the top popup surface (memory
management was shuffled), or compressing multiple grabbing xdg_popups
together (the existing grab maintains a single MetaWaylandEventHandler
for all).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
