The debug controller can optionally, when passing --debug-control,
enable manipulating debug state, so far enabling/disabling HDR, via
D-Bus.
It's always created, in order to have a place to store debug state and
emit signals etc when it changes, but so far, it doesn't have its own
state it tracks, it just mirrors that of the monitor manager.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3432>
While we should ideally have a sensible cursor theme, handle the
case of cursor themes that lack certain cursor names, and fallback
to the 'default' cursor in those cases.
The 'grey rectangle' fallback is still left, in case we even fail
to load a 'default' cursor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3295>
When a stream is destroyed by a consumer, mutter won't be able to
recognize that.
For mutter, the stream just paused, but did not disconnect, because the
connection state of a PipeWire stream only represents, whether the
respective PipeWire context is connected to PipeWire.
In addition to that, it may be the case, that the stream consumer just
recreates the stream.
So even if mutter would be able to know, when the stream consumer
destroyed a stream, but not the whole screencast or remote-desktop
session, then mutter would not know, whether the stream will be resumed
eventually or not.
So, add an explicit API call to the screencast interface to stop a
stream.
For virtual streams, this also means, that the respective virtual
monitor is destroyed.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2889
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3307>
When a virtual stream is destroyed, its respective virtual monitor is
destroyed too. When the virtual monitor is destroyed, mutter reloads
the monitor manager.
However, at this point, the virtual stream is not completely destroyed
yet. The viewport of the virtual monitor still exists at this point and
when the monitor manager reloads, it will try to fetch the logical
monitor of the now destroyed virtual monitor, which will fail and thus
gnome-shell will run into a segfault.
Fix this situation by reloading the monitor manager in an idle callback.
When the monitor manager reloads, the virtual monitor is completely
gone, since the viewport of the virtual monitor is destroyed after the
virtual monitor itself.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2864
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3307>
There is no way to set any gamma luts, or do anything other color
management related. Eventually we'll probably want to, but that requires
bringing color management plumbing to PipeWire.
Doing this is also needed when running a headless session, as when
headless, polkit doesn't let us create colord devices without explicit
user permission, meaning we'll spam the session with useless dialogs
each time a session is started.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3423>
Given destruction order, the display goes away before the stage, so
this lingering signal connection may trigger unintended crashes.
Fixes: 05eeb684d1 ("window: Postpone focusing until grab ended if uninteractable")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3422>
`count_mode_setting_devices` was incorrect in both name and in function.
What it was actually doing was counting GPUs that had been registered with
the backend so far (during the `init_gpus` loop). What it was intended to
do was to count the number of `MetaRenderDeviceEglStream` instances, which
is the thing we're limited to only one of. So `count_mode_setting_devices`
would return zero whenever the first GPU initialized happened to be a
`MetaRenderDeviceEglStream`, which would in turn prevent
`MetaRenderDeviceEglStream` from successfully initializing. Seems it only
ever worked in the case of a hybrid system where the first GPU initialized
was GBM-based.
Now we count `MetaRenderDeviceEglStream` instances (zero or one) externally.
This allows initialization to succeed when it happens to be the first (or
only) GPU. And so `MUTTER_DEBUG_FORCE_EGL_STREAM=1` now works.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2905>
For scanout on a secondary GPU, for the time being try only formats
which are guaranteed to be renderable with GLES3, which notably excludes
10 bpc formats without alpha channel.
v2:
* Use separate format array for 10 bpc formats without alpha.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3139>
If the EGL_KHR_no_config_context extension is supported, use it to
choose a format per onscreen which is compatible with the scanout CRTC
and the GL rendering API used.
Suggested by Jonas Ådahl.
v2:
* Drop code which checked for GLES3 renderability. Makes no sense for
various reasons, in particular that EGLconfigs are about EGLSurfaces,
whereas secondary GPU contexts use an FBO for blitting.
* Use error parameter directly for meta_renderer_native_choose_gbm_format
call (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3139>
Preparation for the following commits, no functional change intended.
v2:
* Pass through MetaEgl pointer
v3:
* Make it return gboolean (Robert Mader)
v4:
* Add debug logging and corresponding purpose parameter
v5:
* Fix excessive function parameter indentation (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3139>
Split the struct into mutable and immutable parts. Access the mutable
parts via getters and the immutable parts via a single struct. This
avoids copying around the immutable parts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3280>
In profilers with a timeline or flame graph views it is a very common
scenario that a span name must be displayed in an area too short to fit
it. In this case, profilers may implement automatic shortening to show
the most important part of the span name in the available area. This
makes it easier to tell what's going on without having to zoom all the
way in.
The current trace span names in Mutter don't really follow any system
and cannot really be shortened automatically.
The Tracy profiler shortens with C++ in mind. Consider an example C++
name:
SomeNamespace::SomeClass::some_method(args)
The method name is the most important part, and the arguments with the
class name will be cut if necessary in the order of importance.
This logic makes sence for other languages too, like Rust. I can see it
being implemented in other profilers like Sysprof, since it's generally
useful.
Hence, this commit adjusts our trace names to look like C++ and arrange
the parts of the name in the respective order of importance.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3402>
Now that the monitor screencast records to DMA-BUF buffers immediately
(since bc2f1145d8), and we know which phase of the paint rountines we
are (since last commit), we have the opportunity to bring back the
blitting technique.
Bring back blitting. This time, instead of simply failing if the blit
fails, add a fallback path that does a stage paint if something goes
wrong. Unlike the previous implementation of blitting, this one only
blits the current view - it does not blit all views that intersect
with the screencasted monitor.
Embedded cursors should still be fine because hardware cursor is
inhibited while embedded cursor screencasts are running.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3406>
Track where we are in terms of the paint cycle. Do this through an
enumeration that is passed through the paint vfuncs of screencast
sources.
Right now, this information is not used by any one of the sources,
but next patch will use it to prevent blitting when detached from
the paint cycle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3406>
With the existing ClutterInputMode terminology (inherited from XI2),
hardware devices may be "physical" (i.e. attached to a logical device),
or "floating" (i.e. detached from all logical devices).
In the native backend, tablet devices are closer to "floating" than
"physical", since they do not emit events relative to the ClutterSeat
pointer logical device, nor drive the MetaCursorTracker sprite. This
is in contrast to X11 where all tablet devices drive the Virtual
Core Pointer by default, along with every other pointing device.
Change this mode in the Wayland backend to be more coherent. The
existing checks on the ClutterInputMode along Mutter seem appropriate
for handling these as floating devices, since they mainly care about
logical vs non-logical.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3393>
The window actor can be mapped every frame, e.g. when it is dragged in
the overview. This commit keeps track when the geometry changed and we
didn't managed to sync the geometry yet and need to sync it at a later
time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3404>
At the end of the sync_actor_geometry function the window buffer_rect
and the WindowActor position and size are the same and consistent.
Call the virtual method at the end and let the implementations look at
either the buffer_rect or the actor position/size itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3404>
In some cases the window is not mapped when the geometry changes.
Without the mapped window the surfaces are not mapped either and don't
have a sensible allocation.
This patch makes sure we abort syncing the geometry if the window is not
mapped and also make sure we sync geometry when the actor eventually
does get mapped.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3152
Fixes: 8f4ab53bd ("window-actor/wayland: Ensure to use allocation for black background check")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3401>
Scoped traces are less error prone, and they can still be ended
prematurely if needed (this commit makes that work). The only case this
doesn't support is starting a trace inside a scope but ending outside,
but this is pretty unusual, plus we have anchored traces for a limited
variation of that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3396>
Allow only specific files to use those deprecated APIs making
it easier to find where deprecated APIs are still in use
and avoid introducing new usages without being noticed
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3400>
Group all the three config files from clutter/cogl/meta into one
and also remove unnused configurations and replace duplicated ones
This also fixes Cogl usage of HAS_X11/HAS_XLIB to match the expected
build options
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3368>
Currently, json-glib is used for two things:
- For loading scripts, nothing seems to use that in real life other
than some tests
- For debugging paint nodes
For now, the PR drops the first use case and only require json-glib
if it is a debug build
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3354>
We don't actually need the host to be a container, so simply work on
actors saving us a few casts.
This'll simplify dropping ClutterContainer entirely later, and
StViewport/ShellWindowPreviewLayout will also need to be updated for the
new signatures
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3384>
Sticky keys configuration changes reset the pressed modifier state mask,
even though the XKB state might already match with the expected new
state. In those cases we can avoid the XKB state mask update completely.
This also fixes a crash at initialization with sticky keys toggled on,
since configuring the device a11y settings will trigger a XKB state
mask merely reassuring the initial state with no modifiers pressed,
while the connection between the ClutterSeat and the impl object has
not been set up yet. This crash was introduced by commit 00bb4190b
("backends/native: Drop device_native->seat_impl field").
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3392>
Tests that
* the window under the cursor has focus
* focus_default_window won't move the focus away from a previously
focused window even if the cursor is somewhere else
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
When the desktop is focused instead of a window we want to tell the core
about this to handle focus-mode mouse. This is handled by looking for
CLUTTER_LEAVE events where the newly focused window is NULL.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
Take a reference to the window to make sure the MetaFocusData->window
pointer is not pointing to a freed object.
Also make sure that the window that we want to focus is not currently
unmanaging.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
On X meta_window_handle_enter was called when the desktop window was
entered. On wayland the "desktop" is no window anymore. We still want to
inform the core that the desktop is focused, so it can unfocus windows
if focus-mode is mouse.
This commit prepares the core for handling a NULL windows to mean the
desktop.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
The following commits will make it possible to pass a NULL window to
display_handle_window_enter/leave to represent the cursor entering the
desktop. This means it can't be a method of the window class anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
If we have an existing focused window that may have focus, default focus
will leave the focus there. An unmanaging window for example must not
have focus and default focus will continue to select another window in
this case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
The layout manager takes the generic ClutterActor expand/align
properties into account. Everyone should already use those instead
of the custom layout/child properties, so removing them should have
little fallout, while making for a nice cleanup.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3382>
It tests various sub-surface corner cases. It would fail without the
previous fixes.
v2:
* Fix draw_descendant parameter formatting
* Make toplevel window fullscreen (Robert Mader)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
To make sure a new wl_subsurface created for the same wl_surface won't
inherit the position from the wl_subsurface being destroyed.
v2:
* Move into permanently_unmap_subsurface
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
Instead of duplicating the code in both.
v2:
* Rename helper to make it clear(er) that it permanently unmaps the
sub-surface
* Move transaction allocation & commit into the helper
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
wl_subsurface_place_above/below need to hook it up to the parent
surface's pending state, so that it gets picked up next time the parent
is committed.
v2:
* Adapt to wl_subsurface_destructor not resetting sub-surface position
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
This is simpler, and makes sure it's called only once for each surface
in the transaction as committed.
v2:
* Use array for surface states with placement ops (Jonas Ådahl)
v3:
* Use GPtrArray instead of GArray (Robert Mader)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
This is necessary to make sure the unmapped sub-surface is no longer
visible.
v2:
* Use META_IS_WAYLAND_SUBSURFACE (Jonas Ådahl)
* Use same sequence of assignments in both cases
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
meta_display_ping_window() does nothing when check-alive-timeout is set
to 0, but meta_window_check_alive_on_event() was relying on it to reset
the events_during_ping. Without this events_during_ping was just
counting up until the threshold was reached and the window was marked as
not alive, preventing further pointer events from being sent to the
window.
Fix this by not doing anything in meta_window_check_alive_on_event() if
check-alive-timeout is 0, similar to meta_display_ping_window().
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3142
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3367>
Locked modifiers should probably not have an effect on keybindings
while toggled. this is most relevant for modifiers that can be
either/both pressed or locked (e.g. Caps Lock key), if used in
keybindings.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3369>
This struct contains the pressed/latched/locked set of modifiers applying
to the event, and may be filled in by backends generating those events.
Other places where we forward modified key events, state may be normally
obtained from the original event.
Since this constructor is used in a variety of places, this commit
updates them all in one go.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3369>
If multiple sync events are send in the same dispatch, a further call to
wait_for_sync_event will get stuck. Fix this by keeping track of the
latest sync event serial in the display and always compare against that.
This also means sync event sequences must start at 0 and increase by 1.
The wayland-x11 interop test is the only one where that wasn't already
the case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3358>
Currently, we use cairo_region_t despite it being a thing wrapper around pixman_region_32
In order to push for a cairo-less and wayland only build in the future, replace
cairo_region_t with a thin wrapper that is almost a copy of the upstream cairo implementation
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3292>
Whenever a MetaWaylandTestClient exists without success the calling test
will fail. This fixes a bunch of cases where the test would get stuck
waiting for some event from the client when it already died and won't be
able to send the event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3348>
The test and dist CI jobs run wrap the meson calls in dbus-runner to
avoid setting up dbus servers and mocking services for every test but
the dbus-runner invocation from meson test didn't actually skip all the
setup.
This nested mocking also doesn't work because the system bus is assumed
to be the host system bus and not a mocked one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2618>
This means one can run meta-dbus-runner.py effectively mocking
everything relevant except logind itself, meaning one can run from a TTY
and get permission to mode set etc, while still mocking things like
gsd-color, colord, etc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2618>
Make CoglBuffer an abstract class and inherit the various Cogl*Buffer types from it.
As none of the subclasses is overriding the vtable functions, they were not turned into
vfuncs but plain function pointers in CoglBuffer.
We still use _cogl_buffer_initialize until we port the various params into actual construct-only
properties, similar to the previous commit for CoglTexture.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3193>
- Make Texture a parent GObject class and move the vtable funcs as vfuncs
instead of an interface as we would like to have dispose free the TextureLoader.
- Make the various texture sub-types inherit from it.
- Make all the sub-types constructors return a CoglTexture instead of their respective
specific type. As most of the times, the used functions accept a CoglTexture,
like all the GTK widgets constructors returning GtkWidget.
- Fix up the basics of gi-docgen for all these types.
- Remove CoglPrimitiveTexture as it is useless: It is just a texture underhood.
- Remove CoglMetaTexture: for the exact same reason as above.
- Switch various memory management functions to use g_ variant instead of the cogl_ one
Note we would still want to get rid of the _cogl_texture_init which is something
for the next commit
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3193>
The helper doesn't do anything that makes it worth
to be exposed as public API. End-users, such as GNOME Shell could have
an in-tree helper if they end up using it that much.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3086>
The shell might raise and make windows recent for another workspace when
an app gets activated on another workspace. Making the windows only
recent on the current workspace thus results in inconsistent focus when
another window of the same app is closed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3315>
There are existing extensions that implement desktop icons as
a combination of a GTK program and a small extension to make
the wayland window behave as if it was of type DESKTOP on X11.
That's quite painful, as it requires reimplementing WM behavior
that is already implemented in mutter itself (stacking, stickiness,
skip-taskbar, ...), as well as modifying gnome-shell to consider
the window in addition to "real" DESKTOP windows (workspace-switch
animations, ctrl-alt-tab, ...).
In addition to that, other extensions may also have special handling
of DESKTOP windows, and their code cannot easily be monkey-patched
to handle "alternative" desktop icons.
This whole game of whack-a-mole can easily be avoided by allowing
desktop-icons extensions to mark their desktop windows as DESKTOP,
so do just that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3305>
Assigning the corresponding stack layer of DESKTOP windows is
currently X11 specific, because there is no way for wayland
clients to set the DESKTOP window type.
This is about to change, so move the code to the generic layer
handling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3305>
Change the order of events to adhere to the Wayland specification for
wl_keyboard.enter, which mandates:
> The compositor must send the wl_keyboard.modifiers event after
> this event.
Mutter currently sends the modifiers event before the enter event,
which may break applications that require information about the focused
surface in order to properly handle the modifiers.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2231
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3341>
These functions ends-up calling gdk-pixbuf for loading textures/bitmaps
from a file and they don't seem to be used anywhere.
These changes are only useful with the following up commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3097>
Create a fake monitor region right of the right-most monitor and if a
horizontal barrier extends into that region, fail the barrier. Barriers
are aligned on the top/left edge of the pixel so the most natural
barrier of (e.g. 0-1024) is also wrong - it's one pixel into the next
monitor.
Check this for nonexisting screens on the right too to avoid clients
suddenly failing when multiple monitors are present.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3319>
Assuming two 1920x1080 screens next to each other: a horizontal barrier
starting at 1920 going east is always outside the left screen.
Assuming two 1920x1080 screens on top of each other: a vertical barrier
starting at 1080 going south is always outside the top screen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3319>
When running headless, only the invalid modifiers are advertised.
That breaks with the NVIDIA proprietary driver which then rejects the
buffers created with the invalid modifier, and that kills Xwayland,
meaning that running Xwayland on top of a mutter based compositor
headless is not possible.
The reason the modifiers are not sent is because AddFb2 is not supported
when running headless.
Other compositors (weston, wlroots) would still send the modifiers even
without AddFb2, and Xwayland works fine on those compositors when
running headless.
Remove the requirement for AddFb2 to send the modifiers, so that
Xwayland can work fine on top of mutter headless with the NVIDIA
proprietary driver.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3060
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3320>
`clutter_actor_destroy()` queues a stage update. Under certain
circumstances - i.e. when run in a very slow container - this can race
with the stage update triggered by the following
`clutter_virtual_input_device_notify_button()`, occasionally resulting in
`wait_stage_updated()` to return before the
`on_event_return_propagate()` callbacks ran, making the test fail.
This notably became more common since
8f27ebf87e (clutter/frame-clock: Start next update ASAP after idle period)
landed.
Thus wait for a stage update to happen after `clutter_actor_destroy()`,
preventing the race.
Fixes: f6da583d06 (tests/clutter/event-delivery: Add tests for implicit grabbing)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3332>
Instead of g_get_monotonic_time. This makes sure last_presentation_time_us
advances by refresh_interval_us.
Doesn't affect test results at this point, but it will with the next
commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3174>
Certain kernel drivers can take an unreasonably long time to
complete mode setting operations. That excessive CPU time is charged
to the process's rlimits which can lead to the process getting killed
if the thread is a real-time thread.
This commit inhibits real-time scheduling around mode setting
commits, since those commits are the ones currently presenting as
excessively slow.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3037
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3324>
At the moment if a thread is made real-time there's no going back,
it stays real-time for the duration of its life.
That's suboptimal because real-time threads are expected by RTKit to
have an rlimit on their CPU time and certain GPU drivers in the kernel
can exceed that CPU time during certain operations like DPMS off.
This commit adds two new ref counted functions:
meta_thread_{un,}inhibit_realtime_in_impl
that allow turning a thread real-time or normally scheduled. At the same
time, this commit stores the RTKit proxy as private data on the thread
so that it can be reused by the above apis.
A subsequent commit will use the new APIs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3324>
Most of the code writes "real-time" as "realtime" not "real_time".
The only exception is one function `request_real_time_scheduling`.
This commit changes that function for consistency.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3324>
If we queued a mode set, but didn't end up compositing all frames, we'll
have pending mode sets in a hash table waiting to be applied. If we
before all monitors again try to reconfigure things we should drop the
old pending mode sets and start fresh.
We already do this when we're doing so when generating views, but when
just unsetting modes, we didn't, so fix that.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2242612
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3318>
We had a function called "reset_modes()" on MetaRendererNative, but what
it expected to do was to unset all modes on all CRTCs. Despite this, it
had code to unset modes on unconfigured CRTCs, probably because it was
used for multiple things in the past.
Make this a bit easier to follow by renaming the function
"unset_modes()" and fold the function doing the unsetting into the
function itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3318>
Intel has started to advertise big gamma LUT sizes on some hardware
because the hardware supports segmented LUTs. This means they have a lot
more precision at certain segments then others. The uAPI can't expose
this functionality meaningfully so they chose to expose a huge number of
TAPs to sample from to their segmented LUT.
This increase in uAPI LUT size resulted in stack overflows because we
allocated the LUT on the stack. This commit moves it to the heap
instead.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3064
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3322>
1. Centralize stride calculation in one function.
2. For dmabufs query the stride instead of assuming a certain value.
3. For system memory buffers use the pixel format to calculate the
stride.
4. Stop negotiating `SPA_PARAM_BUFFERS_size` and
`SPA_PARAM_BUFFERS_stride`.
2. fixes an actual bug where we reported wrong max buffer sizes,
resulting in crashes in Gstreamer when doing area screencasts on AMD
GPUs.
The reasoning for 4. is that the values were possibly wrong for
dmabufs as the negotiation happens before we create any buffers.
Further more neither Mutter nor the common consumers required it.
The later either ignore the values (OBS), always accept (gstpipewiresrc)
them or calculate the exact same possibly wrong values (libwebrtc).
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6747
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3311>
With EI support wired to XTEST, and oeffis being enabled in Xwayland
means that XTEST will always go through the XDG portal.
While this the intended behavior for the general use case of Xwayland
running rootless on a desktop compositor, that breaks when Xwayland is
running on a nested compositor, because the portal is for the entire
session and not limited to the nested Wayland compositor.
Enable XDG portal support in Xwayland only when we managed to connect
to the GNOME session manager, which means we are running in a full
desktop session, and not in any form of nested mode.
This is determined by simply using the status returned by set_gnome_env()
which will fail if not connected to a GNOME Session manager.
See-also: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1586
See-also: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1170
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3047
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3303>
The function set_gnome_env() is used to pass environment variables
though DBus using the "org.gnome.SessionManager".
If that fails, it means we are not running in a full environment, which
might be useful to determine whether Xwayland should enable the portal
support.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3303>
This makes sure the new update takes effect over the pending update for
any common properties. It matches the other users of
meta_kms_update_merge_from.
Fixes: 27ed069766 ("kms/impl-device: Add deadline based KMS commit scheduling")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3316>
When a configuration has a fractional scale, but we're using a physical
monitor layout, we can't use the scale, but if we do, we end up with
wierd issues down the line. Just discard the config if we run into this.
Eventually we probably want to store the layout mode in the
configuration so we can handle more seamless switching between physical
and logical layout mode, but first do this.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3057
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3299>
The surface actors may not have a valid allocation when running the
test. The preferred height, which `clutter_actor_get_size()` returns
in that case, can be wrong in certain cases, making us not add the black
background when it's actually needed.
Query the allocation instead, even at the expense of additional
relayouts.
While on it, sneak it some small cleanups.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3024
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3310>
There's two aspects from its documentation
(https://xkbcommon.org/doc/current/group__state.html#gae56031a8c1d48e7802da32f5f39f5738)
affecting us here:
1. "This function is similar to xkb_state_key_get_syms(), but intended for
users which cannot or do not want to handle the case where multiple
keysyms are returned (in which case this function is preferred)."
We are indeed in that field, and have been for a long time.
2. "This function performs Capitalization Keysym Transformations."
This is unlike the xkb_key_get_syms() function that we use, and
convenient here for parity with X11 since it behaves exactly that
way.
Fixes cases where the keysym for some keys is not properly capitalized
when caps lock is toggled, due to the output of capslock+key being
different from shift+key. An example of this is 'é' in french(azerty)
layout (bound to the '2' key). Even though shift+2 outputs '2',
capslock+é should output 'É'.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3058
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3306>
This is similar, but reserved for the crossing events induced by the
input shape changes on our overlay window. The mechanism in the previous
commit does again protect against this, so this mechanism may go away.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3267>
Focus follows mouse is meant to avoid focusing windows that happened
to pop up under the pointer, e.g. due to mapping, workspace changes,
etc... On X11, this has been done since ancient times through a
moderately complex synchronization mechanism, so mutter would know
to ignore crossing events caused on those situations.
This mechanism is much prior to XInput 2 though, where we may know
this in a more straightforward way: If the sourceid of the crossing
event is a logical pointer (i.e. equals deviceid), the crossing event
was triggered logically, and not through user input.
Perform this simpler check, and drop the existing mechanism to
ignore logically induced crossing events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3267>
The virtual stream source with CURSOR_MODE_EMBEDDED uses
META_STAGE_WATCH_AFTER_PAINT as the callback for recording its frame. In
this stage of the paint though, there is no ClutterPaintContext anymore
(there only is a paint context during the paint, not afterwards).
The callback (actors_painted()) tries to get the redraw clip from the paint
context, and we end up with a NULL pointer crash.
We actually do still have a redraw clip at this point, so because everyone
uses the paint context to get the redraw clip anyway, just pass the redraw
clip to the stage watches directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3283>
After an event has been handled such that it bypasses both Clutter and
Wayland, e.g. when handling a keybinding, bypass_clutter would get
unset in the presence of a wayland grab. This means that the event is
handled both as a keybinding and by Clutter.
In the case of switcher popups in gnome-shell in the presence of a gtk4
autohide popover this meant that instead of selecting the next element,
it would select the one after that. If there are only two elements, as
is common with input sources, this would mean going back to the current
one, preventing switching them with a single press of the keybinding.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6738
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3054>
When a device is added, libei does not allow adding additional regions
for that particular device, as it is already advertised to the EI
client.
As a result, mutter currently effectively only adds the first region to
a device, but not the others.
This makes input in multi monitor sessions only possible on one monitor,
as the EI client cannot look up the other regions, since they were not
advertised to it.
Fix this situation by not adding and resuming the device, when a shared
device is used.
Instead, for shared devices, always add all regions first, and then
after that, add and resume the device.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3273>
Use the previously added API to release acquired mapping ids, when the
corresponding stream is destroyed.
Otherwise, the remote desktop session would maintain a whole bunch of
unused mapping ids, as their corresponding streams are already
destroyed, but maybe not the session.
Such situation would be a remote multimonitor session, where the amount
of used virtual monitors changes multiple times during the session.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3273>
The remote desktop session currently provides a mechanism to acquire
mapping ids.
However, when they are not used anymore, they currently cannot be
removed and thus just linger around.
So, add an API to release these acquired ids.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3273>
Avoid passing the MetaSeatImpl, since it may be potentially null at
MetaSeatNative construction time. An example of this triggering issues
are mousekeys, since those work on an emulated pointer device created
indirectly after a keyboard device is added (and the right settings are
enabled) at a time that the MetaSeatImpl is still being created, so the
MetaSeatNative cannot yet have a reference to it.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2869
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3278>
These objects already have a pointer to the ClutterSeat that has a
pointer to the MetaSeatImpl in its native implementation. This data
may be considered pretty much immutable (a pointer to the seat is
held, and the native implementation will shut down the implementation
thread within ClutterSeat finalization.
Avoids some awkward code, since the MetaInputDeviceNative needs to
be aware of the Clutter object implementation and the implementation
object.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3278>
vc4's implementation of `drmModeAtomicCommit` seems to require a few
milliseconds advanced notice or else it will miss the frame deadline.
That's too high for our deadline evasion threshold which is measured
in microseconds. Let's stop trying to use deadline timers on vc4 to
avoid this conflict without having to disable atomic KMS.
Suggested-by: Jonas Ådahl <jadahl@gmail.com>
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2953
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3279>
It's the 10 bit equivalent to NV12 and uses the same layout as P016, i.e.
16 bit components with the lowest 6 bits set to 0 (padding), allowing us
to use 16 bit "subformats".
Thus adding support is quite trivial as we can reuse the NV12 shader.
The format is widely supported in decoding and display hardware (on Intel
since Kaby Lake), as well as modern codecs (AV1, VP9, HEVC) and has
visible quality advantages over NV12.
Note that the additional colors are lost if composited to a 8 bit RGB
framebuffer. Switching between direct scanout and compositing can thus
cause quality differences. This is no new phenomena, however, as the
same is the case already for e.g. GL clients using 10 bit formats -
including video players.
Also note that P012 and P016 could trivially added as well - it's not
done here as they are uncommen and thus hard to test.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3244>
These shaders can be used for similar formats with other component
sizes since the values are represented as floats. So whether the source
value was stored in 8bit, 10bit or 16bit doesn't matter - the driver
will covert it for us.
Thus use a Weston-inspired, more general naming scheme.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3244>
They are needed as "subformats" for higher bit YCbCr formats, such as
P010, and we don't plan to use or expose them otherwise. Thus don't
implement any conversion or packing features.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3244>
Realizing a cursor will assume view related state objects are valid so
they can mark them as dirty. This assumption broke when there were a
scale changed that happened with multiple CRTCs, as we'd create view
object by view object as we realized the texture. Realizing the texture
would trigger a signal that had the handler assuming the validity of all
view objects, but if we only had gotten to the first, the second view
would not be there yet, thus we'd be doing a NULL pointer dereference.
Creating the view objects first, then handling the updating avoids this
problem by making the already done assumption valid on hotplugs.
The test case added tests exactly this series of events, and uses a
virtual monitor as a cheap trick to make the KMS CRTC based view the
first one, and an arbitrary view the second that previously had its view
object initialized too late.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3012
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3262>
The cursor surface is decided by the "current" surface; if that alone
changed (e.g. current surface was destroyed), we didn't update the
cursor, meaning it either got stuck, or got hidden if the client exited
completely.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3262>
It's hard to tell why turning on HDR mode failed without these log
messages. It could be missing support in the sink (EDID/DisplayID) or
missing support in the driver/display hardware (connector properties) or
just a failure turning it on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3251>
