This launches Xvfb, using xvfb-run, and inside tests the following:
1. Launching 'mutter --x11' works
2. Launching a couple of X11 clients works (doesn't crash or result in
warnings)
3. Launching 'mutter --x11 --replace' works
4. Terminating works
It does this using a simple shell script.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2434>
We don't make use of the refresh rate in any useful way in the X11, and
in this case we just ended up with warnings since the refresh rate was
NaN. Fix this by making it 0.0 to mean "no refresh rate". This also is
what 'xrandr' itself reports.
Fixes warnings when launching 'mutter --x11' in Xvfb.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2434>
This adds a minimalistic fullscreen direct scanout test case, that runs
on vkms. It doesn't use EGL, and it uses uninitialized memory, thus it
lacks any kind of implicit synchronization, but it does test that the
scanout selection paths are working.
What is tested is:
* DMA buffer allocated using gbm on top of VKMS
* Buffer passes a mode setting TEST_ONLY check
* Paint is omitted
* Correct buffer active in KMS after presentation
What isn't yet tested:
* Implicit synchronization related behavior
* Presented pixel content
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2417>
We passed the pointer to a GError * as user data on an async I/O call.
The callback function didn't make use of it, so it was never written to,
thus remained NULL, thus was dead code. Remove it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2446>
It works by using an X11 client to set the clipboard content, using a
mimetype that on purpose is not handled by the clipboard manager. The
test then makes sure we don't crash when trying to transfer data from
the old X11 selection source.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2364>
The Xwayland server can go away at any time; when this happen we might
have a test client running, and for it to tear down more nicely, make
sure to avoid trying to clean up X11 resources on the old X11 display.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2364>
Xwayland can disappear at any time, for example during a new_async() or
read_async() call. When we eventually finalize the stream, the X11
display it was created for is gone, thus can't clean up the X11
resources. Handle this by making the MetaX11Display pointer a weak
pointer, and ignore cleaning up if it disappeared. This is fine since
the X11 server it created those resources one is gone already.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2364>
The property doesn't necessarily exist when using drivers that doesn't
support atomic mode setting, and the way it worked will break night
light and other gamma related features. This makes things use the gamma
length; if it is higher than 0, it definitely supports it one way or the
other, i.e. GAMMA_LUT with the atomic backend, and drmModeCrtcSetGamma()
with the legacy/simple backend.
Fixes: 364572b95c
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2287
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2435>
It doesn't depend on whether the CRTC is active or not, so always read
it. This is also useful to know whether a CRTC supports gamma, before it
is being turned on, without relying on the existance of properties.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2435>
The COMPOSITOR_GRAB event route has effectively been replaced by
ClutterGrabs, which are no longer covered by the existing check.
So check for grabs as well to restore the old behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436>
The event-route is never set to COMPOSITOR_GRAB nowadays, so the
condition will never be met.
Furthermore, it is expected that ClutterGrabs only happen when
events are routed normally, so the remaining NORMAL check should
already fully cover the old COMPOSITOR_GRAB case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436>
We already bypass wayland if there is a ClutterGrab, so the case
that used to be covered by the event-route check is already handled,
and we can just remove the obsolete check.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436>
Since the new ClutterGrab API replaced the old plugin-modal hook,
the event-route is never set to COMPOSITOR_GRAB.
The code in question already checks whether the stage has a grab,
so we can just remove old checks.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436>
Initializing the event mask, SubstructureRedirectMask in particular,
before taking the manager selection fails with BadAccess. Fix this by
initializing said mask after taking the manager selection.
This fixes `--replace`.
Fixes: eb4307c350
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2432>
The code is already trying to avoid creating new laters when there
already is one for the queue type, but this wasn't working because the
ID of the later was never stored after creating a new one. This would
then result in as many laters as meta_display_queue_window() was called
and all of them would run the handler function, even if only the first
one had a non-empty window queue.
Similarly this was causing the later to not be removed if the window
queue got empty after meta_display_unqueue_window().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2414>
Currently the signal is getting emitted accidentally, because even when
removing a window from the queue, the later handler of that queue will
still get run due to a bug. This bug is going to get fixed in the next
commit, but some things might depend on the signal getting emitted when
the visibility of a window has changed.
This change affects the behavior in two ways. First the signal is now
emitted immediately rather than from an idle. And second it now
correctly includes the window in the should_show or should_hide list.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2414>
The compositor currently only updates the topmost window actor that is
visible to it after stacking changes. The visibility of a window actor
to the compositor however might only change via the display idle queue
after the stacking changes. This could then lead to the topmost window
actor being assumed to be NULL on Wayland after switching from an empty
workspace or when opening the first window on an empty workspace. The
result of this is direct scanout being disabled in these cases.
To fix this also trigger the update when the visibility of windows
changes.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2269
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2413>
Some windows span the entire screen but still use transparency, such as
the desktop window of Nemo. When these windows were used for direct
scanout, the transparent areas would turn black and nothing else would
be rendered.
In addition to checking the surface for opaqueness, for X11 windows also
the window actor itself has to be checked, because its opacity might
have been changed via _NET_WM_WINDOW_OPACITY.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2263
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2409>
This replaces the API to get the topmost surface actor with an API to
get the surface actor that could be a candidate for direct scanout. The
advantage of this is that it allows X11 and Wayland specific
restrictions for these actors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2409>
It's not allowed to call eglQueryWaylandBuffer() if the call to
eglBindWaylandDisplay() failed, and will result in an assert being hit
in mesa if called.
Avoid that by keeping track whether we succeeded to bind, and only
attempt to realize a legacy EGL wl_buffer if binding succeeded.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2415>
Mutter makes use of a gsettings scheme that comes from
gnome-settings-daemon to check for the screen orientation.
In use cases where gnome-settings-daemon is not available,
this would lead to a crash as the key doesn't exists
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2398>
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>
The final tick of a timeline is >= its duration, but when using ticks that
are slightly in the future ("next presentation time") this means the final
tick will execute and complete the timeline up to one frame interval before
the timestamp of that final tick.
For the single clock test we now just check if the overall duration is
within one frame of the expected timeline duration.
The dual clock (switching) test needs a threshold of two frames because
starting each new clock creates a phase shift (error) of up to one frame.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2161>
We're in the destructor, it's pointless to unset the userdata as we'll
never ever see a request being invoked with it ever again, since the
resource itself will be destroyed or marked as destroyed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2202>
When rendering to a buffer that is not the stage view buffer, we can not
know where the buffer will be displayed on the screen. As a result we
also can not know what translation would need to be applied to culling.
This was causing glitches when the gnome-shell magnifier was applying
offscreen effects. ClutterOffscreenEffect causes MetaWindowGroup to be
rendered to an offscreen buffer at an offset, because it draws to a
slightly larger texture with an accordingly translated origin. This
translation then later is canceled out again when the offscreen buffer
is drawn. To meta_actor_painting_untransformed() however which only sees
the translation used when drawing to the buffer this looked like the
window group was being rendered at the offset. This then lead to
redraw_clip getting translated accordingly, resulting in wrong
coordinates used for culling.
Similarly this was leading to issues when taking area screenshots while
at 1x zoom.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1678
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4876
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2080>
Refresh rates >60Hz become ever more common. In order to allow users
to keep hight refresh rates when not running at a natively advertized
resolution, add common refresh rates to our fallback modes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2189>
Right now we often add a duplicate fallback mode that's almost
identical to the native mode. This adds unnecessary clutter to
UIs, thus filter out such modes.
In order to keep the code small, use `MetaCrtcModeInfo` directly
instead of recalculating the values. And to keep consistency, do
the same in the loop above.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2189>
This is so that it can unregister from it on tear down. The tracker owns
references to cursors too, but this cycle is already broken as the
backend calls 'g_object_run_dispose()' when tearing the cursor tracker
down.
Fixes a crash on shutdown.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2181>
An incorrect assumption that after mode set there would be no pending
page flips was made. This meant that if there was a mode set, followed
by a page flip, if that page flip was for a CRTC on a now unused GPU,
we'd crash due to the renderer GPU data having already been freed. This
commit avoids that by keeping it alive as long as the page flips are
still in the air. It fixes crashes with backtraces such as
0) meta_render_device_get_egl_display (render_device=0x0)
at ../src/backends/native/meta-render-device.c:320
1) secondary_gpu_state_free (secondary_gpu_state=0x1c8cc30)
at ../src/backends/native/meta-onscreen-native.c:560
2) meta_onscreen_native_dispose (object=0x1cb65e0)
at ../src/backends/native/meta-onscreen-native.c:2168
3) g_object_unref (_object=<optimized out>)
at ../gobject/gobject.c:3540
4) g_object_unref (_object=0x1cb65e0)
at ../gobject/gobject.c:3470
5) clutter_stage_view_finalize (object=0x1cbb450)
at ../clutter/clutter/clutter-stage-view.c:1412
6) g_object_unref (_object=<optimized out>)
at ../gobject/gobject.c:3578
7) g_object_unref (_object=0x1cbb450)
at ../gobject/gobject.c:3470
8) meta_kms_page_flip_closure_free (closure=0x1d47e60)
at ../src/backends/native/meta-kms-page-flip.c:76
9) g_list_foreach (list=<optimized out>, func=0x7fb3ada67111 <meta_kms_page_flip_closure_free>, user_data=0x0)
at ../glib/glist.c:1090
10) g_list_free_full (list=0x1cb4d20 = {...}, free_func=<optimized out>)
at ../glib/glist.c:244
11) meta_kms_page_flip_data_unref (page_flip_data=0x1c65510)
at ../src/backends/native/meta-kms-page-flip.c:109
12) meta_kms_callback_data_free (callback_data=0x227ebf0)
at ../src/backends/native/meta-kms.c:372
13) flush_callbacks (kms=0x18e2630)
at ../src/backends/native/meta-kms.c:391
14) callback_idle (user_data=0x18e2630)
at ../src/backends/native/meta-kms.c
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2147>
This ensures we don't have any left over cursor GPU buffers (via
gbm_bo's) after destroying the corresponding gbm_device (owned by
MetaRenderDevice).
Fixes crashes with backtraces such as
1) meta_drm_buffer_gbm_finalize at ../src/backends/native/meta-drm-buffer-gbm.c:450
4) invalidate_cursor_gpu_state at ../src/backends/native/meta-cursor-renderer-native.c:1167
9) update_cursor_sprite_texture at ../src/wayland/meta-wayland-cursor-surface.c:70
10) meta_wayland_surface_role_apply_state at ../src/wayland/meta-wayland-surface.c:1869
11) meta_wayland_surface_apply_state at ../src/wayland/meta-wayland-surface.c:832
12) meta_wayland_surface_commit at ../src/wayland/meta-wayland-surface.c:993
13) wl_surface_commit at ../src/wayland/meta-wayland-surface.c:1158
14) ffi_call_unix64 at ../src/x86/unix64.S:76
15) ffi_call at ../src/x86/ffi64.c:525
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2147>
During tear down, if anything teared down after the seat tries to get
the cursor renderer, we'd crash trying to get it as the seat would
already be gone. Avoid this by returning NULL when there is no seat.
It's assumed that any path that will happen during tear down that relies
on getting the cursor renderer will gracefully handle it not being
present, e.g. by relying on the cursor rendering cleaning up itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2147>
Most clients nowadays switched to buffer damage, most notably Mesa
and Xwayland. Thus lets avoid the extra cost of allocating three
`cairo_region_t`s and doing some calculations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2168>
If no viewport is set, the neutral viewport is the surface size
without viewport destination size applied - i.e. transform and
scale applied to the buffer size. Change it accordingly, giving
us the same values we'd return in `get_width` in this case.
As result, this only changes cases where a viewport destination
size but no viewport source rectangle is set.
The change fixes exactly such cases, e.g. the Gstreamer Wayland
sink. Can be tested with: `gst-play-1.0 --videosink=waylandsink`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2168>
When checking panel orientation on logical monitors we should take
panel orientation transform to check it's properly applied, so ensure
that we're checking the right one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2090>
Commit 2289f56112 ("monitor-manager: Don't apply unneeded orientation
changes") added an early return to handle_orientation_change () in case
the transform is unchanged.
But this did not take the correction of the transform for devices
with 90° mounted panels into account causing a desired orientation
change to get skipped if the new orientation matches the corrected
logical orientation from the previous transform setting.
Fix this by calling meta_monitor_crtc_to_logical_transform () on the
transform before comparing it, matching the
meta_monitor_crtc_to_logical_transform () call in
create_for_builtin_display_rotation ().
Related: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1233
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2090>
When Xwayland was not initalized, we'd still clean things up. What this
accidentally meant was that the uninitialized display number 0 was
cleanud up, which very likely was main display of the host session.
What this meant in practice was that /tmp/.X11-unix/X0 was often
removed, causing every Flatpak X11 application to fail to start until
Xwayland was restarted nad the X0 socket file was restored.
Fix this in two ways: firstly only shutdown Xwayland if we ever started
it, i.e. if the X11 display policy was not 'disabled'. This should fix
the issue most of the times. Secondly only clean up the socket if it was
ever initialized. This should fix things if the socket creation failed,
as if it did, the name would be set.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2162>
A popup surface can be remapped multiple times using the same
wl_surface, if a new xdg_popup object is created. To properly handle
this, we need to reset the 'dismissed_by_client' boolean to false, as
otherwise we won't allow new buffer commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1993>
Change to use the headless backend with a virtual monitor, instead of
the nested backend. This means tests can create and use virtual input
devices, which isn't possible with the nested backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1993>
The roundtrip in the handle-configure function could in theory (and in
practice in the future) happen to receive another configure event. If we
send yet another invalid geometry the second time, we log one time too
many in the server, which fails the test. Avoid this by ignoring the
second configure event; it's enough to pass through the error handling
path once.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1993>
We are using internal API that has the benefit of checking that the
focus surface still matches, but has the drawback that it does not
check the MetaWaylandKeyboard state.
In order to fix this, look for keyboard focus and serial matches
specifically when triggering activation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2148>
The GBM support in the NVIDIA driver is fairly new, and to make it
easier to identify whether a problem encountered is related to using GBM
instead of EGLStreams, add a debug environment variable to force using
EGLStream instead of GBM.
To force using EGLStream instead of GBM, use
MUTTER_DEBUG_FORCE_EGL_STREAM=1
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2045
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2132>
We created pipes for the stdout of the spawned mock services. This
resulted in the pipe being filled if enough things were logged, as
nothing was reading from it. Change this to allow for two modes:
verbose - where output is logged to the parent stderr, as well as non-verbose
(default) - where things are logged directly to /dev/null.
This fixes frozen tests when running with --repeat and a high enough
repeat count.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2139>
Since this signal is in a hot path during input handling, it makes sense
not to have this be a signal at all, currently most of the time spent in
it is in GLib signal machinery itself.
Replace it with a function/user data pair that are set on the sprite
itself. Only the places that create an sprite are interested in hooking
one ::prepare-at behavior per sprite, so we can do with a single pair.
This makes meta_cursor_sprite_prepare_at() inexpensive enough.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
Let the meta_cursor_sprite_realize() function return a boolean value
telling whether there was an actual change in the sprite cursor. E.g.
the surface/icon for it changed in between.
This is used in the native backend to avoid converting/uploading again
the cursor surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
This test is injecting input events without checking the correct stage/
device state. Wait for the pointer to enter the stage, so the event gets
correctly forwarded across.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
Listen to changes in MetaWindow::is-alive, so that the pointer
can logically leave the surface as soon as that happens. This
helps prevent flooding the client socket while it is stalled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2122>
Change some things in these "app is alive" checks:
- The dialog timeout is separated from the ping timeout, in order
to show it again at a constant rate after dismissing, despite in
flight pings. It still shows immediately after the first failed
ping.
- As we want to tap further into is-alive logic, MetaWindow now
made it a property, that other places in code can fetch and
subscribe.
- Motion events trigger ping (as long as there was none other in
flight for the same window), and are counted between ping and
pong, in order to preemptively declare the window as not alive
before there is trouble with event queues being overflown.
This results in a separate logic between "the application does
not respond" and "we are showing the close dialog" so that the
former may get triggered independently.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2122>
If we were cancelled, it could mean we teared down, meaning fetching
manager instances will attempt to fetch past freed instances. Handle
this by waiting with the fetching until we know we weren't cancelled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2140>
MetaBackend can now show whether it is in headless mode or not
using a vfunc is_headless.
Fallback of is_headless returns FALSE.
MetaBackendNative implements is_headless returning its
is_headless property.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2130>
This is a strange thing to do since MetaInputMapper also does take care of
devices with an output configured through settings, since we might have
devices that were configure through settings exclude other devices that
belong together with an output (e.g. a display-integrated tablet).
This was essentially here as a last resort to avoid matching two very
similar looking tablets to one of two very similar looking outputs. There
was a 50% chance already that the choice was wrong, and now these devices
can all be configured specifically through settings, so this shouldn't
be missed either.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2107>
Non-display-attached tablets (e.g. Intuos) may find no match, which
should mean "use the span of all monitors", not "pick one for me".
Reserve this fallback to touchscreen devices, since these might
still benefit from it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2107>
The matrix and aspect ratio of the tablet is irrelevant on pads, and
it actually triggers warnings when trying change that on those devices:
gnome-shell:42536): mutter-CRITICAL **: 17:22:41.994: meta_input_device_native_get_mapping_mode_in_impl: assertion 'device_type == CLUTTER_TABLET_DEVICE || device_type == CLUTTER_PEN_DEVICE || device_type == CLUTTER_ERASER_DEVICE' failed
This is unnecessary to do on pad devices, these just need to be moved
together with their respective stylus.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2107>
Since the completion callback (on_switch_workspace_effect_complete) sets
priv->tml_switch_workspace1 to NULL, the unref was trying to unref NULL,
and the reffed ClutterTimeline was not getting unreffed.
This could be triggered by rapidly switching workspaces, switching again
before the animation of the initial switch was done.
Found while working on #2038.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2120>
This avoids the following crash, that could happen in certain rare race
conditions, e.g. in tests:
0) wl_closure_invoke (closure=0x2fbf9e0, target=0x2e5b3d0, opcode=0)
at ../src/connection.c:1014
1) wl_client_connection_data () at ../src/wayland-server.c:432
2) wl_event_loop_dispatch () at ../src/event-loop.c:1027
3) wayland_event_source_dispatch () at ../src/wayland/meta-wayland.c:104
4) g_main_dispatch () at ../glib/gmain.c:3381
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2127>
Passing a NULL workspace does not make sense, since it silently
returns no windows. Mandate that a workspace is explicitly requested,
and while at it check the other arguments as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2124>
The cursor renderer shouldn't assume all the CRTCs of a logical are KMS
CRTC's, as we'll end up checking hardware capabilities for CRTC's of
virtual monitors as well, when they were created to not embed the cursor
image directly in the framebuffer.
Instead, use the newly introduced API for checking CRTC cursor
capabilities. This fixes a crash with the following backtrace:
0) get_plane_with_type_for at ../src/backends/native/meta-kms-device.c:150
1) meta_kms_device_get_cursor_plane_for at ../src/backends/native/meta-kms-device.c:173
2) has_cursor_plane at ../src/backends/native/meta-cursor-renderer-native.c:678
3) foreach_crtc at ../src/backends/meta-logical-monitor.c:247
4) meta_monitor_mode_foreach_crtc at ../src/backends/meta-monitor.c:1920
5) meta_logical_monitor_foreach_crtc at ../src/backends/meta-logical-monitor.c:274
6) crtcs_has_cursor_planes at ../src/backends/native/meta-cursor-renderer-native.c:718
7) should_have_hw_cursor at ../src/backends/native/meta-cursor-renderer-native.c:881
8) meta_cursor_renderer_native_update_cursor at ../src/backends/native/meta-cursor-renderer-native.c:1085
9) meta_cursor_renderer_update_cursor at ../src/backends/meta-cursor-renderer.c:411
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2000183
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1991>
On a KMS backed CRTC, hardware cursor are supported when there are
cursor planes to assign them to. Note that when using legacy mode
setting, fake cursor planes are added when adequate.
On virtual CRTCs, used with virtual monitors, the equivalent of hardware
cursor are always supported, as they are sent using embedded PipeWire
stream metadata.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1991>
This can happen if a texture was newly assigned to the actor, but the
unobscured region hasn't been updated yet. Without bailing here, the
actor would display correctly via direct scanout, but other parts of
mutter would continue considering it obscured, which would e.g. result
in no frame callbacks getting sent for its surface.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1636
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2112>
Previously we chose to only anti-alias texels inside the boundary
(`clip_radius - 1.0`) but zoomed in you could see it was slightly smaller
than the correct curve (#2024).
Similarly if you choose to only anti-alias texels outside that edge
(`clip_radius + 1.0`) then you'd get an overly convex curve that doesn't
match up with the straight line sections.
So now we anti-alias texels that intersect the circle boundary, regardless
of which side they are mostly on. For efficiency we define "intersect" to
mean any texel whose center is within 0.5 of the theoretical edge.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2024
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2102>
It was dropping to zero after the first frame because it hadn't been
incremented high enough. So the second frame would crash with:
```
#0 g_type_check_instance_cast
#1 META_DRM_BUFFER
#2 copy_shared_framebuffer_cpu
```
That's the CPU-copy path (fallback-fallback) that probably no one is using
but it does work after this fix. Exactly the same issue as was fixed
in `copy_shared_framebuffer_primary_gpu` by 36352f44f9.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2104>
A client can create a token without any seat, serial, or surface. In
this case, we'd still try to grab, which would run into some unforseen
code paths, potentially resulting in the following crash:
0) meta_wayland_tablet_seat_device_added (tablet_seat=0x55dff4271c90,
device=0x7f87b80655b0) at
../src/wayland/meta-wayland-tablet-seat.c:200
1) meta_wayland_tablet_seat_new (seat=0x0, manager=0x55dff3ec7b40) at
../src/wayland/meta-wayland-tablet-seat.c:283
2) meta_wayland_tablet_manager_ensure_seat (manager=manager@entry=0x55dff3ec7b40,
seat=seat@entry=0x0) at
../src/wayland/meta-wayland-tablet-manager.c:239
3) meta_wayland_tablet_manager_ensure_seat (seat=0x0, manager=0x55dff3ec7b40) at
../src/wayland/meta-wayland-touch.c:595
4) meta_wayland_seat_get_grab_info (seat=0x0, surface=0x55dff43ff5b0,
serial=0, require_pressed=0, x=0x0, y=0x0) at
../src/wayland/meta-wayland-seat.c:479
5) activation_activate (...) at
../src/wayland/meta-wayland-activation.c:261
Fix this by not trying to grab if not enough parameters was passed when
creating the token. Also add a test case that reproduces the above
crash.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2081>
When an activation times out, we'll be signalled two signals on the
startup sequence object: "timeout", and "complete".
Normally, the "complete" signal is emitted when a startup sequence is
completed succesfully by it being used for activation, and in this case,
the xdg_activation implementation should remove the sequence from the
startup notification machinery.
However, in the timeout case, we should not remove it, as the startup
notification machinery itself will deal with this. If we would, we'd end
up with use-after-free issues, as the sequence would be finalized when
removed the first time.
To avoid this, just clean up the Wayland side in the "timeout" signal
handler, leaving the "complete" signal handler early out if it was
already handled by it.
This avoids crashes like:
0) g_type_check_instance (type_instance=type_instance@entry=0xdd6740)
1) g_signal_handlers_disconnect_matched (instance=0xdd6740, ...)
2) meta_startup_notification_remove_sequence (sn=0x4cc890,
seq=0xdd6740) at
../src/core/startup-notification.c:544
3) startup_sequence_timeout (data=0x4cc890, ...) at
../src/core/startup-notification.c:504
4) g_timeout_dispatch (...) at ../glib/gmain.c:4933
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2081>
We set it via setenv(), and might not have the MetaX11Display at hand.
This fixes a crash when the stuck-client dialog (using zenity) appears
without any X1 client having appeared.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2081>
This test ensures that windows that were resized such that they extend
beyond the screen will be moved to be fully on the screen (if possible).
This has been working on X11 since forever, but on Wayland only since
the last commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2103>
The previous code was trying to detect client resizes by only
considering resizes without any pending configurations as client
resizes. There can however be pending configurations that do not involve
resizing, such as ones triggered by state changes. These may also stay
unacknowledged by the client until the next size change. This was
causing client resizes after showing the window (and therefore changing
its status to focused) to not be detected as client resize.
Fix this by checking whether the queue has any configuration with size
changes rather than just whether it is empty.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2023
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2103>
Used to log multiple line entries. Just make continue prefix things, no
need to mess with maybe-prefixing; it'll just complicate using some less
custom logging functionality.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2094>
If some connectors disappeared, but the rest didn't change, we missed
actually removing the ones that disappeared, as we incorrectly assumed
nothing changed. Fix this by only assuming nothing changed if 1) we
didn't add any connector, and 2) we have the same amount of connectors
as before the hotplug event. The connector comparison checking makes
sure we report changes if anything of the still available connectors
changed.
Fixes: a8d11161b6
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2007
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2097>
When a docking station is disconnected, a few previously existing DRM
connectors may now be gone. When this happens, getting them via the
libdrm API results in NULL pointers returning, and we need to handle
this gracefully by making sure the connector state is properly updated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2097>
The 'stop_after_next' will execeute one command, then not return to the main
loop until a 'continue' command is passed. Commands will still be
processed between 'stop_after_next' and 'continue'.
This is intended to be used to induce race conditions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2066>
Currently the stored unconstrained_rect is only ever updated if there
was a move, resize or state change according to the move_resize_internal
implementation. For Wayland windows however resizes or state changes
are done in two steps, first the new configuration is sent to the client
and then once client acknowledges it, it is set on the mutter side in
another move_resize_internal call. Only the second call would result in
the unconstrained_rect being updated.
This started causing problems when unfullscreening windows was
immediately followed by a strut change. These strut changes started
happening in gnome-shell due to the visibility of the panel now being
considered for the struts and the presence of a fullscreen causing it to
be hidden until unfullscreen. In this situation first the unfullscreen
would resize the window to its pre-fullscreen size as expected, but then
the strut change triggers another window resize. This window resize is
based on the stored unconstrained_rect, which is still at the fullscreen
size because the unfullscreen resize only has sent its configuration,
but it has not been acknowledged yet. As a result the strut change
causes a resize to the fullscreen size which due to the constraints now
looks like a maximized window.
To fix this always update the unconstrained_rect when the requested size
has changed, but not when a previous request has been acknowledged
unless it is originating from the client itself.
If this included the move_resize_internal call from acknowledging the
size as well, it would be possible for this to be delayed long enough on
the client side to overwrite an intermediate resize originating from
mutter. And if this did not include resizes originating from the client,
clients would not be able to set an initial window size.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1973
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2066>
meta_window_wayland_finish_move_resize() is called for both, finishing
a resize that has been requested through/by mutter and for resizes
directly done by the client. This introduces a CLIENT_RESIZE flag to
differentiate the former from the latter. Having this distinction is
required to know what the last requested size by either the client or
mutter is while ignoring older requests that might only have been
applied now.
This excludes client resizes when there are still pending
configurations, because the resize is known to be only temporary.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2066>
Because POSIX sh was, with hindsight, not a particularly well-designed
programming language, if we don't 'set -e', then we'll respond to failure
of a setup command such as cd by carrying on regardless.
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2009>
The assumption here seems to be that it's an overlay onto the
current environment which would make sense; but the implementation in
gnome-desktop-testing currently removes all other environment variables
(see GNOME/gnome-desktop-testing#1). This causes test failure when the
tests are run in Debian's autopkgtest framework, possibly because PATH
is cleared.
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2009>
Systems with AMD GPUs do not take advantage of Mutter's zero-copy path
when driving DisplayLink screens. This is due to a very slow CPU access
to the zero-copy texture. Instead they fall back on primary GPU doing a
copy of the texture for fast CPU access. This commit accelerates texture
copy by working through damage regions only.
Tests on a 4K screen with windowed applications show significant
reduction of GPU utilisation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2033>
If one would end up with an actor attached to mapped actor, where the
attached actor doesn't itself have an up to date stage view list while
listening on the stage for updating, when clearing the stage views of
the list, anything that would query the stage views list at this time
would end up accessing freed memory.
This could happen if
1) An actor was added to a newly created container actor attached to
the stage
2) The actor got a timeline attached to it
3) The actor was moved to a container that already was mapped
4) A hotplug happened
After (1) both the container and actor would not have any stage views.
After (2) the timeline would listen on the stage for stage views
updates. After (3) the actor would still listen on the stage for stage
views updates. When (4) happened, the actor would be signalled when the
stage got its stage view cleared, at which point it would traverse up
its actor's tree finding an appropriate stage view to base its animation
on. The problem here would be that it'd query the already mapped
container and its yet-to-be-cleared stage view list, resulting in
use-after free, resulting in for example the following backtrace:
0) g_type_check_instance_cast ()
1) CLUTTER_STAGE_VIEW ()
2) clutter_actor_pick_frame_clock ()
3) clutter_actor_pick_frame_clock ()
4) update_frame_clock ()
5) on_frame_clock_actor_stage_views_changed ()
6) g_closure_invoke ()
7) signal_emit_unlocked_R ()
8) g_signal_emit_valist ()
9) g_signal_emit ()
10) clear_stage_views_cb ()
11) _clutter_actor_traverse_depth ()
12) _clutter_actor_traverse ()
13) clutter_actor_clear_stage_views_recursive ()
14) clutter_stage_clear_stage_views ()
...
Avoid this issue by making sure that we don't emit 'stage-views-changed'
signals while the actor tree is in an invalid state. While we now end up
traversing tree twice, it doesn't change the Big-O notation. It has not
been measured whether this has any noticible performance impact.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1950
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2025>
Certains keys (such as ~ and |) are in the keyboard map behind the
second shift level. This means in order for them to be input, the
shift key needs to be held down by the user.
The GNOME Shell on-screen keyboard presents these keys separately on
a page of keys that has no shift key. Instead, it relies on mutter
to set a shift latch before the key event is emitted. A shift latch
is a virtual press of the shift key that automatically gets released
after the next key press (in our case the ~ or | key).
The problem is using a shift latch doesn't work very well in the face
of key repeat. The latch is automatically released after the first
press, and subsequent repeats of that press no longer have shift
latched to them.
This commit fixes the problem by using a shift lock instead of a shift
latch. A shift lock is never implicitly released, so it remains
in place for the duration of key repeat.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2045>
The `guess_candidates()` function scores each display that an input
device could be mapped to and then uses the `sort_by_score()` comparator
to find the best option. The function expects the list to be sorted from
best to worst, but the comparator currently sorts them in the opposite
order. This causes the function to end up returning the _worst_ match
rather than the the best. This commit reverses the sort order of the
comparator so that the best display can be returned as intended.
Closes: #1889
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1934>
Mutter already calculates and tracks the damage rectangles to redraw
only areas of the screen that change since the last time a buffer was
used.
This patch extends this by using the EGL_KHR_partial_update extension to
inform the GPU in advance that only those areas will be changed, which
may allow for further optimization.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2023>
This will make clients immediately aware of the output disappearing,
while still allowing for a grace period of 10 seconds for attempting to
bind to it before it turning into a protocol error. This API added as
part of wayland 1.18.
This requires us to not add the output resource to the output resource
list, if the output was made inert. This effectively makes the resource
useless, but that is harmless, since shortly after, the client will
clean it up anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
This will be crucial when we start to remove the global directly when an
output is removed, as that means Xwayland might have removed the output
before we managed to get our queries in.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
We setup Xwayland in an early phase of the X11 display, before we had a
MetaX11Display, and teared down in a couple of places happening when
tearing down the Xwayland integration if the X server died or
terminated. It was a bit hard to follow what happened and when it
happened. Attempt to clean this up a bit, with things being structured
as follows:
* Early during X11 display connection setup, only setup the rudimentary
X11 hooks, being the libX11 error callbacks, and adding the local
user to XHost.
* Move "initialize Xwayland component" code to a new
'x11-display-setup' signal handler. Things setup here are cleaned up
in the 'x11-display-closing' handler.
* Connect to 'x11-display-setup' and 'x11-display-closing' up front,
and stay connected to these two.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
This old handling of session files looked on ~/.mutter, which has
been unused and unsupported for a long time. It also had paths were
the GError was leaked. Fix both by dropping the legacy code, and
falling back to the common error paths.
CID: #1502682
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2061>
When grabbing the devices, there's no error paths that would quit
late enough that both pointer and keyboard would need ungrabbing,
so the keyboard checks were dead code.
Fix this by dropping the boolean variable checks, and adding goto
labels to unroll the operation properly at every stage.
CID: #1418254
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2061>
The monitor orientation tests do a lot of things in sequence. Replace
some of the comments with g_test_message() so that the log from a failed
test gives us a better idea of how far we got.
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2049>
Previously, we were waiting up to 300ms for the signal, then proceeding
anyway. However, 300ms is not necessarily long enough to wait on an
autobuilder that might be heavily loaded, particularly if it's a non-x86
with different performance characteristics.
Conversely, if mutter responds to the D-Bus signal from the mock sensor
before we have connected to the signal, then we cannot expect to receive
the signal - it was already emitted, but we missed it. In this case, we
need to avoid waiting.
One remaining use of wait_for_orientation_changes() that would previously
always have timed out was in
meta_test_orientation_manager_has_accelerometer(), which does not
actually expect to see an orientation-changed signal. Make this wait
for the accelerometer to be detected instead.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/1967
Bug-Debian: https://bugs.debian.org/995929
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2049>
When we use gbm together with the NVIDIA driver, we want the EGL/Vulkan
clients to do the same, instead of using the EGLStream paths. To achieve
that, make sure to only initialize the EGLStream controller when we
didn't end up using gbm as the renderer backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2052>
This switches the order of what renderer mode is tried first, so that
the gbm renderer mode is preferred on an NVIDIA driver where it is
supported.
We fall back to still try the EGLDevice renderer mode if the created gbm
renderer is not hardware accelerated.
The last fallback is still to use the gbm renderer, even if it is not
hardware accelerated, as this is needed when hardware acceleration isn't
available at all. The original reason for the old order was due to the
fact that a gbm renderer without hardware acceleration would succeed
even on NVIDIA driver that didn't support gbm.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2051>
This replaces functionality that MetaRenderDevice and friends has
learned, e.g. buffer allocation, EGLDisplay creation, with the usage of
those helper objects. The main objective is to shrink
meta-renderer-native.c and by extension meta-onscreen-native.c, moving
its functionality into more isolated objects.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
All render devices that have a device file backing them might be able to
allocate dumb buffers, so add a helper for doing that. Will indirectly
result in an error up front on a surfaceless render device due to lack
of a device file.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
It might not be needed by the user of the buffer, so don't always
require it up front. Instead make sure that any user that needs it first
calls "meta_drm_buffer_ensure_fb_id()" to create the ID.
Only the plain gbm implementation creates the ID lazilly, the other
still does it on construction due to the objects used to create them
only existing during construction.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
Mostly calls into gbm_bo_* API, or something somewhat similar when on
dumb buffers. Added API are:
* get offset for plane
* get bpp (bits per pixel)
* get modifier
This will allow users of MetaDrmBuffer to avoid having to "extract" the
gbm_bo to get these metadata.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
The purpose of MetaRenderDevice is to contain the logics related to a
render device; i.e. e.g. a gbm_device, or an EGLDevice. It's meant to
help abstract away unrelated details from where it's eventually used,
which will be by MetaRendererNative and the MetaOnscreenNative
instances.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
Meant for MetaRenderer and everything related that deals with turning
composited frames, or client buffers, into mode set updates. This is
slightly related to the debug topic 'kms' is meant for the KMS details.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
It was a feature relevant for when Clutter was an application toolkit
that wanted the application window to communicate a minimum size to the
windowing system.
Now, clutter is part of the windowing system component, so this feature
doesn't make any sense, so remove it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
This feature was configured depending on whether the Cogl backend
reported COGL_WINSYS_FEATURE_MULTIPLE_ONSCREEN or not. All cogl backends
do report this, so any code handled the 'static' case were never used.
While we only ever use one stage, it's arguable more correct to
consilidate on the single stage case, but multiple stages is something
that might be desirable for e.g. a remote lock screen, so lets keep this
logic intact.
This has the side effect of completely removing backend features, as
this was the only left-over feature detection that they handled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
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>
In various places we retrieved the default seat from the ClutterBackend.
All the clutter backends implement this by calling
meta_backend_get_default_seat() which will then return
MetaBackendPrivate::default_seat.
Lets avoid this by fetching the default seat directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
