The monitors settings such as the privacy screen property is propagated
to the monitors via kms updates, however during initialization and
on monitors changes, we end up clearing the pending KMS updates because
such settings are added to the queue before the backend has fully
initialized the monitors, and this may lead to discarding all the
pending updates, including the one we've just planned.
To avoid this, move settings applications after we've both initialized
the backend and notified it about changes.
Also avoid to try set the settings during actual initialization, but
delay that after post-init.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2372>
Prior to 'compositor: Destroy actors when unmanaging', window actors
were destroyed when the compositor object was destroyed, long after the
windows were unmanaged, however, when this instead changed to happen
when unmanaging, with the original goal to avoid having these actors try
to interact with the disposed MetaCompositor instance, it caused an
issue where window actors would be indirectly destroyed as a side effect
of their parents being destroyed, which caused some fallout in the logic
handling window-close animation tracking, which relies on
meta_window_actor_queue_destroy() being called before a window actor is
actually destroyed.
Fix this by unmanaging windows before unmanaging the compositor.
From an X11 point of view, this should be harmless, since all it really
do is call XCompositeUnredirectSubwindows().
For the native backend and the common behavior, all unmanaging the
compositor instance does is destroy clutter actors, so doing so after
window actors were already cleaned up should not be a problem, as this
was the case before too.
Fixes: 35ac3a096d
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5330
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2403>
Quoting Ray Strode:
we don't expose a way to explicitly save the session in gnome anymore
afaik, and I don't think it's going to show on log out because
I believe we use the FORCE flag from the log out dialog.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2370>
'kms/impl-device/simple: Get the buffer handle from MetaDrmBuffer'
changed how fb ids are generated, but it only made it fully work with
atomic mode setting. For legacy/simple mode setting, it only handled the
primary plane buffer, not the hardware cursor.
Fix this by making sure the fb id is generated also in the legacy mode
setting case.
Fixes: ea39142da2
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2250
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2397>
When an X11 window becomes an all-workspace window its `workspace` is
set to NULL before `meta_window_x11_current_workspace_changed()` is
called. The latter then checks for `workspace` being NULL (which also
happens when unmanaging) and then returns early. So this does not update
`_NET_WM_DESKTOP` to 0xFFFFFFFF. Instead it remains at the workspace the
window was on before. This was causing programs like `wmctrl` to switch
to this old workspace when activating such a window.
Fix this by checking if the window is unmanaging instead.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2242
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2387>
Simply signal preedit string changes from/to NULL once, in order
to avoid unwanted activity in the client side. We do still need to
send the preedit once each .done event, if there is one, in order
to behave according to the protocol when it matters the most.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2395>
With the unthrottled input emission, we ended up often getting the
cursor updates long before any damage had been posted, meaning that if
you moved around the mouse pointer where the mouse had a high enough
refresh rate, we'd effectively stall the screen cast stream by only
sending cursor updates and nothing else.
Fix this by scheduling an update when we get a cursor update, then
sending a cursor-only frame after any damage and relayout has been
processed, but only if there is no queued damage that will cause an
actual repaint.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2393>
This handle is used by the legacy KMS API; lets avoid having to have GBM
specific code where this is done by letting the MetaDrmBuffer API, that
already has this information, expose it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2275>
We'd put the message in a variable called `message`. If something passed
to meta_topic() was called `message`, it'd end up being `NULL` in the
log entry. Avoid this by making the local message variable a bit more
"on topic".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2391>
Unfortunately we cannot do this generically since the target of the
button/touch press does matter, e.g. tapping on the OSK, or clicking
the IBus candidates window. These situations should not trigger a
reset.
So be more selective about the situations where button/touch presses
trigger an IM reset, in the case of ClutterText these are still clicks
inside the actor, for Wayland's text-input it is when clicking the
surface that has text_input focus.
For all other situations where clicking anywhere else might make
sense to trigger an IM reset are covered by the focus changing paths,
that also ensure a reset before changing focus between surfaces/actors.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1961
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
Focus changes should trigger an IM reset, as some engines do want
to maybe commit the preedit string before changing focus. In addition,
we do not want the preedit string to be able to move between
windows/applications.
Ensure that the commit string is committed when the IM deems so, and
ensure we send a .done event disntinct to the .leave event, so that
the client doesn't miss the commit.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2030
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
DMA buffers might be allocatable, but it doesn't mean the driver doesn't
fail when we try to allocate a buffer with an implicit modifier. Using
the proprietary NVIDIA driver for example, it will fail. Lets catch this
up front and avoid advertising DMA buffer support when we know it won't
work.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2383>
As of currently, we only emit .done() on actual changes coming from the
ClutterInputMethod/ClutterInputFocus. With the recent changes in the
interpretation of serials, it becomes more important now that the
compositor acknowledges every .commit done by the client, in order to
keep them feeding future IM state updates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2365>
Compensate the protocol statelessness with our ClutterInputFocus
statefulness. This becomes more necessary now, since sending
consecutive .done() events is now considered acceptable behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2365>
MetaCursorRendererNative only updates the cursor state when the
underlying texture changes. The cursor scale and transform do not
trigger updates. This results in wrong cursor orientations on rotated
displays. Use both texture changes and scale and transformation changes
to figure out when to update the cursor state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2363>
When switching between the existence and not of a stage ClutterGrab, we
would correctly attempt to synchronize key focus from the perspective of
the Wayland clients.
But this synchronization should do its own checks about existing stage
grabs before determining a client window has key focus or not.
Add that check, so that grabs correctly unfocus the keyboard in Wayland
clients, in addition to pointers and touch.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2194
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2366>
When we get passed a "snippet" to the shaped texture, it's added as a
pipeline layer snippet to change how the source texture is sampled. When
we draw from a texture tower however we have allocated regular textures
which doesn't need any special layer snippet, so create separate
pipelines for those that doesn't use that snippet.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/528
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2278>
With Xwayland on demand, a number of maintenance X11 applications need
to be run first, before Xwayland starts accepting requests from the
normal clients, as soon as the WM_S0 selection is acquired by mutter.
On startup, mutter also sets a number of X11 properties that can be
queried by X11 clients.
Unfortunately, mutter acquires the WM_S0 selection before setting those
properties, so mutter and the first regular X11 client will race on
startup.
As a result, the X11 properties set by mutter on startup may not be
available to the very first X11 client when Xwayland starts.
To avoid that issue, make sure to take the WM_S0 selection last when
opening the display.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2176
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2336>
Currently, meta_xwayland_shutdown_dnd() is called from the handler
on_x11_display_closing() triggered from the signal "x11-display-closing"
hooked up from meta_xwayland_init_display().
Once the signal has been triggered, on_x11_display_closing() removes the
signal handler, disconnecting from the signal.
As meta_xwayland_init_display() is called from meta_display_new() which
is issued only once, the signal handler is not restored again.
As a result, meta_xwayland_shutdown_dnd() is not called anymore after
Xwayland has been restarted, but meta_xwayland_init_dnd() will check and
assert that the manager's DND object is NULL.
Basically, restarting Xwayland more that once will trigger an assertion
failure in mutter. That's even more of a problem with autoclose-xwayland
where Xwayland is expected to terminate when there is no meaningful X11
client remaining, which can happen multiple times during the lifetime
of a user session.
To make sure that meta_xwayland_init_display() is called for every new
instance of Xwayland, simply keep the signal hooked in place by not
disconnecting it when triggered.
This reverts commit 9a10b8ff94.
Even though, originally, this issue was first introduced with commit
b4fe1fdd95 ("xwayland: Make setup/teardown
a bit more symmetrical") which didn't actually kept 'x11-display-setup'
and 'x11-display-closing' connected.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2168
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2339>
For wayland meta_window_move_to_monitor sends a configure to the client
without actually moving the window, yet and the
meta_display_queue_check_fullscreen call won't detect any changes.
Checking for fullscreen in meta_window_update_monitor fixes the problem
because it is called whenever the window actually changed the monitor it
is on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2325>
We rather confusingly still call a secondary display card that is
GPU-less (DisplayLink or other basic KMS device) a "secondary GPU",
so just because secondary_gpu_state is non-NULL doesn't mean we
can use it for rendering. The clearest indication of this is when
there is no EGL surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2341>
Since devices may be multiple things now, check all capabilities in order
to ensure all aspects of the device are correctly configured.
This change does the following observations:
- Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad'
settings path. The regular pointer settings path is left for all
non-touchpads.
- Devices that are both a tablet and a touchscreen prefer the tablet
relocatable schema. This works for both aspects as the touchscreen
schema is a subset of the tablet one.
Other than that it's a rather boring, even if verbose search and replace.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
We do not need to open code the ClutterInputDeviceType fetching from a
libinput_device, since we already created a native ClutterInputDevice that
has the right type.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
We use meta_workpace_focus_default_window() to sync the input focus back
to a window after it was on shell UI, this is not really necessary on
Wayland, but it is on X11. What this function does internally is ask
MetaWindowStack about the topmost window and focus+raise that window.
In gnome-shell we set the input focus to the default window every time
the key-focus changes to NULL (see shell-global.c ->
sync_stage_window_focus()). Now when closing the alt-tab switcher and
activating a window while there's an always-on-top window on the
workspace, meta_workspace_focus_default_window() will focus that
always-on-top window right after closing the alt-tab switcher, making it
impossible to focus another window using alt-tab.
To fix this, make meta_workspace_focus_default_window() check if there's
an existing focus_window first, if there is, use that, and if there
isn't, resort to just focusing the topmost one.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5162
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2328>
This will allow us to reuse the keys and values more easily, as later
commits will rely on being able to iterate over the keys and values to
construct explict env strings for passing into special test cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2152>
We use get_window_for_event() to check whether an event happened on top
of a window or on top of shell UI to decide whether to bypass delivering
the event to Clutter. In case of crossing events though, we can't just
use the device actor to determine whether to forward the event to
Clutter or not: We do want to forward CLUTTER_LEAVE events which
happened on top of shell UI. In that case the device actor is already a
window actor (the pointer already is on top of a window), but the shell
still needs to get the LEAVE crossing event.
Since the event source actor got removed from the detail of
ClutterEvent, the context we're looking for (which actor did the pointer
leave) is now the target actor that the event gets emitted to. Since the
last commit, we also made event filters aware of this context by passing
the target actor to them, so use this context now to determine whether
we're on top of a window or not.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2321>
We'll need the additional context of which actor the event will be
emitted to in mutters event filter (see next commit), so pass that
target actor to the event filters that are installed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2321>
Before scanning out the surface of a native client we have
to check the following attributes that influence the
relationship between buffer and the defined result on screen:
- buffer scale
- buffer transform
- viewport
In the future we can loose these checks again in cases where the
display hardware supports the required operations (scaling, cropping
and rotating).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2276>
Prior to 67033b0a mutter was accidentally including sizes for
configurations that were just focus state changes. This was not leading
to any known problems on the client side, but it was causing issues in
mutter itself when detecting whether a resize originated from the client
or the server.
Not including sizes in focus change configurations anymore however
revealed a bug in gtk. It was storing the window size when in a fixed
size mode (tiled/maximized/fullscreen), but not on any other server side
resizes. It was then restoring this stored size whenever there was a new
configuration without a size while in floating mode, i.e. the focus
change configurations generated by mutter after 67033b0a.
This change now addresses the issue 67033b0a was fixing in a way that
restores the previous behavior of always including the size whenever
sending a configuration.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2091
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2238>
If the remote desktop service emits absolute input events (e.g. absolute
pointer events) before the stream has started streaming, we don't have a
virtual monitor, as the size has not been negotiated yet. When this
happens, just drop the event. Remote desktop services should probably
make sure not to send events before the streaming has started, but them
doing so anyway shouldn't trigger a crash, which would be the case
otherwise.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2270>
This test resizes the stream by updating the PipeWire stream properties.
This triggers a format negotiation, that results in the buffers being
reallocated with the new size. The test makes sure we eventually
receive this new size.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2270>
Keep the virtual monitor around if it's being resized. This reduces the
number of unnecessary object rebuilding that happen during monitor
rebuilding.
This changes finalize() vfunc into a dispose() vfunc in the abstract
stream source object implementation, as it needs the abstract stream
source object to close the stream early, so that various signal
listeners get disconnected early.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1904
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2270>
We'll change mode's on-demand so using IDs identical to the virtual
monitor ID would mean IDs didn't change when changing mode, and that is
rather unintuitive. IDs don't mean much anyhow, just make them grow
within the realm of a 63 bit unsigned integer, as the 64th bit means its
a virtual mode ID. Making sure the ID is in the virtual mode namespace
is handled by meta_crtc_mode_virtual_new().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2270>
In some configurations (e.g. NVIDIA driver 470) Xwayland may use DMA
buffer for passing buffers around. When this is done, we might attempt
to scanout these buffers when they are fullscreen, and to do so we
import them using gbm.
However, for the mentioned configuration, there is no gbm device
available for importing. This was not handled, and resulted in a crash;
avoid this crash by checking whether we have a gbm device and fail
gracefully if we don't.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2098
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2318>
This aims to replace the x,y arguments in wl_surface.attach(); meaning
it can be used more sanely together with EGL, and at all when using
Vulkan.
The most common use case for the offset is setting the hotspot of DND
surfaces.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1905>
This implements the new 'bounds' event that is part of the xdg_toplevel
interface in the xdg-shell protocol. It aims to let clients create
"good" default window sizes that depends on e.g. the resolution of the
monitor the window will be mapped on, whether there are panels taking up
space, and things like that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2167>
We'd guess the initial monitor before it was actually calculated by
looking at the initial geometry. For Wayland windows, this geometry was
always 0x0+0+0, thus the selected monitor was always the primary one.
This is problematic if we want to provide initial more likely
configurations to Wayland clients. While we're not doing that yet, it'll
be added later, and this is in preparation for that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2167>
This will later be used to tell Wayland clients about a size they
shouldn't exceed.
If the window doesn't have a main monitor, this function does nothing
and returns FALSE.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2167>
gnome-desktop is used to retrieve the monitor vendor name which in some
use cases is not needed as it brings a bunch of gnome-desktop unwanted
dependencies.
The change makes mutter fallback to an "Undefined" vendor name if it is
built without gnome-desktop
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2317>
Return in meta_egl_choose_all_configs() the actual number of
configurations returned by eglChooseConfig(), which are not
necessarily the same number as those from eglGetConfigs().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2303>
Since the introduction of ClutterGrabs, MetaDnd now no longer gets
notified about input events on the stage during grabs (for example while
the alt-tab popup is shown) and thus can't move the grab feedback actor
anymore.
To fix this, forward events to MetaDnD directly from
meta_display_handle_event() when a ClutterGrab is in effect.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2308>
We get the MetaWaylandCompositor a bunch of times, but we can do with
getting it only once and then also replace the is_wayland_compositor()
checks with a if (wayland_compositor).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2308>
The XDG activation support was missing interoperability with other
startup sequences, notably those coming from other means than XDG
activation.
In order to play nice with X11 startup sequence IDs, we not just
have to check for the startup ID being in the general pool, but
we also need to fallback into X11-style timestamp comparison so the
window ends up properly focused.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2314>
When a drag and drop occurs from an X11 client to a Wayland native
client, mutter uses an internal X11 window as a peer for the DnD drop
site.
That internal X11 window is moved and resized to match the Wayland
native windows as the drag destination moves.
When moving from one Wayland native window to another Wayland native
window, the same X11 window is used, and as a result no DND enter/leave
events is emitted.
In that case, the drop may occur on the wrong Wayland native window,
because no new XdndEnter/XdndLeave event were emitted.
To avoid that issue, use a pair of X11 windows instead of just one and
alternate between the two when repicking a new drop surface, so that
moving from a Wayland surface to another will always generate the
expected enter/leave events that we rely on.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2136
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2305>
When generating the action label, we expect both directions of these
features to have consistent settings (either both get a keycombo, or
they don't) or these just return NULL altogether.
Since one of the directions has an action associated, this is
misleading, so be more lenient at the time of generating the action
label.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2001>
If we happen to handle a CLUTTER_TOUCH_BEGIN without a corresponding
CLUTTER_TOUCH_END at MetaWaylandTouch, we would still attempt to
reuse the older MetaWaylandTouchInfo, resulting in an assert triggered
as there is a stale touch reference on the previous surface.
Warn in place and create a new touch info struct to still fix the
broken surface accounting, instead of finding out the hard
way after the surface is destroyed. The assert is preserved to ensure
the accounting does not sneakily break anymore/further.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/584
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2251>
It passes a MetaLogicalMonitor, which isn't introspected right now, so
skip it completely. The entry point to the UI is handled via
MetaDisplay, so it isn't needed.
This fixes the following warning:
<unknown>:: Warning: Meta: (Signal)monitor-privacy-screen-changed: argument object: Unresolved type: 'MetaLogicalMonitor'
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2287>
Structure tests in a list of dictionaries, instead of requiring each
test to have its own executable(...) and test(...) statement. The
intention of this is to make it easier to add more test cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2262>
It already was built into it without any symbols exported, but also
duplicated in test cases that used it. Make it so that the built in
functions are exported, with prefixes, and make all tests use the
exported functions. While at it, make things go via MetaContext or
MetaBackend depending on how early in initialization things are run.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2262>
We update some details like the last used device and pointer visibility
from events, but this is done inconsistently on X11 since the
ClutterEvents are created and pushed from an additional place.
Make these updates happen on a private call, that will be called from
these places in X11.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/285>
Even though it's great that XI2 has an event to notify about device
changes, this is something we can let the MetaBackend code handle
consistently for all backends, since looking for the source device
works everywhere.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/285>
Instead of relying in the device being updated from different parts of our
machinery for different backends, hook this up to our own event dispatching.
This will allow dropping all other places where this is done.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/285>
We create a cursor renderer per device for those at
meta_seat_native_handle_event_post() with PROXIMITY_IN events, but
the MetaWaylandTabletTool handles the event before that, and goes
with a NULL cursor renderer.
Make MetaBackend::get_cursor_renderer() on the native backend create
those cursor renderers on demand, and only handle PROXIMITY_OUT in
handle_event_post() to dispose those. This makes MetaWaylandTabletTool
happily get a cursor renderer again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/285>
We now only enable DMA buffer based PipeWire screen casting if a
format/modifier has been negotiated. This practically means a consumer
is aware about what is needed, and we should not try to predict that it
uses the DMA buffer the right way (i.e. not mmap:ing directly).
However, in case we're not hardware accelerated, we never want to
attempt to use DMA buffer screen sharing, as we want to avoid
compositing into a DMA buffer on such hardware as doing so can be very
slow.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2086>
meta_window_(un)queue() was implemented with global arrays in window.c
that managed MetaLater handle IDs and lists of window queues. In order
to rely less on scattered static variables and making it clearer that
we're dealing with per display window management and not something
specific to a single window, move the window resize/calc-showing queue
management to MetaDisplay.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2264>
It's still used by e.g. GNOME Shell to produce fallback icons for X11
applications that doesn't come with a .desktop file. Geometry stays in
the generic class because it's used for minimize animations and is
configured by the panel (e.g. the one in gnome-shell-extensions).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2264>
The comments in this function tells a story of C programmer self
reflecting about data types and Perl. While that can be nice, the rest
consisted mostly of repeating what the code line below did, with the end
result being that the function didn't fit on screen, resulting in worse
readability overall.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2264>
When handling lid state, we used to update the idle time right after
opening the lid. This behavior changed in commit 14b6c8780d due
to a typo/thinko, "if (lid_is_closed)" used to be an early return
condition before updating idle time, now it only updates in that
case.
Restore the original behavior, since this idle time update is key
in having gsd-power light up the display again, this presumably
fixes situations that required extra "light up" hints after suspend.
What it does surely fix is "ninja test" in g-s-d against recent
mutter, since the behavioral change induced a test timeout there.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2272>
The `ensure_x11_unix_perms` function tries to detect systems on which
/tmp/.X11-unix is owned by neither root nor ourselves because in that
case the owner can take over the socket we create (symlink races are
fixed in linux 800179c9b8a1e796e441674776d11cd4c05d61d7). This should
not be possible in the first place and systems should come with some way
to ensure that's the case (systemd-tmpfiles, polyinstantiationm …). That
check however only works if we see the root user namespace which might
not be the case when running in e.g. toolbx.
This change relaxes the requirements such that in the root user
namespace we detect and abort if a vulnerable system is detected but
unconditionally run in toolbx.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2261>
Add some debug logging that allows checking whether we're using DMA
buffers for screencasting or system memory buffers. This can be useful
for debugging screencasting performance and CPU usage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2256>
With the ability to query the renderer for DMA-BUF support we can
announce support for implicit modifiers. This allows PipeWire to check
for matching modifiers while negotiation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1939>
Returns TRUE if the active renderer backend can allocate DMA buffers.
This is the case hardware accelerated GBM backends, but FALSE for
surfaceless (i.e. no render node) and EGLDevice (legacy NVIDIA paths).
While software based gbm devices can allocate DMA buffers, we don't want
to allocate them for offscreen rendering, as we really only use these
for inter process transfers, and as buffers allocated for scanout
doesn't use the relevant API, making it return FALSE for these solves
that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1939>
There may be situations where we may stack a ClutterGrab on top of a
wayland popup's. Since ClutterGrab should win over client grabs, we
mostly correctly figure out that it should start doing
bypass_wayland=TRUE and bypass_clutter=FALSE while the ClutterGrab
holds, however the late checks for the MetaDisplay event route can
still toggle bypass_clutter on, resulting in neither handling events.
This check for wayland popups in the display event route should just
enforce wayland handling if wayland is meant to be receiving events,
so ensure these don't mix together.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5020
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2271>
Wayland event processing and WM operations are themselves outside the
ClutterGrab loop so far. Until this is sorted out, these pieces of
event handling have got to learn to stay aside while there is a
ClutterGrab going on.
So, synchronize foci and other state when grabs come in or out, and
make it sure that Wayland event processing does not happen while
grabs happen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2099>
Since we want these accessed from bindings this must be a boxed
type. This has the side effect of making ClutterGrab a refcounted
object, since we want to avoid JS from pointing to freed memory
and maybe causing crashes if misusing the object after dismiss.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2099>
This is (luckily!) unused, and it's inconvenient to have a toggle to
break the input model we are striving towards. Drop this function
and stick to the default behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2099>
The experimental feature "autoclose-xwayland" requires a couple of
prerequisites:
1. Be able to (re)start Xwayland on demand, i.e. with systemd
2. Xwayland must support the terminate delay
Add a warning message if "autoclose-xwayland" was requested but any of
those prerequisites is not met.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2258>
Since commit 226afa24a - "Use Xwayland auto-terminate feature", the
callback function shutdown_xwayland_cb() does not check for the
autoclose-xwayland experimental feature anymore.
As a result, when running nested or outside of systemd,
gnome-shell/mutter would quit after 10 seconds unless some X11 window
was mapped.
But now that we rely on Xwayland's own terminate feature, there really is
no need to use any xserver timeout function anymore.
We do not need to keep track of X11 windows being created or unmapped, as
again, Xwayland does all that for us at the client level.
Remove all this code that we do not need anymore.
fixes: 226afa24a - Use Xwayland auto-terminate feature
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2258>
Because both code paths require the existence of `GL_TIMESTAMP[_EXT]`
which is only guaranteed if `ARB_timer_query` (included in GL core 3.3)
is implemented.
We know when that is true because `context->glGenQueries` and
`context->glQueryCounter` are non-NULL. So that is the minimum
requirement for any use of `GL_TIMESTAMP`, even when it is used in
`glGetInteger64v`.
Until now, Raspberry Pi (OpenGL 2.1) would find a working implementation
of `glGetInteger64v` but failed to check whether the driver understands
`GL_TIMESTAMP` (it doesn't).
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2107
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2253>
When using Xwayland-on-demand (default), if the (experimental) autoclose
features is enabled, we can rely on Xwayland's auto-terminate feature
instead of explicitly killing the Xwayland process.
With it, gone is the mechanism that was added to check the X11 clients
connected and their executable to check whether we can (safely) kill
Xwayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1794>
The connection to the Xserver for the X11 window manager part of mutter
even on Wayland may prevent the Xserver from shutting down.
Currently, what mutter does is to check the X11 clients still connected
to Xwayland using the XRes extension, with a list of X11 clients that
can be safely ignored (typically the GNOME XSettings daemon, the IBus
daemon, pulseaudio and even mutter window manager itself).
When there is just those known clients remaining, mutter would kill
Xwayland automatically.
But that's racy, because between the time mutter checks with Xwayland
the remaining clients and the time it actually kills the process, a new
X11 client might have come along and won't be able to connect to
Xwayland that mutter is just about to kill.
Because of that, the feature “autoclose-xwayland” is marked as an
experimental feature in mutter and not enabled by default.
Thankfully, the Xserver has all it takes to manage that already, and
is even capable of terminating itself once all X11 clients are gone (the
-terminate option on the command line).
With XFixes version 6, the X11 clients can declare themselves
"terminatable", so that the Xserver could simply ignore those X11
clients when checking the remaining clients and terminate itself
automatically.
Use that mechanism to declare mutter's own connection to the Xserver as
"terminatable" when Xwayland is started on demand so that it won't hold
Xwayland alive for the sole purpose of mutter itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1794>
Adding a <dbus/> element containing a boolean (yes/no) determines
whether org.gnome.Mutter.DisplayConfig ApplyMonitorsConfig will be
callable. The state is also introspectable via the
ApplyMonitorsConfigAllowed property on the same interface.
For example
<monitors version="2">
<policy>
<dbus>no</dbus>
</policy>
</monitors>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
The test aims to verify that setting the following policy
<policy>
<stores>
<store>system</store>
</stores>
</policy>
only applies monitor configurations from the system level.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
This adds a way to define a way, at the system level, to define a policy
of how monitor configuration files are loaded.
The intended use case is to e.g. either prefer system level monitor
configurations before user levels, or only allow system level
configurations.
Examples:
Prefer system over user level configurations:
<monitors version="2">
<policy>
<stores>
<store>system</store>
<store>user</store>
</stores>
</policy>
<configuration>
...
</configuration>
</monitors>
Only allow system level configurations:
<monitors version="2">
<policy>
<stores>
<store>system</store>
</stores>
</policy>
<configuration>
...
</configuration>
</monitors>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
strncmp() always return 0 if the passed length is 0. What this means is
that whatever the first string check happens to be, if the parsed XML
cdata was empty (e.g. if we got <element></element>), the first
condition would evaluate to true, which is rather unexpected.
Fix this by making sure the string length is correct first. Also move it
into a helper so we don't need to repeat the same strlen() check every
time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
The way device backends implement power saving differ, and power saving
needs to contain nothing incompatible in the same update. Make it
impossible to e.g. mode set, page flip, etc while entering power save by
not using MetaKmsUpdate's at all for this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
When we're predicting state, i.e. when having posted an update while
avoiding reading KMS state, copy the predicted state, update the actual
state, and check that the predicted state matches the newly updated one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
It was a bit scattered, with it being split between MetaKms and
MetaKmsImpl, dealing with MetaKmsDevice and MetaKmsImplDevice
differentation. Replace this by, for now, single entry point on
MetaKmsDevice: meta_kms_device_process_update_sync() that does the right
thing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
As other KMS tests, depends on being DRM master and vkms being loaded.
Currently consists of a sanity check that checks for the expected set of
connectors, CRTCs, planes, etc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
Right now gamma is set only via the D-Bus API (from gsd-color), but the
actual gamma isn't right after SetCrtcGamma(), meaning if one would call
GetCrtcGamma() right after setting it, one would get the old result.
Avoid this by getting the "current" CRTC gamma from the cache we manage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
In order to support dynamic imports, gjs added an implicit mainloop
that can drive the main context independently from other mainloops
like the one from GApplication or MetaContext.
That means that sources can now get dispatched to the main context
from the moment the plugin is started, resulting in a crash as the
association between compositor and plugin manager doesn't exist until
meta_plugin_manager_new() returns.
Make sure this doesn't happen by only starting the plugin after
meta_plugin_manager_new() has returned.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2242>
When privacy screen is changed and this happens on explicit user request
(that is not a setting change) we should notify about this via an OSD.
To perform this, we keep track of the reason that lead to a privacy
screen change, and when we record it we try to notify the user about.
When the hardware has not an explicit hotkey signal but we record a
change we must still fallback to this case.
Fixes: #2105
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
Privacy screen events on connector are handled as notification events
that won't cause any monitors reconfiguration but will emit monitors
changed on DBus, so that the new value can be fetched.
We monitor the hardware state so that we can also handle the case of
devices with hw-switchers only.
In case a software state is available it means we can also support
changing the state, and if so expose the state as unlocked.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
When both a setting change and a monitor change happens we need to
ensure that the monitor settings are applied.
This is currently only related to privacy settings, but will in future
also handle other monitor parameters such as brightness.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
Some monitors support hardware features to enable the privacy screen
mode that allows users to toggle (via software or hardware button) a
state in which the display may be harder to see to people not sitting
in front of it.
Expose then this capability to the monitor level so that we can get its
state and set it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
In some cases mutter is started in the user scope from a TTY (for
example using toolbox). Using sd_pid_get_session fails because it's not
in the session scope so it falls back to the primary session
(sd_uid_get_display). We want to start mutter on the TTY we started
mutter on however. Instead of relying on the scope to figure out the
correct session we first look at $XDG_SESSION_ID which is set by
systemd_pam.so.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2254>
It is possible that we never create a cached state for a surface
even if it is synced. That is the case if `commit()` is never called.
We still need to call `apply_state()` in this case in order to run
e.g. `role_post_apply_state()` or `parent_state_applied` on subsurfaces.
So just ensure to initialize the cached state instead of bailing out.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2232>
Subsurfaces can be effectively synced indirectly via their ancestors.
Right now such indirectly synced surfaces don't apply their cached
state when their ancestor effectively becomes desync as by the time
we call `parent_state_applied()` on them, they are considered as
desync.
Thus sligthly reoder things so when the ancestors becomes desync
and applies its state, those surfaces still count as synced and
will thus apply their cached state as well.
While on it, add a check to prevent `set_desync()` to have side
effects when the target surface is not currently synced.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2232>
At first glance the `goto` looks like a loop, or potentially an infinite
loop. It's not a loop because the mode has changed at that point to
`META_SHARED_FRAMEBUFFER_COPY_MODE_PRIMARY`. But we can make it more
obvious and avoid the need for a goto.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2240>
The stage window is an interface, that added properties, that were only
then actually managed by MetaStageImpl. Shuffle things slightly, and let
the MetaStageImpl object deal with these things itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2014>
What the keymap eventually is after, are things handled by the actual
backend (MetaBackendX11), so let it keep a pointer to that. This
eliminates some usages of globals.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2014>
It tests that if we go from (x is the pointer cursor)
+--------+
| |
| X |
+--------+
to
+----------------+
| |
| |
+--------+ |
| | |
| X | |
+--------+----------------+
i.e. making sure that X ends up somewhere within the logical monitor
region.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2237>
These will be skipped by default, but can be run from a TTY for easier
debugging by doing:
dbus-run-session -- meson test -C build --suite mutter/native/tty --setup plain
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
This commit makes it possible to run test executables in a test
environment constructed of a virtual machine running the Linux kernel
with the virtual KMS driver enabled, and a mocked system environment
using meta-dbus-runner.py/python-dbusmock.
The qemu machine is configured to use 256M of memory, as the default
128M was not enough for the tests to pass.
Using qemu is also only made possible on x86_64; more changes are needed
for it to be runnable on aarch64, so add a warning if it was enabled on
any other architecture.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
This is needed if one wants to run the test suite parts that need KMS or
evdev access in a virtual machine.
However, only initiate these methods if the meta-dbus-runner.py program
was launched with --kvm, as it's only suitable for using while running
as root in a virtual machine.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
When we test, we might not have a systemd session to rely on, and this
may cause some API we depend on to get various session related data to
not work properly. Avoid this issue by passing fallback values for these
when we're running in test mode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
There will be another mode added later, 'test'; prepare for this by
changing the existing "mode" boolean ('headless') to a mode, which is
either 'default' or 'headless'. Checking the is_headless variable is
changed to using the function is_headless(), except for one place, being
VT switching, which in preparation is only allowed on the 'default'
mode. Other places where it makes sense, the conditions are changed to
switch statements.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
When running in KVM, the EGL driver supports querying the render node
path, but it returns NULL. Handle that better by falling back to
querying the device main device file, instead of falling back on v3 of
the protocol and logging a warning.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
Some API will return NULL or the equivalent; sometimes it's an error,
and sometimes it's not, and the way to check that is by looking at the
return value of eglGetError(). When we check this, don't set the GError
if it returned EGL_SUCCESS, as that indicates that the return value is
expected behavior, and not an error.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
There was a sanity check that complained if there was still a "next
framebuffer" when disposing an onscreen. This is correct to complain
about under normal operation, as we always wait until receiving the page
flip callback before cleaning up the onscreen and their state.
However, when there are many hotplugs occurring, we might end up with
race conditions when the above sanity check is not valid: when we have
more than one monitor active, paint 1 one of them, but receive a hotplug
event before we paint the other(s), we will discard the already painted
onscreen before really issuing a page flip.
In this situation, we will have the "next framebuffer", but having that
is not a bug, it's a race condition, thus to not leak in this situation,
make sure to clean up the next framebuffer here too.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2081
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2225>
If there are any pending updates, for example if we painted one of
multiple monitors but without having posted the update due to waiting
for another monitor to be painted, but before we paint all of them and
post the update, another hotplug event happens, we'd have stale pending
KMS update. When that update eventually would be processed, we'd try to
apply out-of-date updates which may contain freed memory.
Fix this by discarding any update when we're rebuilding the views. We
can be sure not to need any of the old updates since we're rebuilding
the whole content anyway.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1928
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2216>
Following the EGL_KHR_swap_buffers_with_damage specification, the
surface damage used by eglSwapBuffersWithDamage does not need to
contain the damage history.
Rework that to reduce the amount of rectangles that get passed to
the backend.
Also rework some of the regions that were using fb_clip_region and
missing the last scaling to support fractional scaling.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2089>
When the before-paint function is executed, it's only purpose
is to check if there's any scanout queue, and immediately
record it if any.
However, since [1], we regressed in this specific case with the
introduction of an idle callback in the before-paint function.
The regression only happens when the PipeWire stream is using
DMA-BUF buffers, and it would operate as follows:
1. In before-paint, when there's a scanout available, we queue
an idle callback to capture the monitor. The idle callback
(almost always) executes after the scanout is pulled from
the stage view
2. meta_screen_cast_stream_src_maybe_record_frame() is called
by the idle callback. In the DMA-BUF case, it then runs
meta_screen_cast_monitor_stream_src_record_to_framebuffer()
3. In meta_screen_cast_monitor_stream_src_record_to_framebuffer(),
because the stage view doesn't have a scanout anymore, it
ends up calling cogl_blit_framebuffer() with the stage view
framebuffer. This is the regression bug.
This regression presents itself in the form of the screencast
stream showing the desktop when there's an unredirected fullscreen
application window running.
Revert before-paint - and only that - back to immediately capturing
any available scanout. Only record these frames when the target
buffer is a DMA-BUF handle. Nothing is captured on before-paint if
the stream is not using DMA-BUF, since the regular paint routine
will handle these frames regularly post-paint.
[1] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1914
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2186>
Next commits will reintroduce a certain behavior of stage
capturing that can only happen with DMA-BUF buffers. To
control this, add a new flag tp MetaScreenCastRecordFlags
for this behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2186>
If a Wayland subsurface is the topmost actor, consider in for
scanout as well. This will extend our scanout capabilities to apps
like Firefox
While on it, correct a unnessary type check to a NULL check.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2211>
On Wayland a window actor may have more than one surface actor,
most importantly when subsurfaces are used.
Add a new function to request the one which is at the top -
it will be used in the next commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2211>
If the EGL header is not new enough, it will not contain that relatively
new macro definition, so to avoid breaking compilation, define it
ourselves for now. Should be possible to remove after some time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2214>
We save the window rect before going fullscreen to a dedicated variable,
so we can go back to the correct dimension. We also have a dedicated
variable for returning from other window states, e.g. maximized, and
this one we initialized when creating the MetaWindow. This meant that we
could always rely on this being up to date on X11 windows that were
mapped maximized or fullscreen.
What the commit that introduced the saved rect dedicated for going
unfullscreen missed was to initialize the new saved rectangle too when
creating the MetaWindow. This resulted in windows mapped as fullscreen
often ending up misbehaving when unfullscreening, as mutter would tell
them to unfullscreen to 0x0.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1786
Fixes: a51ad8f932
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2210>
Since every input stream now uses its own window, the X property used to
transfer the data no longer has to be unique, so we can stop generating
those unique names. This avoids creating a new atom for every transfer
since those are never freed, neither on the shell nor on the server
side. Also don't unnecessarily duplicate other strings that are
(almost) never used and get them from the atom in the rare case when
they are needed.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1328
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1812>
When there are two (or more) concurrent XConvertSelection requests with
the same target, selection and window and the data is large enough for
SelectionNotify events to overlap. This can result in the affected streams
being considered completed without any data being transferred.
While regular mutter/shell code does not make use of concurrent
XConvertSelection requests with the same targets, some extensions might.
Such as for example a clipboard manager that like the built-in clipboard
manager tries to read the selection on owner-changed.
One potential solution would be to make sure the event is for the correct
property, but not all clients seem to support concurrent requests for the
same targets but different properties on the same window.
This commit instead changes the streams to use their own window which
seems to be more widely supported.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4034
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1812>
This is a preparation for each input stream creating its own window. It
moves deleting the property from meta_x11_selection_input_stream_xevent
where it can run after the stream has been finalized to a spot where
the stream still exists. Use an error trap in case the property was not
set by the client, such as when the conversion failed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1812>
This significantly increases the chance of a fullscreen surface buffer
being scanned out instead of being painted via composition. This is
assuming the client supports the DMA buffer feedback Wayland protocol.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2146>
This API can be used to construct a MetaKmsUpdate with plane assignments
that in isolation will be tested against the current KMS state. How it
is tested depends on the KMS implementation; in the simple / legacy KMS
backend, the tests are identical to the current scanout requirements
(dimension, stride, format, modifiers, all must match), and with atomic
KMS, it uses the TEST_ONLY on a real constructed atomic mode setting
commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2146>
Whenever a surface is promoted as a scanout candidate by
MetaCompositorNative, it'll get a CRTC set as the candidate CRTC.
When a client asks for DMA buffer surface feedback, use this property to
determine whether we should send a scanout feedback tranche.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1959>
