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>
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>
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>
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>
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>
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>
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>
This leaves only the atomic mode setting cap check before creating the
impl device, aiming to make it possible to create a non-mode-setting
MetaKmsImplDevice implementation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Make it possible to pass --headless as a command line argument in order
to turn the native backend "headless". This currently doesn't do
anything, but the intention is that it should not use logind nor KMS,
and work completely headless with only virtual outputs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Input settings requires a valid seat in order to initialize the a11y
settings (since commit 1609d145), however in X11 we never set it and
even if we create the input settings early (as per commit 7547891a) we
never initialize the seat for it.
This leads to startup critical errors on X11:
clutter_seat_get_pointer_a11y_settings: assertion
'CLUTTER_IS_SEAT (seat)' failed
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1763>
This commit adds the events created in the function
`meta_seat_x11_notify_devices` to the clutter events queue, which
are currently only added to the stage queue making the events not
being picked up by the `clutter_seat_handle_event_post` function.
This results in devices not getting added to the device-list of
`MetaInputSettings`.
Fixes the bug in which mouse and touchpad settings are not working in
the settings app during x11 session.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1767>
Since commit 2ceac4a device-related X11 events aren't processed anymore,
causing the input settings not to handle the devices.
This is due to the fact that we may never call clutter_seat_handle_event_post()
for such events.
While this is always happening for the native backend, it doesn't happen in
X11 because the events are removed from the queue as part of
meta_x11_handle_event(), and thus no event was queued to the stage by the
backend events source.
This also makes sure that the event post handler is called after the
event is actually processed, and not before an event is queued.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1564
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1769>
The nested backend may need to have an input setting implementation,
while we don't want to change the host settings (re-using an X11 input
settings) we can add a dummy implementation, until something more
complex is needed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1769>
With commit 7d78768809 we switched to
storing pointer coordinates in MetaInputDeviceNative instead of
ClutterInputDevice, and while we had set the coordinates of the
ClutterInputDevice in ClutterStage when queueing an event, we now set
the MetaInputDeviceNative coordinates in new_absolute_motion_event().
Here a small mistake snuck in: new_absolute_motion_event() only
translates the coordinates of the event, but we call
meta_input_device_native_set_coords() using the x and y variables
(which remain untranslated), so now the input device coordinates are no
longer translated.
Fix that by translating the coordinates of the x and y variables in case
we're we handling a tablet/stylus event instead of only translating the
event coordinates.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1685
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1760>
With commit c985753442 the support for
multiple hardware cursors broke, but those were never properly supported
anyway as we usually assume there's only one hardware cursor around.
With the introduction of the KMS thread in the future, we'll only have
one KMS cursor that gets updated directly from the input thread. So
apart from the fact that it never really makes sense to have two cursors
visible, in this new model having multiple cursors won't work anyway.
So make the cursor we show for stylii a software cursor again.
Eventually the plan is to make the input device that's driving the KMS
cursor interchangeable, so that we can always use hardware cursors.
This reverts commit 165b7369c8.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1645
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1758>
This concerns only the cases when the presentation timestamp is received
directly from the device (from KMS or from GLX). In the majority of
cases this timestamp is already MONOTONIC. When it isn't, after this
commit, the current value of the MONOTONIC clock is sampled instead.
The alternative is to store the clock id alongside the timestamp, with
possible values of MONOTONIC, REALTIME (from KMS) and GETTIMEOFDAY (from
GLX; this might be the same as REALTIME, I'm not sure), and then
"convert" the timestamp to MONOTONIC when needed. An example of such a
conversion was done in compositor.c (removed in this commit). It would
also be needed for the presentation-time Wayland protocol. However, it
seems that the vast majority of up-to-date systems are using MONOTONIC
anyway, making this effort not justified.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
