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>
They are float in libdisplay-info and our own EDID parsing also returns
a float but when then converted both to an integer. Especially the min
luminance can be <1.
We also don't need a variable for indicating presence of a CTA Static
Metadata block. The values are all zero if it is absent.
Found by Dor Askayo.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3574>
Some features depend on libdisplay-info, and making it a feature
option should increase its visibility and adoption.
This makes it required when building with "-Dauto_features=enabled",
unless explicitly disabled with "-Dlibdisplay_info=disabled".
If "-Dauto_features=enabled" is not set, everything remains the
same.
In the future, the libdisplay_info option can be made "enabled" by
default so that it would always be required unless explicitly
disabled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3582>
The function was used only once so just move it content where it is
called. It allows us to drop more cairo paths from the API surface even
if it is not part of a public api
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3581>
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>
With all early "goto out" paths bypassing wayland, we can pretty
much avoid the goto and use early returns in this function. This
will hopefully improve readability.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
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>
Users of Clutter grabs may listen for notify::revoked changes in
order to know that their grab is no longer in charge of event
propagation, without the use of crossing events.
Since a ClutterGrab may stay in the stack and regain effects,
this notification also happens the other way around.
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>
Besides the pointer locking/constraining mechanism, these grab interfaces
were more of a focus tracking mechanism, revoking the constraints when
the conditions didn't meet.
This can be handled pretty similarly to keyboard grabs with the new
interface, with the added bonus that we can chain up to let the
parent/default handler handle the events themselves, without poking at
MetaWaylandPointer API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
This is implemented at the MetaWaylandSeat level, and it governs
focus and event delivery for all devices, falling through each
of the MetaWaylandPointer/MetaWaylandKeyboard/etc components.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
MetaWaylandInput is an object that will become in charge of handling
input events on their way to the Wayland socket. It keeps a stack
of event handlers, and propagates events and changes across them in
order to have them emit Wayland events, or change focus.
Each of these event handlers has a MetaWaylandEventInterface, this
is a vtable meant to replace MetaWaylandPointerGrabInterface and
MetaWaylandKeyboardGrabInterface in an unified manner, with the
following methods:
- get_focus_surface: to return the focus surface for a device/sequence.
Since several handlers will want to delegate logic on previous
handlers, it is optional to chain up with
meta_wayland_event_handler_chain_up_get_focus_surface().
- focus: To trigger a focus change for a device/sequence, since
event handlers are daisy chained by default, it is mandatory to
chain up with meta_wayland_event_handler_chain_up_focus(), either
with the given surface, or passing NULL to let later handlers
unset their state.
- press/motion/release: Unified handlers for pointer/touch/stylus
input, they chain up like event handlers do.
- key: Key event handler, propagates like event handlers do.
- other: Fallthrough for other events (pad, scroll, ...), propagates
like event handlers do.
Since there is a variety of expected behaviors, and the possibility
of stacking for some of the existing Wayland "grabs", this provides
the mechanism for that to happen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
That would be the surface under the tool that is being currently used
on the device. This will be used by MetaWaylandSeat to implement the
default MetaWaylandEventInterface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3420>
