This object is a windowing-specific implementation of MetaSessionState,
allowing to save window state for toplevel surfaces of a Wayland client
using the xdg_session_management_v1 protocol.
This object is detached from windowing logic itself, and will be
integrated in later commits.
Changes from Carlos Garnacho: Integrate state serialization with
MetaSessionState and MetaSessionManager.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3825>
Make this core object own the MetaSessionManager, for the window management
code to access.
At this level, we will be able to integrate with systemd notification
system, and use systemd fdstore to keep the mapped memory warm for
us for the case of soft reboot. This is at the moment not implemented
here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3825>
This core object will be the manager of "client sessions", allowing
the windowing-specific paths to generate MetaSessionState objects to
track their clients.
This object is unused at the moment, and will be integrated in later
commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3825>
This is an abstract base class to implement a "client session",
carrying the accounting of the windows, and allowing to serialize/read
their state into a Gvdb table.
Since different windowing backends may require slightly different
data to be saved for each window, this is meant to have windowing-specific
implementations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3825>
A nick property is a bit similar to the nick of a GObject property, in
that it's a shorter version of the name. It's intended to be used to
store state on the file system, where the state depends on the desktop
environment being used. E.g. gnome-shell sets the name "GNOME Shell",
which is, if no nick is explicitly set, transformed into the nick
"gnome-shell", which will be used for file paths.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3825>
Preparation for next commit, which may merge multiple KMS updates with
sync_fds for modesets. Waiting for all sync_fds to signal before
processing the merged KMS update would be rather involved, for now just
leave implicit sync enabled for it. We're still relying on implicit sync
for modesets in general anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3999>
Now that we copy this into a temporary XDG_DATA_HOME, we don't need
to have it duplicated in the source tree as well.
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4012>
Previously these tests tried to write to /usr when run as an
installed-test, which happens to work on Gitlab-CI because we're running
as root inside a container, but will not work when running in a more
realistic scenario as an unprivileged user (which is how Debian's
autopkgtest framework runs this test suite).
This also avoids leaving non-package-manager-managed detritus in /usr.
In color-management-tests, we can just delete the code that sets
XDG_DATA_HOME.
In color-management-profile-conflict-test, we also need to copy
the conflicting vx239-calibrated.icc into the temporary XDG_DATA_HOME
to get onto the code path that this test is intended to exercise.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/3658
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4012>
g_array_sized_new() creates a new GArray with a preallocated size, but,
after creation, the array length is still zero [1].
Store the modifiers in a EGLuint64KHR array and use g_array_new_take()
to create a new GArray with the correct size.
Because no modifiers were returned, gbm_surface_create() was used
instead gbm_surface_create_with_modifiers() on multi-GPU setups.
[1] https://docs.gtk.org/glib/type_func.Array.sized_new.html
Fixes: aec85281ba ("native/renderer: Retrieve the right modifiers set for each GPU")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3998>
When a surface is destroyed, the existing feedback surfaces are marked
as inert by setting the wl_resource user_data to NULL. This wasn't
handled in the feedback surface destructor.
Fixes: 2341346c90 ("wayland: Implement the color management protocol v4")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4000>
The tablet tool is initialized with a device but if that device is later
removed we never update tool->device. This eventually causes a crash
when we're passing that device into
meta_wayland_input_invalidate_focus().
The tool keeps track of the current tablet anyway so instead of caching
this pointer in the tool, use the current tablet's device.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3642
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3959>
`(int) (1.0f * (float) INT_MAX)` doesn't necessarily result in INT_MAX
due to how floating point arithmetics. Handle this better by setting
INT_MIN/MAX explicitly, when the floating point value post scaling
exceeds the corresponding limit.
This fixes resizing of electron windows.
Fixes: 6e8c7c5f84 ("Add experimental mode to use native scaling of Xwayland clients")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3997>
Meson variables don't have a scope, so using `prefix` in a loop
for D-Bus interface prefixes actually overshadows the global
variable that holds the build prefix.
As far as I can tell, the only place where the "wrong" value is
read is the build summary, but let's not tempt fate and fix it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3995>
The value returned by meta_frame_get_frame_bounds() is owned by the
caller so we can assign it directly without copying to avoid a leak and
a bit of unnecessary work. Also it can't ever return NULL, so there is
no need to check for that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3994>
As with Xsettings, we want to use the X11 UI scaling factor to set the
cursor size, so that clients use a larger theme, both when using
`native-xwayland-scaling` and a physical layout mode.
Fixes: 6e8c7c5f84 ("Add experimental mode to use native scaling of Xwayland clients")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3992>
This makes Xsettings tell clients to be HiDPI again, when using the
physical layout mode.
Fixes: 6e8c7c5f84 ("Add experimental mode to use native scaling of Xwayland clients")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3992>
This is different from MetaSetting's UI scaling factor, and different
from the effective Xwayland scale.
The MetaSetting's UI scaling factor is the scaling factor used by
gnome-shell chrome itself.
The effective Xwayland scale is, with `native-xwayland-scaling` enabled,
the scale everything X11 is scaled with.
The X11 UI scaling factor is intended to be the scaling factor X11
clients are told to use, and how to derive that differs depending on the
layout mode and the effective Xwayland scale.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3992>
When !3952 introduced the new tracing macros, they were only defined in
the HAVE_PROFILER case, causing builds without profiler support to fail.
Also it introduced an unconditional call to cogl_is_tracing_enabled()
which is not available without HAVE_PROFILER.
Fixes: 777c63507 ("cogl/trace: Allow defining and setting sysprof trace counters")
Fixes: 322ac42a6 ("stage-impl: Trace the damage region")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3991>
It is intended to replace using GetResources() and ChangeBacklight().
It moves from a normalized 1-100 numbers, to directly exposing the
hardware. This more closely maps to how gsd-backlight.c in
gnome-settings-daemon normally works, and simplifies the API a bit to
not have to deal with rounding issues.
There is still no KMS uAPI for this, so it still only hooks up to
XRANDR. Being private API, it doesn't try very hard to predict how the
KMS uAPI will look. When that day comes, it will likely need some
adaptations.
Part of the motivation here is to get something for gsd-backlight.c to
use where it can work more similarly to how the current common case
(sysefs) works, while attempting to migrate away from libgnome-rr.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3861>
It's now a signal emitted when `meta_output_set_backlight()` is called.
It is also no longer normalized between 1 and 100; that is now handled
done via the D-Bus API layer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3861>
