As documented in g_once_init_enter(): "While @location has a volatile qualifier,
this is a historical artifact and the pointer passed to it should not be
volatile.". And effectively this now warns with modern glibc.
Drop the "volatile" qualifier from these static variables as it's expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1785>
For Xwayland, mutter creates the sockets in the standard /tmp/.X11-unix
directory.
Yet, if that directory already exists, it may have been created by
another user with full control over the created socket.
To avoid that issue, if the directory /tmp/.X11-unix already exists,
check that the permissions are as we expect, i.e. the directory belongs
to either root or the user herself, is writable and has the sticky bit.
Thanks to fabian@ritter-vogt.de for reporting that issue.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1708
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1787>
Unlike other subsurface state, placement operations need to get
applied in order. As per spec:
```
Requests are handled in order and applied immediately to a pending
state. The final pending state is copied to the active state the
next time the state of the parent surface is applied.
```
Having placement operations being part of the subsurface state
makes it difficult to support arbitrary orderings. Make them
part of the parents surface pending state instead.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1691
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1768>
MetaInputSettings unref:ed the seat on destruction, but it never ref:ed
it on construction, meaning it "stole" the reference from the rightful
owner. Make MetaInputSettings less of a thief.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1775>
XIQueryPointer allocates the button state mask that we were leaking in
some places. We need to manually free this, because there is no XI
function that would do this for us.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1728>
In case the shell ignores or can't accept the restart request we should
hide the message that has been just requested to be shown.
As per ::show-restart-message signal documentation, this has to be done by
emitting the signal with a NULL message.
So follow the API properly in such case
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1780>
In non-systemd managed session we are unable to start services on
demand. Instead, gnome-session will start everything at login time,
including any X11 related service (i.e. gsd-xsettings).
However, in order to start gsd-xsettings, Xwayland needs to be started
already. Otherwise it will connect to GNOME_SETUP_DISPLAY and login will
hang at that point.
Fix this by detecting whether mutter is running in a systemd unit. If it
is, we assume that we are systemd managed and the machinery to start the
services works fine. If not, we assume that the session management may
unconditionally try to start X11 related services and Xwayland must be
started in order to not block this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1771>
On Wayland MetaInputSettings is part of the input thread. Connecting
a GSettings binding to the default ClutterSettings could result in the
change notification being emitted on the input thread. This then could
end up triggering the same handler from two different threads at the
same time. In the case of the ClutterText layout cache it was attempting
to unref the same layout twice, leading to a crash.
This can be avoided by simply removing the GSettings bind. This does not
cause changes to this setting to be missed by ClutterSettings because it
itself already sets up a bind.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1696
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1776>
When deciding if `configure` event should be sent,
`meta_window_wayland_move_resize_internal` compares requested window size
with `window->rect` size. However, `window->rect` is only updated when `commit`
is received. So the following sequence produces incorrect result:
1. a window initially has size `size1`
2. `move_resize_internal` is called with `size2`. `configure` is sent
3. `move_resize_internal` is called with `size1` to restore original size,
but `commit` for `size2` haven't arrived yet. So `window->rect` still has size
`size1`, and thus new `configure` is not sent
4. `commit` for `size2` arrives, window changes size to `size2`
Expected window size in the end: `size1`
Actual: `size2`
To fix the issue, take size from pending `configure` events into account.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1627
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1755>
This eliminates the need for any render node or device nodes, thus can
be used without any graphics hardware available at all, or with a
graphics driver without any render node available.
The surfaceless mode currently requires EGL_KHR_no_config_context to
configure the initial EGL display.
This also means we can enable the native backend tests in CI, as it
should work without any additional privileges.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Tests that creating and starting a virtual screen cast monitor works,
and that at least one one buffer is processed.
Currently the content of the buffer isn't checked more than it can be
mmap():ed. Only MemFd buffers are tested for for now, as DMA buffers
would need a surfaceless EGL context to check properly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
The new RecordVirtual API creates a virtual monitor, i.e. a region of
the stage that isn't backed by real monitor hardware. It's intended to
be used by e.g. network screens on active sessions, virtual remote
desktop screens when running headless, and scenarios like that.
A major difference between the current Record* API's is that
RecordVirtual relies on PipeWire itself to negotiate the refresh rate
and size, as it can't rely on any existing monitor, for those details.
This also means that the virtual monitor is not created until the stream
negotiation has finished and a virtual monitor resolution has been
determined.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
The area source, window source, and monitor source, currently set up the
stream size up front, given the area, maximum allowed window size or
monitor resolution, but for to be introduced sources, the size will be
negotiated using PipeWire, instead of specified via the D-Bus API. This
commit changes the internal source API to allow for this. There are
currently no users of this new behaviour.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
There may be a race between the ability to turn stream relative input
coordinates and turning them into screen coordinates, due to the future
scenario where the entity backing a stream is created and managed ad-hoc
depending on PipeWire stream negotiations.
When an input event is sent during this time, drop it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Make it possible to create persintent virtual monitors using command
line argument. This will not be the only way to create virtual monitors,
the primary way will be using the screen cast API, but using command
line argumenst is convenient for debugging purposes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
The testing currently done is:
* Creating a virtual monitor succeeds and gets the right configuration
* Painting a few times results in the expected output
* Changing the content of the stage also changes the painted content
accordingly
* Destroying the virtual monitor works as expected
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
This adds a test framework that makes it possible to compare the result
of painting a view against a reference image. Test reference as PNG
images are stored in src/tests/ref-tests/.
Reference images needs to be created for testing to be able to succeed.
Adding a test reference image is done using the
`MUTTER_REF_TEST_UPDATE` environment variable. See meta-ref-test.c for
details.
The image comparison code is largely based on the reference image test
framework in weston; see meta-ref-test.c for details.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Virtual monitors are monitors that isn't backed by any monitor like
hardware. It would typically be backed by e.g. a remote desktop service,
or a network display.
It is currently only supported by the native backend, and whether the
X11 backend will ever see virtual monitors is an open question. This
rest of this commit message describes how it works under the native
backend.
Each virutal monitor consists of virtualized mode setting components:
* A virtual CRTC mode (MetaCrtcModeVirtual)
* A virtual CRTC (MetaCrtcVirtual)
* A virtual connector (MetaOutputVirtual)
In difference to the corresponding mode setting objects that represents
KMS objects, the virtual ones isn't directly tied to a MetaGpu, other
than the CoglFramebuffer being part of the GPU context of the primary
GPU, which is the case for all monitors no matter what GPU they are
connected to. Part of the reason for this is that a MetaGpu in practice
represents a mode setting device, and its CRTCs and outputs, are all
backed by real mode setting objects, while a virtual monitor is only
backed by a framebuffer that is tied to the primary GPU. Maybe this will
be reevaluated in the future, but since a virtual monitor is not tied to
any GPU currently, so is the case for the virtual mode setting objects.
The native rendering backend, including the cursor renderer, is adapted
to handle the situation where a CRTC does not have a GPU associated with
it; this in practice means that it e.g. will not try to upload HW cursor
buffers when the cursor is only on a virtual monitor. The same applies
to the native renderer, which is made to avoid creating
MetaOnscreenNative for views that are backed by virtual CRTCs, as well
as to avoid trying to mode set on such views.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
The order of which function argument expressions are executed is
undefined, so don't rely on this for setting the background colors, as
it results in different colors on different architectures.
For example, it has been observed that the order of execution is
reversed comparing x86_64 and aarch64, making these two architectures
having different background color.
Fix this confusion, and also reproduceability in future reference tests,
by making the order of execution predictable.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
It's useful to be able to have very very tiny monitors (e.g. 60x60
pixels) when doing reference testing, as tests have reference images
that the output is compared to. Smaller reference images the less
storage they use.
To avoid annoying pointless warnings when this is done, change the
pedantic workspace work area code to be more forgiving if the work area
happens to match the display size.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
When rebuilding the monitors (e.g. during hotplug), make sure to detach
the disposed monitors from any outputs before creating the new monitors.
While this isn't currently needed, as outputs are too being recreated,
with the to be introduced virtual outputs that are created for virtual
monitors, this is not always the case anymore, as these virtual outputs
are not regenerated each time anything changes.
Prepare for this by making sure that cleaning up disposed monitors
detach themself properly from the outputs, so new ones can attach
themself to outputs without running into conflicts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
This makes it possible to pass custom properties to backends when
constructing tests. This will be used to create "headless" native
backend instances for testing the headless native backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
With this commit, it's possible to run mutter without being DRM master.
It's not yet possible to add virtual monitors, but one can for example
already add virtual input devices.
This currently doesn't try to hook up to any logind session, thus will
not have a real seat assigned. Currently it's hard coded to "seat0".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Currently our only entry point for DRM devices is MetaKms*, but in order
to run without being DRM master, we cannot use /dev/dri/card*, nor can
we be either of the existing MetaKmsImplDevice implementation (legacy
KMS, and atomic KMS), as they both depend on being DRM master.
Thus to handle running without being DRM master (i.e. headless), add a
"dummy" MetaKmsImplDevice implementation, that doesn't do any mode
setting at all, and that switches to operate on the render node, instead
of the card node itself.
This means we still use the same GBM code paths as the regular native
backend paths, except we never make use of any CRTC backed onscreen
framebuffers.
Eventually, this "dummy" MetaKmsImplDevice will be replaced separating
"KMS" device objects from "render" device objects, but that will require
more significant changes. It will, however, be necessary for e.g. going
from being headless, only having access to a render node, to turning
into a real session, with a seat, being DRM master, and having access to
a card node.
This is currently not hooked up, but will be in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Add a flag to MetaSeatNative and MetaSeatImpl that tells it not to
attempt to create a libinput context. This is intended to be used when
mutter is to run headless, as in without any input devices other than
virtual ones.
Currently not hooked up.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
