We don't actually need the host to be a container, so simply work on
actors saving us a few casts.
This'll simplify dropping ClutterContainer entirely later, and
StViewport/ShellWindowPreviewLayout will also need to be updated for the
new signatures
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3384>
Sticky keys configuration changes reset the pressed modifier state mask,
even though the XKB state might already match with the expected new
state. In those cases we can avoid the XKB state mask update completely.
This also fixes a crash at initialization with sticky keys toggled on,
since configuring the device a11y settings will trigger a XKB state
mask merely reassuring the initial state with no modifiers pressed,
while the connection between the ClutterSeat and the impl object has
not been set up yet. This crash was introduced by commit 00bb4190b
("backends/native: Drop device_native->seat_impl field").
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3392>
Tests that
* the window under the cursor has focus
* focus_default_window won't move the focus away from a previously
focused window even if the cursor is somewhere else
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
When the desktop is focused instead of a window we want to tell the core
about this to handle focus-mode mouse. This is handled by looking for
CLUTTER_LEAVE events where the newly focused window is NULL.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
Take a reference to the window to make sure the MetaFocusData->window
pointer is not pointing to a freed object.
Also make sure that the window that we want to focus is not currently
unmanaging.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
On X meta_window_handle_enter was called when the desktop window was
entered. On wayland the "desktop" is no window anymore. We still want to
inform the core that the desktop is focused, so it can unfocus windows
if focus-mode is mouse.
This commit prepares the core for handling a NULL windows to mean the
desktop.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
The following commits will make it possible to pass a NULL window to
display_handle_window_enter/leave to represent the cursor entering the
desktop. This means it can't be a method of the window class anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
If we have an existing focused window that may have focus, default focus
will leave the focus there. An unmanaging window for example must not
have focus and default focus will continue to select another window in
this case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
The layout manager takes the generic ClutterActor expand/align
properties into account. Everyone should already use those instead
of the custom layout/child properties, so removing them should have
little fallout, while making for a nice cleanup.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3382>
It tests various sub-surface corner cases. It would fail without the
previous fixes.
v2:
* Fix draw_descendant parameter formatting
* Make toplevel window fullscreen (Robert Mader)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
To make sure a new wl_subsurface created for the same wl_surface won't
inherit the position from the wl_subsurface being destroyed.
v2:
* Move into permanently_unmap_subsurface
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
Instead of duplicating the code in both.
v2:
* Rename helper to make it clear(er) that it permanently unmaps the
sub-surface
* Move transaction allocation & commit into the helper
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
wl_subsurface_place_above/below need to hook it up to the parent
surface's pending state, so that it gets picked up next time the parent
is committed.
v2:
* Adapt to wl_subsurface_destructor not resetting sub-surface position
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
This is simpler, and makes sure it's called only once for each surface
in the transaction as committed.
v2:
* Use array for surface states with placement ops (Jonas Ådahl)
v3:
* Use GPtrArray instead of GArray (Robert Mader)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
This is necessary to make sure the unmapped sub-surface is no longer
visible.
v2:
* Use META_IS_WAYLAND_SUBSURFACE (Jonas Ådahl)
* Use same sequence of assignments in both cases
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
meta_display_ping_window() does nothing when check-alive-timeout is set
to 0, but meta_window_check_alive_on_event() was relying on it to reset
the events_during_ping. Without this events_during_ping was just
counting up until the threshold was reached and the window was marked as
not alive, preventing further pointer events from being sent to the
window.
Fix this by not doing anything in meta_window_check_alive_on_event() if
check-alive-timeout is 0, similar to meta_display_ping_window().
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3142
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3367>
Locked modifiers should probably not have an effect on keybindings
while toggled. this is most relevant for modifiers that can be
either/both pressed or locked (e.g. Caps Lock key), if used in
keybindings.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3369>
This struct contains the pressed/latched/locked set of modifiers applying
to the event, and may be filled in by backends generating those events.
Other places where we forward modified key events, state may be normally
obtained from the original event.
Since this constructor is used in a variety of places, this commit
updates them all in one go.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3369>
If multiple sync events are send in the same dispatch, a further call to
wait_for_sync_event will get stuck. Fix this by keeping track of the
latest sync event serial in the display and always compare against that.
This also means sync event sequences must start at 0 and increase by 1.
The wayland-x11 interop test is the only one where that wasn't already
the case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3358>
Currently, we use cairo_region_t despite it being a thing wrapper around pixman_region_32
In order to push for a cairo-less and wayland only build in the future, replace
cairo_region_t with a thin wrapper that is almost a copy of the upstream cairo implementation
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3292>
Whenever a MetaWaylandTestClient exists without success the calling test
will fail. This fixes a bunch of cases where the test would get stuck
waiting for some event from the client when it already died and won't be
able to send the event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3348>
The test and dist CI jobs run wrap the meson calls in dbus-runner to
avoid setting up dbus servers and mocking services for every test but
the dbus-runner invocation from meson test didn't actually skip all the
setup.
This nested mocking also doesn't work because the system bus is assumed
to be the host system bus and not a mocked one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2618>
This means one can run meta-dbus-runner.py effectively mocking
everything relevant except logind itself, meaning one can run from a TTY
and get permission to mode set etc, while still mocking things like
gsd-color, colord, etc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2618>
Make CoglBuffer an abstract class and inherit the various Cogl*Buffer types from it.
As none of the subclasses is overriding the vtable functions, they were not turned into
vfuncs but plain function pointers in CoglBuffer.
We still use _cogl_buffer_initialize until we port the various params into actual construct-only
properties, similar to the previous commit for CoglTexture.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3193>
- Make Texture a parent GObject class and move the vtable funcs as vfuncs
instead of an interface as we would like to have dispose free the TextureLoader.
- Make the various texture sub-types inherit from it.
- Make all the sub-types constructors return a CoglTexture instead of their respective
specific type. As most of the times, the used functions accept a CoglTexture,
like all the GTK widgets constructors returning GtkWidget.
- Fix up the basics of gi-docgen for all these types.
- Remove CoglPrimitiveTexture as it is useless: It is just a texture underhood.
- Remove CoglMetaTexture: for the exact same reason as above.
- Switch various memory management functions to use g_ variant instead of the cogl_ one
Note we would still want to get rid of the _cogl_texture_init which is something
for the next commit
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3193>
The helper doesn't do anything that makes it worth
to be exposed as public API. End-users, such as GNOME Shell could have
an in-tree helper if they end up using it that much.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3086>
The shell might raise and make windows recent for another workspace when
an app gets activated on another workspace. Making the windows only
recent on the current workspace thus results in inconsistent focus when
another window of the same app is closed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3315>
There are existing extensions that implement desktop icons as
a combination of a GTK program and a small extension to make
the wayland window behave as if it was of type DESKTOP on X11.
That's quite painful, as it requires reimplementing WM behavior
that is already implemented in mutter itself (stacking, stickiness,
skip-taskbar, ...), as well as modifying gnome-shell to consider
the window in addition to "real" DESKTOP windows (workspace-switch
animations, ctrl-alt-tab, ...).
In addition to that, other extensions may also have special handling
of DESKTOP windows, and their code cannot easily be monkey-patched
to handle "alternative" desktop icons.
This whole game of whack-a-mole can easily be avoided by allowing
desktop-icons extensions to mark their desktop windows as DESKTOP,
so do just that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3305>
Assigning the corresponding stack layer of DESKTOP windows is
currently X11 specific, because there is no way for wayland
clients to set the DESKTOP window type.
This is about to change, so move the code to the generic layer
handling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3305>
Change the order of events to adhere to the Wayland specification for
wl_keyboard.enter, which mandates:
> The compositor must send the wl_keyboard.modifiers event after
> this event.
Mutter currently sends the modifiers event before the enter event,
which may break applications that require information about the focused
surface in order to properly handle the modifiers.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2231
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3341>
These functions ends-up calling gdk-pixbuf for loading textures/bitmaps
from a file and they don't seem to be used anywhere.
These changes are only useful with the following up commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3097>
Create a fake monitor region right of the right-most monitor and if a
horizontal barrier extends into that region, fail the barrier. Barriers
are aligned on the top/left edge of the pixel so the most natural
barrier of (e.g. 0-1024) is also wrong - it's one pixel into the next
monitor.
Check this for nonexisting screens on the right too to avoid clients
suddenly failing when multiple monitors are present.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3319>
Assuming two 1920x1080 screens next to each other: a horizontal barrier
starting at 1920 going east is always outside the left screen.
Assuming two 1920x1080 screens on top of each other: a vertical barrier
starting at 1080 going south is always outside the top screen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3319>
When running headless, only the invalid modifiers are advertised.
That breaks with the NVIDIA proprietary driver which then rejects the
buffers created with the invalid modifier, and that kills Xwayland,
meaning that running Xwayland on top of a mutter based compositor
headless is not possible.
The reason the modifiers are not sent is because AddFb2 is not supported
when running headless.
Other compositors (weston, wlroots) would still send the modifiers even
without AddFb2, and Xwayland works fine on those compositors when
running headless.
Remove the requirement for AddFb2 to send the modifiers, so that
Xwayland can work fine on top of mutter headless with the NVIDIA
proprietary driver.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3060
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3320>
`clutter_actor_destroy()` queues a stage update. Under certain
circumstances - i.e. when run in a very slow container - this can race
with the stage update triggered by the following
`clutter_virtual_input_device_notify_button()`, occasionally resulting in
`wait_stage_updated()` to return before the
`on_event_return_propagate()` callbacks ran, making the test fail.
This notably became more common since
8f27ebf87e (clutter/frame-clock: Start next update ASAP after idle period)
landed.
Thus wait for a stage update to happen after `clutter_actor_destroy()`,
preventing the race.
Fixes: f6da583d06 (tests/clutter/event-delivery: Add tests for implicit grabbing)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3332>
Instead of g_get_monotonic_time. This makes sure last_presentation_time_us
advances by refresh_interval_us.
Doesn't affect test results at this point, but it will with the next
commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3174>
Certain kernel drivers can take an unreasonably long time to
complete mode setting operations. That excessive CPU time is charged
to the process's rlimits which can lead to the process getting killed
if the thread is a real-time thread.
This commit inhibits real-time scheduling around mode setting
commits, since those commits are the ones currently presenting as
excessively slow.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3037
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3324>
At the moment if a thread is made real-time there's no going back,
it stays real-time for the duration of its life.
That's suboptimal because real-time threads are expected by RTKit to
have an rlimit on their CPU time and certain GPU drivers in the kernel
can exceed that CPU time during certain operations like DPMS off.
This commit adds two new ref counted functions:
meta_thread_{un,}inhibit_realtime_in_impl
that allow turning a thread real-time or normally scheduled. At the same
time, this commit stores the RTKit proxy as private data on the thread
so that it can be reused by the above apis.
A subsequent commit will use the new APIs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3324>
Most of the code writes "real-time" as "realtime" not "real_time".
The only exception is one function `request_real_time_scheduling`.
This commit changes that function for consistency.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3324>
If we queued a mode set, but didn't end up compositing all frames, we'll
have pending mode sets in a hash table waiting to be applied. If we
before all monitors again try to reconfigure things we should drop the
old pending mode sets and start fresh.
We already do this when we're doing so when generating views, but when
just unsetting modes, we didn't, so fix that.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2242612
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3318>
