As with CRTC GAMMA_LUT, we're moving towards making the entity managing
KMS updates aware if there are any changes to be made, and whether KMS
updates are actually needed or not, and for privacy screen changes, this
means we need to communicate whether the privacy screen state is valid
or not. This allows the caller to create any needed MetaKmsUpdate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2814>
We're moving towards making the entity managing KMS updates aware if
there are any changes to be made, and whether KMS updates are actually
needed or not, and for GAMMA_LUT changes, this means we need to
communicate whether the GAMMA_LUT state is valid or not. This allows the
caller to create any needed MetaKmsUpdate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2814>
We may fall through these paths on --nested too, resulting in us poking the
wrong internals from the wrong MetaRenderer subclass. Fixes launching of
clients using wl_drm in --nested.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2818>
Running each stacking test as a separate installed-test is analogous to
what was done for build-time tests in c6d1cf4a (!442) and should make it
easier to track regressions, by being able to see whether a regression
is specific to one .metatest script or applies to more than one.
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2773>
While completely untested, at least this makes it work "in theory"
again. Before it'd listen to signals on the stage, but have an incorrect
type signature to handle the test paint procedures, meaning it'd
probably crash or cause memory corruptions.
What was needed was a signal which in the callback the test could call
some cogl functions to paint on the framebuffer. While there is no such
signal on the stage, and the ClutterActor::paint signal (which they
probably used in the past) is long gone, lets add a "test actor" that is
just a wrapper that adds that paint signal with a paint context.
The tests that need it are changed to add this actor to the stage, and
to listen to the paint signal on the actor instead of incorrectly
listening on stage signals.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2807>
At least indirectly, this is set as object qdata while the
window drag is ongoing, and reset/reconstructed if needed.
Consequently, this edge data does not need to be stored in
the MetaDisplay struct anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Even though the data is still stored in the display, add a "high
level" meta_window_drag_update_edges() call, so that the cached
edges may be updated while a window drag operation is ongoing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
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>
Since MetaWindowDrag took a lot of this code to handle window drags
internally with less interactions with the rest of the stack, this
code in display/window/keybindings is unused.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Flip the switch in using MetaWindowDrag, leaving display grab
ops and a bunch other code unused. Some places checked the grab op
and/or window in complex ways, others just checked for grab existence
and should now look for clutter ones, and others already were already
doing this in addition.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This helper object (and the whole window drag operation) will be
requested to the compositor instead of created directly, and only
one of those can exist at a time, so the compositor will also
safeguard that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Since SSD X11 windows require synchronization between frame and client
windows on resizes, updates do not always happen immediately but in
control of external factors (i.e. when both windows become to have
a coherent size).
This method will be used to update the window position between
resize/sync operations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This compositor-side object will single-handedly drive a window
drag operation. Currently, this largely copies meta_display_begin_grab_op
and meta_display_end_grab_op, except grabbing is done through a
ClutterGrab instead of direct meta_backend_grab_device() calls. This
also means that the switch from passive to active keyboard grabs is
handled differently.
Currently, this object is dormant. It requires moving more code from
other places to become a fully functional replacement.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
We only allow partial grabs in the case of a keyboard-type MetaGrabOp
happening while the pointer cannot be grabbed. In that case, it's not
a big stretch to unconditionally ungrab the pointer device at the time
of undoing the grab, as it will be always ineffective (not even implicit
grabs on frame windows can happen now, inside Mutter).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This is no longer necessary, since the SSD frames are no longer
part of Mutter process, so it is not the MetaX11Display connection
which holds the implicit grab when a mouse button is pressed over
a window frame (say, to start a drag).
As the SSD frames client communicates the same way than CSD windows
for window operations, it is also expected to undo its implicit
grab before requesting a window move/resize operation.
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>
Now that it is called from a single place, there's a few arguments
that are unnecessary:
- button and modifiers are unused
- already_grabbed was originally added to handle grab transitions between
window menus (GtkMenus, back in the day) with display grabs. It's no
longer necessary now
- frame_action can be passed through the META_GRAB_OP_WINDOW_FLAG UNCONSTRAINED
flag
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>
There is no longer reason to call meta_display_begin_grab_op() except
for window grab operations, and meta_window_begin_grab_op() is a
perfectly fine entry point for all window grab operations.
Move away from meta_display_begin_grab_op().
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>
Unlike the comment suggests, this piece of event handling manages
the ungrabbing of a window on button press in the following 2
conditions:
- If a keyboard grab operation was triggered, the window does
additionally follow the pointer, and first button press ends
the grab.
- If a button-press grab is ongoing on the window, but more buttons
are pressed.
We can simplify this to just happen every time a button press event
is received while a window grab op is ongoing. The only case where
this might diverge a bit is same button presses from different
pointer devices, and it's not a big stretch to also undo the grab
in that situation.
This also happens to make the "button" argument in
meta_display_begin_grab_op() completely unused.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
