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>
These "features" are somewhat less featured, it's becoming too ugly
to handle all of them with a single API call. The clear outlier are
buttons, so move them to a separate function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3005>
queue_update() in a previous iteration was called in two situations:
* A page flip was already pending, meaning if we would commit an
update, it'd fail with EBUSY.
* A update was marked as "always-defer" meaning it should only be
processed from the deadline callback (would there be one). These were
used for cursor-only updates.
In the latter, we had to arm the deadline timer when queuing a new
update, if it wasn't armed already, while in the former, we would
currently idle, waiting for the page flip callback. At that callback
would the deadline timer be re-armed again.
Since we're only handling the former now, we'll never need to arm the
timer again, so remove code doing so. The code removed were never
actually executed anymore, after the "always-defer" flag on updates was
removed.
Fixes: 27ed069766 ("kms/impl-device: Add deadline based KMS commit scheduling")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2940
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3150>
Primary plane updates were forgetting to do this in OnscreenNative, but
rather than do it for each post there we should simply do it for each
post.
This fixes cursor stutter in the fallback path (not using deadline timers)
where needs_flush_crtcs would remain populated but CRTC_NEEDS_FLUSH would
never be emitted, because handle_flush hadn't been called for the last
post.
This is safe as the current use of scheduled flushing is only for cursor
updates, and since cursor updates happen on the same thread as processing,
and due to the fact that we always use the most up to date cursor position
when flushing, we never risk leaving an old cursor state unflushed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3138>
Implement importing of multi-plane formats. For now, only support
importing planes individually using "sub-formats". This is the most
commonly driver-supported approach in the moment, used by other
Wayland compositors as well.
In the future we will additionally want to support importing the formats
directly and let the drivers handle conversion internally.
Co-Authored-By: Robert Mader <robert.mader@collabora.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2191>
So they can be derived from the DRM format as well.
While updating the users, ensure we don't announce support for
DRM formats in zwp_linux_dmabuf_v1 if the MetaMultiTextureFormat is
INVALID. This will be used for YUV subformats in following commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2191>
To be able to later support more complex YUV formats, we need to make
sure that MetaShapedTexture (the one who will actually render the
texture) can use the MetaMultiTexture class.
Co-Authored-By: Robert Mader <robert.mader@collabora.com>
Co-Authored-By: Daniel van Vugt <daniel.van.vugt@canonical.com>
Co-Authored-By: Sebastian Wick <sebastian.wick@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2191>
