In various public APIs, Clutter used to return a PangoDirection
while we have a text direction enum defined in Clutter.
This allows us to drop pango dependency from meta making it specific
to cogl-pango & clutter
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3531>
This is a step in cleaning up the Clutter context management. By making
it a GObject it's easier to add e.g. properties and features that helps
with introspection.
For now, this means the context creation is changed to go via a
"constructor" (clutter_create_context()). This is so that the global
context singleton can be mantained outsid of ClutterContext, until it
can be removed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2016>
The intention for ClutterContext is to be more or less the MetaContext
or CoglContext equivalent. Lets rename the type so that it becomes more
consistent with the other similar types.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2016>
There are no 'features' left, the last one, GLSL shader support, was
moved to Cogl.
This also move the Cogl context creation to a more sensible place, as it
was hidden away in the feature initialization.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2015>
There's a bunch of crashes right now where the assertions in
clutter_actor_set_mapped() after calling the map/unmap() vfuncs are
failing. The only way this can happen is by re-entering
clutter_actor_set_mapped() during the map/unmap recursion.
The reason for those crashes is that the shell hides/shows some actors
in response to crossing events and key-focus changes. These in turn get
triggered by the newly introduced ungrabbing of ClutterGrabs when an
actor gets unmapped, which triggers GRAB_NOTIFY crossing events and
key-focus changes.
Since these situations are hardly avoidable (it's a valid use-case to
hide/show something in response to a crossing/key-focus event), catch
the set_mapped() call early while we reenter the mapping machinery and
log a warning instead of crashing.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3165
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2299>
This changes the setup phase of clutter to not be result of calling an
init function that sets up a few global singletons, via global singleton
setup vfuncs.
The way it worked was that mutter first did some initial setup
(connecting to the X11 server), then set a "custom backend" setup vfunc
global, before calling clutter_init().
During the clutter_init() call, the context and backend was setup by
calling the global singleton getters, which implicitly created the
backend and context on-demand.
This has now changed to mutter explicitly creating a `ClutterContext`
(which is actually a `ClutterMainContext`, but with the name shortened to
be consistent with `CoglContext` and `MetaContext`), calling it with a
backend constructor vfunc and user data pointer.
This function now explicitly creates the backend, without having to go
via the previously set global vfunc.
This changes the behavior of some "get_default()" like functions, which
will now fail if called after mutter has shut down, as when it does so,
it now destroys the backends and contexts, not only its own, but the
clutter ones too.
The "ownership" of the clutter backend is also moved to
`ClutterContext`, and MetaBackend is changed to fetch it via the clutter
context.
This also removed the unused option parsing that existed in clutter.
In some places, NULL checks for fetching the clutter context, or
backend, and fetching the cogl context from the clutter backend, had to
be added.
The reason for this is that some code that handles EGL contexts attempts
to restore the cogl EGL context tracking so that the right EGL context
is used by cogl the next time. This makes no sense to do before Cogl and
Clutter are even initialized, which was the case. It wasn't noticed
because the relevant singletons were initialized on demand via their
"getters".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
Regarding the sequence = 0 fallback: in some cases (moving a cursor
plane on atomic amdgpu) we get sequence = 0 in the page flip callback.
This seems like an amdgpu bug, so work around it by assuming a sequence
delta of 1 (it is equal to 1 because of the sequence != 0 check above).
Sequence can also legitimately be 0 if we're lucky during the 32-bit
overflow, in which case assuming a delta of 1 will give more or less
reasonable values on this and next presentation, after which it'll be
back to normal.
Sequence is also 0 on mode set fallback and when running nested, in
which case assuming a delta of 1 every frame is the best we can do.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
When a transfer request is done to the MetaSelectionSourceRemote source,
it's translated to a SelectionTransfer signal, which the remote desktop
server is supposed to respond to with SelectionWrite.
A timeout (set to 15 seconds) is added to handle too long timeouts,
which cancels the transfer request.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1552>
Don't mode set each CRTC in separate KMS updates, as reconfiguring one
CRTC might cause other CRTCs to be implicitly reset thus as well,
causing KMS return EBUSY if using atomic modesetting.
Prepare for this by compositing each CRTC first including adding steps
to the KMS update, but wait until all views has rendered at least once
before posting the initial update. After this each CRTC is posted
separately.
Using EGLStreams instead of normal page flipping seems to fail when
doing this though, so handle that the old way for the EGLStream case,
i.e. eglSwapBuffers() -> mode set with dumb buffer -> eglStream
"acquire" (resulting in page flip under the hood).
For this we also introduce a new error code so that we don't use client
buffers when doing mode sets, which could accidentally configure the
CRTC in a way that is incompatible with the primary plane buffers.
Do the same also when we're in power save mode, to only have one special
case path for this scenario in the regular swap-buffer path.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Culling paint volumes don't give this level of detail anymore, and in
fact knowing whether it was partially or fully in was only being used
in a debug path. For the purposes of culling, it doesn't matter if a
given actor is partially or completely inside the frustum; either way,
it must be painted.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
The timestamp sent with _NET_WM_FRAME_DRAWN should be in "high
resolution X server timestamps", meaning they should have the same scope
as the built in X11 32 bit unsigned integer timestamps, i.e. overflow at
the same time.
This was not done correctly when mutter had determined the X server used
the monotonic clock, where it'd just forward the monotonic clock,
confusing any client using _NET_WM_FRAME_DRAWN and friends.
Fix this by 1) splitting the timestamp conversiot into an X11 case and a
display server case, where the display server case simply clamps the
monotonic clock, as it is assumed Xwayland is always usign the monotonic
clock, and 2) if we're a X11 compositing manager, if the X server is
using the monotonic clock, apply the same semantics as the display
server case and always just clamp, or if not, calculate the offset every
10 seconds, and offset the monotonic clock timestamp with the calculated
X server timestamp offset.
This fixes an issue that would occur if mutter (or rather GNOME Shell)
would have been started before a X11 timestamp overflow, after the
overflow happened. In this case, GTK3 clients would get unclamped
timestamps, and get very confused, resulting in frames queued several
weeks into the future.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1494
CoglMatrix already is a typedef to graphene_matrix_t. This commit
simply drops the CoglMatrix type, and align parameters. There is
no functional change here, it's simply a find-and-replace commit.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Graphene provides skewing as part of graphene_matrix_t API, and it'll
be easier for the transition to just expose similar API surfaces.
Move the matrix skew methods to CoglMatrix.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
On X11 we won't always receive cursor positions, as some other client
might have grabbed the pointer (e.g. for implementing a popup menu). To
make screen casting show a somewhat correct cursor position, we need to
actively poll the X server about the current cursor position.
We only really want to do this when screen casting or taking a
screenshot, so add an API that forces the cursor tracker to track the
cursor position.
On the native backend this is a no-op as we by default always track the
cursor position anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1391
Replace the default master clock with multiple frame clocks, each
driving its own stage view. As each stage view represents one CRTC, this
means we draw each CRTC with its own designated frame clock,
disconnected from all the others.
For example this means we when using the native backend will never need
to wait for one monitor to vsync before painting another, so e.g. having
a 144 Hz monitor next to a 60 Hz monitor, things including both Wayland
and X11 applications and shell UI will be able to render at the
corresponding monitor refresh rate.
This also changes a warning about missed frames when sending
_NETWM_FRAME_TIMINGS messages to a debug log entry, as it's expected
that we'll start missing frames e.g. when a X11 window (via Xwayland) is
exclusively within a stage view that was not painted, while another one
was, still increasing the global frame clock.
Addititonally, this also requires the X11 window actor to schedule
timeouts for _NET_WM_FRAME_DRAWN/_NET_WM_FRAME_TIMINGS event emitting,
if the actor wasn't on any stage views, as now we'll only get the frame
callbacks on actors when they actually were painted, while in the past,
we'd invoke that vfunc when anything was painted.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/903
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The mutexes was used by ClutterTexture's async upload and to match GDK's
mutexes on X11. GDK's X11 connection does not share anything with
Clutter's, we don't have the Gdk Clutter backend left, and we have
already removed ClutterTexture, so lets remove these mutexes as well.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
We had time unit conversion helpers (e.g. us2ms(), ns2us(), etc) in
multiple places. Clean that up by moving them all to a common file. That
file is clutter-private.h, as it's accessible by both from clutter/ and
src/.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The CLUTTER_ACTOR_IN_REPARENT and the CLUTTER_IN_REPARENT flag are never
set and the logic for skipping unmap, unrealize and the emission of the
"parent-set" signal during reparents has been solved differently by
leaving out the CHECK_STATE and EMIT_PARENT_SET flags when calling
add_child_internal() and remove_child_internal().
The only place where those REPARENT flags are theoretically still useful
is in the clutter_actor_verify_map_state() debugging function, but that
is never called during reparent anyway, so simply leave the comment
regarding reparent there.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1228
The stage window handled the redraw clip in a global manner; this would
interfere if we want to paint views individually as it'd mean
intersecting views (i.e. mirrored monitors) would loose the redraw clip
once the first view was painted. It also is awkward to have a global
state for something that is built up before redrawing, and only really
valid during paint, due to buffer damage history.
This commits removes all redraw clip management from the stage window,
moving it all into the stage views. When a redraw clip is added to the
stage, every affected view will get the same redraw clip added to it,
and eventually when painted, the stage window (ClutterStageCogl) will
retrieve the redraw clip for each view as it repaints them.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
