A MetaEisViewport represents an absolute region backend by e.g. a
pointer device. There are two kinds: a standalone viewport, which
corresponds to a viewport that has no neighbours, and a non-standalone,
which represents a region of a global coordinate space.
The reason for having non-standalone viewports is to allow to mirror the
logical monitor layout of a desktop, while the standalone are meant to
represent things that are not part of the logical monitor layout.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3228>
How EIS will be used depends on its context, meaning we'll have multiple
EIS contexts that expose different things. To prepare for this remove
the global socket since that won't work with multiple contexts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3228>
This fixes a compiler warning:
```
src/x11/events.c:523:1: warning: ‘get_event_name’ defined but not used [-Wunused-function]
523 | get_event_name (MetaX11Display *x11_display,
| ^~~~~~~~~~~~~~
```
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3223>
This used to be the behavior, until commit 5d35138df0 changed the meaning
of the return value of MetaCursorRendererClass::update_cursor(). This
made the user of pure-overlay cursors (singular, MetaWaylandTabletTool)
miss their overlays.
Change the return value, so that it matches the desired behavior of
a backend-less overlay-only cursor renderer.
Fixes: 5d35138df0 ("cursor-renderer: Make 'handled_by_backend' state 'needs_overlay'")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3218>
We react on changes to has_hw_cursor, but always try to inhibit if
there is no cursor sprite. While this looks like a reasonable optimization
with the typical situation of one cursor renderer, it may fall into
inhibiting twice without knowing to unwind, e.g.:
1. has_hw_cursor: TRUE, cursor_sprite: !=NULL -> inhibit
2. has_hw_cursor: FALSE, cursor_sprite: NULL -> inhibit
3. has_hw_cursor: TRUE, cursor_sprite: !=NULL -> uninhibit, but once
And this may also result in the CLUTTER_PAINT_FLAG_NO_CURSORS flag
staying on for Tablet cursors, that (so far) always use overlay paths.
This results in invisible tablet cursors after using the mouse at
least once.
Fixes: e52641c4b6 ("cursor-renderer/native: Replace HW cursor with KMS cursor manager")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3218>
Under strange timings, the GTK frames client may implicitly queue
relayouts that end up disagreeing with the latest frame size as
given by Mutter, this results in GTK calling XResizeWindow, and
Mutter plain out ignoring the resulting XConfigureRequestEvent
received.
This however makes GTK think there's pending resize operations,
so at the next resize it will freeze the window, until enough
resizes happened to thaw it again. This is seen as temporary
loss of frame-sync ness (e.g. frozen frame, and other weird
behavior).
In order to make GTK happy and balanced, reply to this
XConfigureRequest, even if just to ignore it in a more polite
way (we simply re-apply the size Mutter thinks the frame should
have, not GTK), this results in the right amount of
ConfigureNotify received on the frames client side, and the
surface to be thawed more timely, while enforcing the size as
managed by Mutter.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2837
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3189>
This is meant for compatibility purposes with the shell extensions
avoiding to break a bunch of them in the last minute and we would
drop it in the GNOME 46 release.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3128>
Currently, Meta/Cogl/Clutter makes use of cairo_rectangle_int_t despite
the existance of MetaRectangle.
In order to make MetaRectangle usable in Cogl/Clutter as well, Mtk would
provide such base types that are shared across the various private
libraries
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3128>
Dropped obsolete Free Software Foundation address pointing
to the FSF website instead as suggested by
https://www.gnu.org/licenses/gpl-howto.html
keeping intact the important part of the historical notice
as requested by the license.
Resolving rpmlint reported issue E: incorrect-fsf-address.
Signed-off-by: Sandro Bonazzola <sbonazzo@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3155>
This used to be the case before the refactor at commit 43cee4b6b6,
use_clipped_redraw would be unset before the larger check if has_buffer_age
was set, but clutter_damage_history_is_age_valid() was FALSE. This got
replaced by a check just on the latter, which will also be FALSE if
has_buffer_age is not present.
We have other means to achieve clipped redraws, so this slight change
culled all of them.
Fixes: 43cee4b6b6 ("stage-impl: Do clipped redraws when drawing offscreen")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2771
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3221>
This changes how state is tracked by introducing an explicit state. We
need this since we use asynchronous calls to the out of process
component that handles actual inhibitation, including idleness.
This means if inhibitations changes rapidly, we might end up with an
incorrect state if we e.g. try to uninhibit while we're currently trying
to inhibit.
This is done by adding a state variable that accounts for the pending
state, as well as the active state, with a function that looks at the
current conditions to derive what state we should be in, and what state
we are in, to decide what the next action should be.
For example, if we're trying to inhibit, but now wants to uninhibit,
we'll wait for the inhibit call to complete, recheck what we want, which
would result in an async uninhibit call being made.
Fixes: 388b534062 ("wayland: Implement idle inhibit protocol")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3219>
This fixes the following
1. Minimize window; minimize animation starts
2. Do something that immediately destroys the animated actor (e.g. terminate)
3. This triggered the timeline of the animation to emit a "stopped"
signal while all transitions of the actor were destroyed
Previously we'd implicitly animate the scale again (set_scale(..)) which
created a new transition The hash table iterator didn't like this and
abort():ed
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3213>
The 'suspend state' is meant to track whether a window is likely to be
visible any time soon. The hueristics for this are as follows:
* If a window is hidden, it will enter the 'hidden' state.
* If a window is visible, and unobscured, it will enter the 'active'
state.
* If a window is visible, but obscured by another window, it will enter
the 'hidden' state.
* If there is a mapped clone of a window, it will enter the 'active'
state.
* If the window has been in the 'hidden' state for 3 seconds, it will
enter the 'suspended' state.
This will eventually be communicated to Wayland clients so that they can
change their behaviour to e.g. save power.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3019>
Previously it transformed a physical CRTC coordinate to a logical desktop
coordinate. But current and future users of the function all require
conversion from logical coordinates to physical coordinates. We would have
had to always invert the transform parameter which is a waste of time when
we can instead just invert the function behaviour.
We also simplify the parameters to show both the point coordinate and the
area dimensions are potentially transformed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3180>
When creating a new stream, check if the preferred format is
different from the default (COGL_PIXEL_FORMAT_BGRX_8888). If
it is, then also include it in the list of potential formats
for the stream.
COGL_PIXEL_FORMAT_BGRX_8888 is still passed around as it's
both the default, and the fallback for when things go wrong.
When creating buffers, use the negotiated SPA format instead
of a hardcoded value. We leave it to PipeWire to figure out
what's the best format, since clients may not support the
preferred format of the stream.
Due to how chaotic things got, this commit also cleans up
the create_pipewire_stream() to use an auxiliary array of
SPA formats, which is then iterated on in order to generate
the format pods.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3175>
In future commits, we will want to create DMA-BUFs with pixel
formats other than COGL_PIXEL_FORMAT_BGRX_8888. In preparation
for that, let's start passing a new pixel format parameter to
this function, and the corresponding winsys vfunc.
All callers of this function pass COGL_PIXEL_FORMAT_BGRX_8888
for now. Next commits will change that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3175>
Freeing the window opaque region rather than the frame one when was
leaking the frame opaque region and wrongly setting the window opaque
region to NULL.
Fixes: 82b2b7688 ("core: Add infrastructure to keep window frames' opaque regions")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3188>
This is something the compositor could now track by itself, instead of
being pushed through events. It also makes more sense to do this directly
when the grabbing conditions change, as opposed to the next event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3185>
Except for the tests that launches `mutter`, use a custom shell
implementation. It's roughly a copy of default.c with some cleanups on
top. A custom shell allows for a bit more freedom when doing testy
things.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3185>
This splits culling into two different phases to move unobscured region
culling to pre-paint to fix#2680. This is needed as direct scanout
skips the paint phase altogether, but the pre-paint phase always runs as
it's used for selecting the direct scanout surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3127>
With the ClutterEvent subtype structs sealed, this remains the only useful
struct type that is now usable on the Javascript side. Make all
ClutterActorClass event vmethods use ClutterEvent, and update all users
to this change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3163>
In test situations we sometimes do not create a libinput context, so
our check on dispose to see if we need closing the input thread is off
if META_SEAT_NATIVE_FLAG_NO_LIBINPUT was provided.
Check the input thread existing instead, since that is the thing we
want to undo here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Move the string construction bits in the event logging happening in
MetaSeatImpl to a clutter_event_describe() call, so that it has more
freedom in fiddling with ClutterEvent internals, and may be potentially
reused in other places.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Add methods, and change the API of some rarely used methods, in order
to make all event info currently held/necessary accessible through
ClutterEvent getters, instead of direct field access.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Since the full decomposed modifier state is unused, and only the
effective modifier mask matters to users, the new constructors take
just this effective modifier mask. This means this helper went
unused in the port to the new constructors, so can be now dropped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Since the full decomposed modifier state is unused, and only the
effective modifier mask matters to users, the new constructors take
just this effective modifier mask. This means this helper went
unused in the port to the new constructors, so can be now dropped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
This is done from the backend X11 connection, but needs directing at times
from the frontend X11 connection. Commit 5a8509f895 added a XEvent
argument presumably for possible future expansions that did never come.
Since this function is nothing about events, drop the XEvent argument and
make the name a little bit more ad-hoc (according to what it does, at
least).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Despite the attempt to make this a generic interface, this was
pretty much used only by the X11 backend, and now it ported away
from it.
This now stands unused and may be removed, in favor of backends
each creating and injecting events as they please.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
This is about the only reason now to go through the ClutterBackend
translate_event vmethod. We can do that directly, and stop requiring the
generic vmethod that is actually just used for X11 events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
There's no need for an XEvent filter, since this is already code close enough
to MetaBackendX11 XEvent handling and always required anyways. Make the a11y
configuration checks happen directly from MetaBackendX11 event handling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
We are pretty much guaranteed that the first event will be handled after
the cogl renderer has been set up. We can avoid the loop through
ClutterBackend vmethods and X11 event filters, and call this directly
from the code that is already close to the MetaClutterBackendX11.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Stop taking a ClutterEvent and pass the essentials here (x/y/evtime),
we don't have a ClutterEvent handy in all places that we call this
API, and it feels awkward to create one just for calling this vmethod.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
It is a bit backwards that events contain information about
the stage they are being handled by. It makes more sense to
specify in the ClutterEvent handling entrypoint the stage
that will handle the event.
As a first step, add this ClutterStage argument, even though
the information is still carried through the event in order to
keep satisfying calls to the getter function.
This entrypoint has been also renamed to clutter_stage_handle_event(),
so that its ownership/namespace is clearer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Nowadays, all our MapNotify event handling happens already prior to
the MetaCompositorX11 handling of XEvents. It does not make sense to
channel these events again through the backend, at best all it could
lead to is double handling of the same events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>