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>
In future commits, we want to be able to handle more complex textures,
such as video frames which are encoded in a YUV-pixel format and have
multiple planes (which each map to a separate texture).
To accomplish this, we introduce a new object `MetaMultiTexture`: this
object can deal with more complex formats by handling multiple
`CoglTexture`s.
It supports shaders for pixel format conversion from YUV to RGBA, as
well as blending. While custom bleding is currently only required for
YUV formats, we also implement it for RGB ones. This allows us to
simplify code in other places and will be needed in the future once
we want to support blending between different color spaces.
Co-Authored-By: Robert Mader <robert.mader@collabora.com>
Co-Authored-By: Sebastian Wick <sebastian.wick@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2191>
This adds the actual input capturing rerouting that takes events and
first hands them to the input capture session, would it be active.
Events are right now not actually processed in any way, but will
eventually be passed to a libei client using libeis.
A key binding for allowing cancelling the capture session is added
(defaults to <Super><Shift>Escape) to avoid getting stuck in case the client
doesn't even terminate the session.
The added test case makes sure that the pointer moves again after
pressing the keybinding.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
A sticky barrier means that a pointer in motion intersecting a barrier
doesn't move once having hit it. The intention with this is to allow an
input capture clients to continue a motion once a barrier is hit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
Commit 7e9d9c7eb9 added new API to replace GTK for accelerator
parsing.
Unfortunately there is another case in gnome-shell, where we have
to get the label from the logical binding name rather than the
modifier+keysym combination.
Add another small method to cover that use case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2899>
After !2489, the active workspace's MRU list is now used to pick
the next focus window instead of the stack order.
This list is currently only updated on focus, which can lead to
surprising behavior when closing a window after activating its
ShellApp in the shell.
That is because raising a window (as part of shell_app_activate())
will only change the stacking order, so when closing the active
app window, the focus will switch to whatever had focus before the
app was activated, not the app's next window.
In order to allow gnome-shell to address this, add a new
raise_and_make_recent() method that also adjust the MRU order.
https://gitlab.gnome.org/GNOME/mutter/-/issues/2540
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2866>
This API will be used by GNOME Shell to handle X11 events
in the relevant places, as a substitute to gdk_window_add_filter().
It is ATM still a bit ironic, since the Mutter X11 event handler
is itself a GdkFilterFunc, but it may move away from that eventually.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2779>
This is a public API change. Add device/sequence parameters to this
operation, so that window dragging and resizing can stick to one
set of pointing events of them all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
The final effect of this boolean can now be expressed through the
META_GRAB_OP_WINDOW_FLAG_UNCONSTRAINED flag to MetaGrabOp. Use that
in the relevant places, and drop the argument.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Leave meta_window_begin_grab_op() as the only public API to initiate
a display grab. There's no longer grab operations that don't attain
windows, and ending these grabs usually happen through user interaction
when the right circumstances happen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Currently, it is thought out to be called with META_GRAB_OP_KEYBOARD*
grab op parameters. Make it more generic so it can also be called for
pointer operations (avoiding pointer warping in that situation).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
The frame_action boolean is only used by constraints.c code, in order to
determine whether a moving window should be able to move past the top
bar or not.
We can avoid the special casing by passing this information as a
META_GRAB_OP_WINDOW_FLAG_UNCONSTRAINED flag passed with the grab op.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Make this public API check just return a boolean about whether
there is an existing grab, instead of exposing MetaGrabOp.
It is desirable to avoid exposing details like
META_GRAB_OP_WAYLAND_POPUP, so that MetaDisplay and wayland
grabs can port to ClutterGrab at their own pace, but also
this further information is unused.
This is likely to be temporary API anyways, after both
MetaDisplay and wayland grabs port to Clutter, it will be
possible to check the ClutterStage for all of them.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Some tests expect warnings to be logged, and handle that using
g_test_expect_message(). However, if debug topics are enabled, this
causes g_logv() to expect expected messages to also contain entries with
the debug level 'message' or higher to be listed in the expected message
list. Since meta_topic() always logged using g_message(), enabling debug
topics caused any test that used g_test_expect_message() and had debug
logging somewhere along the code path to fail.
Fix this by changing the log level of meta_topic() to 'debug' if we're
in a test. This doesn't mean they won't be visible, they still will
since debug log entries are printed by default during testing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2800>
Commit bf84b24 created meta-enums.h but it's pretty empty so far, the
vast majority of enum definitions is still in common.h.
Move the Meta enum definitions to meta-enums.h as one would expect them
to be found.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2467>
Things like meta_compositor_destroy() and meta_compositor_add_window()
isn't intended to be used externally, and if they was, things would
probably fall apart rather quickly.
MetaCompositor also isn't introspected, meaning things that technically
belong to the compositing parts isn't easily available via some object,
but much take detours via other objects like MetaDisplay.
So move the API intended for internal usage to compositor-private.h, and
leave API that is meant to be expose in the public compositor.h.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
The "later" API is used to queue actions in relation to compositing,
thus is owned by the MetaCompositor instance. Make users of this
functionality get MetaLaters instance from the compositor, and stop
using the global meta_later() API.
display: Use non-singleton MetaLater API
tests: Use non-singleton MetaLater API
meta/common: Make docs refer to context aware MetaLater API
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
As elsewhere, make sure objects that need to have a ownership up to the
context, and use this ownership chain to find relevant components, such
as the backend or the Wayland compositor object instance.
wayland/data-device: Hook up data devices to seats
They are tied to a seat - make that connection in struct fields too, so
that related objects can get to the context via it.
wayland: Don't get Wayland compositor via singleton getter
This means via the ownership chain or equivalent.
xwayland: Hook up manager to Wayland compositor
Same applies to the drag-n-drop struct.
xwayland: Make X11 event handling compositor instance aware
This avoids finding it via singletons in the callee.
xwayland: Don't get Wayland compositor from singleton
xwayland: Pass manager when handling dnd event
window/xwayland: Don't get Wayland compositor from singleton
xwayland/grab-keyboard: Don't get backend from singleton
xwayland: Don't get backend from singleton
wayland: Always get the backend from the context
This means traveling up the ownership chain or equivalent when
necessary.
wayland: Hook up data devices, offers and sources to the compositor
This allows tying them to a context without going through any
singletons.
wayland: Don't get display from singleton
xwayland: Don't get display from singleton
tablet: Don't get display from singleton
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
While already cleaning up API, if this should ever be more non-static
than a constant, it's better if its a function on the monitor manager
instance than something static.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
