Page flipping shouldn't necessarily be an actively requested action, but
happen implicitly depending on the given state. Thus, change the "page
flip" update into adding listeners for page flip feedback instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This will later make it possible to pass cursor plane assignments,
together with a complete update including the primary plane, but not
failing the whole update if just processing the cursor plane failed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
If posting an update resulted in an immediate error, don't communicate
this failure using the page flip feedback callbacks, but directly as a
return value.
This makes it possible for the direct client buffer scanout path not to
pass around flags triggering this behavior, meaning we can handle such
direct scanouts better.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of a "post all pending updates", pass an update specific to a
single device. This gets rid of the awkward "combine feedback" function,
and makes it possible to queue updates to a multiple devices without
always posting them together.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Custom page flips are meant to allow using e.g. EGLStream API to
indirectly trigger page flip queueing, when the KMS API cannot be used
directly. This is really something that is specific to a device, so
instead of making part of the page flip API, make it a configuration of
the update itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Eventually the type of impl device will depend on the driver details, so
get that information before constructing the impl device. This commit
doesn't introduce any new usage of the details, it just prepares for
the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This commit consolidates DRM buffer management to the MetaDrmBuffer
types, where the base type handles the common functionality (such as
managing the framebuffer id using drmModeAdd*/RMFb()), and the sub types
their corresponding type specific behavior.
This means that drmModeAdd*/RmFB() handling is moved from meta-gpu-kms.c
to meta-drm-buffer.c; dumb buffer allocation/management from
meta-renderer-native.c.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
For now feedbacks from an update are combined, meaning we might lose
error information. The feedback API may have to be reconsidered and
redesigned when planes gets a more front seat position.
This means we need to avoid trying to post updates if we're in power
save mode, as it may be empty.
Note that this is an intermediate state during refactoring that aims to
introduce atomic mode setting support, and we'll stop combining
feedbacks completely in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of a constructor method, use the type directly and handle error
reporting using GInitable.
The DRM capability setting is done before construction, as later it'll
determine what type of impl device should be constructed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector
property changes, make the update itself aware of the changes, making
the impl side translate that to property changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of having MetaKmsPlaneAssignment carry a low level property
list, set the actual state change, and then have the implementation
translate that into the necessary property changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
With the aim at always using the property table to fetch and parse
property metadata, move IN_FORMATS handling to the property table, using
the newly introduced parse vfunc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Values may need to be processed and parsed in custom ways; make this
possible via the property table infrastructure using a callback.
Will be used for e.g. parsing rotation and formats.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of relatively verbosely going through the DRM properties finding
the properties we care about and saving their ID's, add a more
declarative way to fetch property metadata. This'll allow for fetching
more property IDs with relatively less code, which will be useful for
the atomic backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This contains a copy of a drmModeModeInfo, describing a mode. It also
has an unused pointer to the impl device it is associated with. It'll
later be used to get a blob ID for the mode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This means backend implementations can have more control of the order of
how things are destroyed. To be precise, this will, in the next commit,
allow us to destroy the logind integration after the clutter backend
thus the libinput owning seat, that uses the logind integration to
release input devices.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1670>
We can't post tasks to the input thread when cleaning up the
MetaSeatImpl, as that will make the GTask complain about adding
references to a to be purged object. Avoid this by adding an explicit
meta_seat_impl_destroy() function that handles the destruction of the
MetaSeatImpl properly.
This also does more of the cleanup in the input thread, as that is where
it was managed. Will likely not make a difference as before this
happened after tearing down the thread, but lets tear down things in the
thread they were managed for good measure.
This fixes the last log spew I see right now when terminating mutter.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1670>
Closing automatically Xwayland once all relevant X11 clients are gone is
inherently racy, if a new client comes along right at the time we're
killing Xwayland.
Fixing the possible race conditions between mutter, Xwayland and the X11
clients may take some time.
Meanwhile, make that an experimental feature "autoclose-xwayland".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1673>
We didn't tear down the libinput objects in the right thread when
exiting, but did so after the input thread exited.
We also tried to destroy the libinput devices after the libinput context
was destroyed, which isn't allowed.
Fix these two issues by tearing down the libinput objects in a input
thread task that when done exits the input thread. This effectively
"flushes" the input thread tasks while destroying the libinput objects
just before the thread exits.
While it might fine to tear down libinput objects in an arbitrary (main
in this case) thread while making sure nothing pokes at it in parallel
(e.g. the input thread is gone), libinput is by definition single
threaded, and could theoretically make assumptions about this, and we
shouldn't cause any possible surprises here, so make sure to destroy it
all in the right thread.
This fixes an abort() on exit caused by an assert about invalid object
destruction in libinput.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1663>
The "seat" usually refers to the ClutterSeat (MetaSeatNative) object,
and "seat_impl" to the MetaSeatImpl object, but there were still a few
places where this wasn't adhered to so fix those.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1663>
When supported, this property allows the window system to apply a 3x3 color
correction matrix in order to transform colors from the window system's native
color space to the measured color space of a display device.
Query for this property and set the 'supports-color-transform' property in the
GetResource reply. Add support for the SetOutputCTM DBus method and plumb that
through to the server's CTM property.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1048>
Currently, the NotifyPointerAxis method always assumes that the scroll
source is CLUTTER_SCROLL_SOURCE_FINGER.
This is however not always true and in some cases a remote desktop
client needs to submit a PointerAxis event with a custom axis step.
This is for example the case with high resolution mouse wheels, where
the NotifyPointerAxisDiscrete method is unsuitable.
In such cases NotifyPointerAxis needs to be called, but with the
intention that the scroll source is still a mouse wheel.
To solve this situation, don't assume the scroll source always to be
CLUTTER_SCROLL_SOURCE_FINGER.
Instead, add further flag options to NotifyPointerAxis, which allow a
remote desktop client to choose the scroll source.
This way a remote desktop client can choose what scroll source is the
most suitable one for the current scroll event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1636>
This signal may be left dangling when disconnecting a device, and be executed
later on if the device is connected again, and mapped to other output. Make it
sure the signal handler is disconnected when unplugging the device.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1657>
To clear a pointer constraint, the Wayland backend passes a NULL
constraint to the native input backend.
The new async API however tries to reference/un-reference the given
object to use it while running in a separate task, which leads to a
warning from GLib trying to g_object_ref()/g_object_unref() a non
GObject pointer.
To avoid that issue, simply set the data only if the given constraints
pointer is not NULL.
Suggested-by: Carlos Garnacho <carlosg@gnome.org>
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1587
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1652>
Power saving changes in laptop panels enable/disable the attached
touchscreen input device, this is an asynchronous operation that
may be happening while the device is disappearing.
In fact, closing the lid is such perfect storm where both things
happen around the same time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1644>
Currently, the MetaInputDeviceNative owns the libinput_device, with the
small catch that it is eventually finished in the main thread (as the
CLUTTER_DEVICE_REMOVED event keeps the last reference to it).
Make it sure that the libinput_device is destroyed in the input thread,
before giving away the last extra input device references.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1639>
There was an attempt to remove an unnecessary inclusion of a header
file, but only got so far as compile testing after having commented out,
but didn't remove the comment before creating a commit. This commit
fixes that mistake.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1640>
Instead of using native backend platform data specifically, store
this info in ClutterMotionEvent. This includes time in usec since
it's just used for motion events, in the future it could make sense
to make these general to all events again, but it could make sense
to make ClutterEvent structs private before.
In order to express that a motion event has relative motion info,
the CLUTTER_EVENT_FLAG_RELATIVE_MOTION event flag has been added
for it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
We had code in both backends that sort of independently associated
sequences to slots. Make both transform slots to sequences the same
way, so they may share the implementation convert those back to slots.
This helper now lives in Clutter API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
We have this as platform-dependent data in the native backend, and
a bunch of fallback code done in place in the evcode users. Stop
making this platform-dependent data, and move it to the relevant
ClutterEvents.
The fallback code for the X11 backend case is about the same, but
now it is done directly by the X11 backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
Making this an event is overly convoluted, accounting that we
emit the event, then convert it to a ClutterStage signal, then
its only consumer (a11y) sets the active ATK state.
Take the event out of the equation, unify activation/deactivation
of the stage in MetaStage, and use it from the X11 backend too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
Ensure that color_ptr gets set, and avoid color_char usage too in
that case. Fixes:
../../../../Source/gnome/mutter/src/backends/native/meta-monitor-manager-kms.c: In function ‘meta_monitor_manager_kms_set_crtc_gamma’:
../../../../Source/gnome/mutter/src/backends/native/meta-monitor-manager-kms.c:370:7: warning: ‘color_char’ may be used uninitialized in this function [-Wmaybe-uninitialized]
370 | g_string_append_printf (string, " %c: ", color_char);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../../Source/gnome/mutter/src/backends/native/meta-monitor-manager-kms.c:351:12: note: ‘color_char’ was declared here
351 | char color_char;
| ^~~~~~~~~~
../../../../Source/gnome/mutter/src/backends/native/meta-monitor-manager-kms.c:391:36: warning: ‘color_ptr’ may be used uninitialized in this function [-Wmaybe-uninitialized]
391 | (*color_ptr)[i]);
| ~^~~~~~~~~~~
../../../../Source/gnome/mutter/src/backends/native/meta-monitor-manager-kms.c:350:24: note: ‘color_ptr’ was declared here
350 | unsigned short **color_ptr;
| ^~~~~~~~~
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1624>
Figuring out the MetaSeatImpl this much indirectly is fairly awkward when
the keymap is only updated from the MetaSeatImpl, pass instead the seat
impl's xkb_state, as we have it handy in all the places this is called.
This will not break on NULL seats during initialization, should the numlock
state be restored from previous sessions.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1556
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1612>
The API allows for invalid barriers to be created; in an X11 session,
this could result in involutary early exit, so guard against those with
soft asserts. These will be logged in the journal as warnings, but will
avoid the crash unless compiled out.
Note that this doesn't fix the bug, it just makes it more detectable.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1901610
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1611>
Make it impossible to add individual includes of input thread objects.
This must go through meta-input-thread.h now, which should be enough
to make anyone think it twice.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
They're a dime a dozen. If it gets called exclusively from the
input thread, it got one. Hopefully these breadcrumbs will be
enough so people don't lose their way here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
This (now) doesn't change anything in regards to the API that the UI
thread should access from the MetaSeatImpl. The MetaInputDeviceNative,
MetaInputSettings and MetaKeymap objects are now considered owned by
the input thread, as well as all of libinput objects.
The MetaEventSource now dispatches events in a GMainContext that is
the thread default to this thread, and all UI-thread-accessible API
(seat and virtual input device API) will be handled in a serialized
manner by that same input thread.
The MetaSeatImpl itself is still considered to be owned by the caller
thread, and all the signals that this object emits will be emitted in
the GMainContext that is default at the time of calling
meta_seat_impl_new().
The MetaInputSettings configuration changes will likewise be handled
in the input thread, close to libinput devices.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Instead of going through the event queue, stage handling code, and
back to the input device via a vmethod call, do this directly in the
MetaSeatImpl. This is not too different from X11, where everything
happens inside the backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
All that is left in the "public" struct is all state that ClutterStage
delegates on ClutterInputDevice. That should move somewhere else, but
not here, not now.
All private fields belong to construct-only properties, with only getter
API, and idempotent vmethods (except keyboard a11y, atm). This should
be enough to make ClutterInputDevice obviously thread safe, outside the
backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
This API is the one accessed from different bits of the UI thread,
make it "async" (it's basically one-way setters, so API stays the same
in the surface) and able to run in the MetaSeatImpl main context.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Simplify the handling of numlock state, so it can be entirely handled
within the input thread. Since the saving/restoring is triggered inside
each backend code, there's no need anymore for meta_backend_set_numlock().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Push it a little bit down to the MetaSeatNative. As both the UI thread
and the input thread are interested in dealing with the xkb_keymap and
it is not meant to be used in different threads, keep 2 separate copies
around.
The keyboard map will always be set from the UI thread, so the xkb_keymap
owned by the MetaSeatNative (owned by the UI thread) can be considered
canonical.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Don't let the vfuncs (meant to be called from the UI thread) deal with
xkb state itself. Instead store the current state in struct fields, which
is then fetched in vfuncs.
This makes the keymap able to be used from the UI thread, while being
maintained by the input thread. Same caveats apply than
clutter_seat_query_state(), you are asking for the most up-to-date state,
but it still may be changing under your feet.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Wrap all keyboard state updates, and all pointer/stylus/touch cursor
position with a write lock, and ::query_state() (The only entrypoint
to this state from other threads) with a read lock.
The principle is that query_state may be called from different threads
(UI so far, but maybe KMS too in the future), while the input thread
may (or may not) be updating it. This state is fetched "atomically"
(eg. x/y will be consistently old or new, if the input thread were
updating it at the same time).
There's other places deep in backends/native that read this state,
they all will run in the input thread, so they count as "other readers"
to the other thread. Those changes are already mutually exclusive with
updates, so they don't explicitly need the RW lock.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
While barriers will be added from the main thread, the native barrier
manager will sit close to the MetaSeatImpl in its own thread. Add the
necessary locking so that we can pass MetaBarrierImplNative from the
UI thread to the input thread, and ensure the MetaBarrier signals are
still emitted in the UI thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Depending on the backend, we want to integrate this object at different
levels. It will sit close to the MetaBackendX11/MetaSeatX11 in X11, but
it will be put deep down with MetaSeatImpl in the native backend, in a
separate thread.
Since we can't depend on a single object type, nor are able to track
ClutterSeat signals neatly, make this API something to be called
explicitly by backends.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
These changes will happen in the input event management code, so let them
be emitted via the MetaSeatImpl, as that's what we'll have neat access to.
The ClutterSeat signals are now emitted from there.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Move most of the functional bits (those meant to run on a standalone
thread) to a MetaSeatImpl object. This object is managed by the MetaSeatImpl
and not exposed outside the friend MetaSeatNative/MetaInputDeviceNative/
MetaInputSettings classes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Banish MetaInputSettings from MetaBackend "public" API, it's now meant to
spend the rest of its days in the backend dungeons, maybe hanging
off a thread.
MetaInputMapper replaces all external uses.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Delegate on the MetaInputMapper all matching of inputs and outputs,
including configuration. Other secondary aspects, like output
aspect ratio for tablet letterbox mode, or toggling attached devices
with power saving changes, are also moved here.
This makes MetaInputSettings independent of MetaMonitorManager,
all interaction with it happens indirectly via public API entrypoints.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Rename the set_tablet_keep_aspect() vfunc into a set_tablet_aspect_ratio()
one that takes an aspect ratio double, instead of leaking monitor info
into subclasses to let them all figure out this number themselves.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
We have 2 sources (this one in MetaSeatNative, and the one in
MetaBackend) dispatching ClutterEvents to the stage. Make the
MetaSeatNative one exclusively about dispatching the libinput
queue, and leave ClutterEvents to the other.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
This will resort to SW rendering if this cursor renderer does not
own the MetaKmsCursorRenderer, so it's pretty much equivalent thus
far, except we may now implement logic to flip the kms cursor renderer
around.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
We actually have a set_send_events() vfunc that can enable or disable
devices at the libinput and X11 input driver level, so use that. A
positive side effect is that those layers will leave the device at
a consistent idle state (as opposed to going mute maybe amid user
input).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
We are aiming for a split of HW and SW cursor rendering management.
Given the HW plane is a limited resource and the amount of cursor
renderers may be >1 (due to tablets, even though we currently use an
always-software cursor renderer there), it would ideally be able to
switch between renderers.
Being MetaCursorRenderer not really a singleton, having cursor
inhibitor accounting here doesn't pan out. Make it MetaBackend API
so all cursor renderers get the same picture.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
These use now more of a "pull" model, where they receive update
notifications and the relevant input position is queried, instead
of the coordinates being passed along.
This allows to treat cursor renderers all the same independently
of the device they track. This notifying of position changes should
ideally be more backend-y than core-y, a better location will be
figured out in future commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Instead of letting the wayland bits maintain an always-software
cursor renderer, let the cursor renderer be managed by the backend,
and only hook to it (as we do for pointer cursor) in the wayland
bits.
ATM, make the cursor renderer still always-software, although
ideally we should allow moving the HW cursor management between
renderers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Different devices may get standalone cursor renderers, add this API
to adapt slowly to this. The meta_backend_get_cursor_renderer() call
still exists, but shortcuts to the mouse pointer's renderer (as it
actually did before).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Use a new set in MetaInputDeviceNative, this coexists with
ClutterInputDevice coords for the time being. This API will
eventually be only accessed from the input thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
While multiple built-in panels isn't actually supported in any
meaningful manner, if we would ever end up with such a situation, e.g.
due to kernel bugs[0], we shouldn't crash when trying to set an
'external only' without any external monitors.
While we could handle this with more degraded functionality (e.g. don't
support the 'switch' method of monitor configuration at all), handle it
by simply not trying to switch to external-only when there are no,
according to the kernel, external monitors available. This would e.g.
still allow betwene 'mirror-all', and 'linear' switches.
The crash itself was disguised as an arbitrary X11 BadValue error, due
to mutter trying to resize the root window to 0x0, as the monitor
configuration that was applied consisted of zero logical monitors, thus
was effectively empty.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1896904
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1899260
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1607>
xkb recently gained support for user-specified keymaps, which means we
can no longer assume that the configuration data is necessarily fully
complete or correct; and the configuration language is quite a labyrinth,
so it's easy to get wrong. If setting the keymap fails, leave it in
whatever state it previously had, since that seems preferable to crashing
with a NULL pointer dereference.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/1555
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1605>
Sometimes the automatically selected primary GPU isn't suitable with no
way to make an well educated guess to do it better. To make it possible
for the user to override the automatically calculated default, make it
possible to override it using a udev rule.
E.g. to select /dev/dri/card1 as the primary GPU, add a file e.g.
/usr/lib/udev/rules.d/61-mutter-primary-gpu.rules (path my vary
depending on distribution) containing the fellowing line:
ENV{DEVNAME}=="/dev/dri/card1", TAG+="mutter-device-preferred-primary"
Reboot or manual triggering of udev rules to make it take effect may be
required.
Related: https://gitlab.gnome.org/GNOME/mutter/merge_requests/1057https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1562
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1562>
Instead of aborting with an error, display a half transparent gray
square instead of cursors and log a warning in the journal, allowing the
user to fix their system withotu having to rely on switching to a TTY.
It will be immediately obvious the cursor is silly looking, which will
be a better hint than just aborting.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1428
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1563>
Monitor tile info is possible to fetch when RANDR version 15 is exposed
by the X11 server. We had inverted the check meaning that only if older
versions were advertised would we attempt to init the tile information.
Fix this guard, thus fix monitor tiling on X11.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1524
Not calling libinput dispatch in the backend constructor defeats the
logic in post init as the device added events have not been processed
yet.
So instead of trying to guess the cursor initial visibility, simply
update it along when devices get added.
Additional benefit, we do not need to walk the all device list looking
for touchscreens anymore, we just need to check the device being added
since the current logic is to hide the cursor as soon as a touchscreen
is found.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1534
At startup, libinput dispatch is called from the MetaSeatNative
constructed callback.
That means that we may get libinput events even before the default seat
is set.
In turn, processing those events may trigger the use the default seat
while it's still not set yet, and cause a crash of gnome-shell/mutter
at startup.
A simple reproducer for this is to start gnome-shell/mutter with a
tablet connected and the stylus in proximity, the proximity event will
cause gnome-shell/mutter to crash at startup.
To avoid that issue, avoid dispatching libinput events early from the
MetaSeatNative constructed callback, those events will eventually get
processed when the seat and the backend are all setup.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1501https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1534
Otherwise we might run into a use-after-free and crash on (virtual)
device removal:
Invalid read of size 8
at clutter_input_device_get_device_type (clutter-input-device.c:811)
by update_last_device (meta-backend.c:1282)
by g_main_dispatch (gmain.c:3325)
by g_main_context_dispatch (gmain.c:4016)
by g_main_context_iterate.constprop.0 (gmain.c:4092)
by g_main_loop_run (gmain.c:4290)
by meta_run_main_loop (main.c:708)
by meta_run (main.c:723)
by main (main.c:550)
Address is 32 bytes inside a block of size 504 free'd
at free (vg_replace_malloc.c:538)
by g_type_free_instance (gtype.c:1939)
by clutter_event_free (clutter-event.c:1420)
by _clutter_stage_process_queued_events (clutter-stage.c:830)
by handle_frame_clock_before_frame (clutter-stage-view.c:1064)
by clutter_frame_clock_dispatch (clutter-frame-clock.c:405)
by frame_clock_source_dispatch (clutter-frame-clock.c:456)
by g_main_dispatch (gmain.c:3325)
by g_main_context_dispatch (gmain.c:4016)
by g_main_context_iterate.constprop.0 (gmain.c:4092)
by g_main_loop_run (gmain.c:4290)
by meta_run_main_loop (main.c:708)
by meta_run (main.c:723)
Block was alloc'd at
at malloc (vg_replace_malloc.c:307)
by g_malloc (gmem.c:106)
by g_slice_alloc (gslice.c:1025)
by g_slice_alloc0 (gslice.c:1051)
by g_type_create_instance (gtype.c:1839)
by g_object_new_internal (gobject.c:1939)
by g_object_new_valist (gobject.c:2264)
by g_object_new (gobject.c:1782)
by meta_input_device_native_new_virtual (meta-input-device-native.c:1365)
by meta_virtual_input_device_native_constructed (meta-virtual-input-device-native.c:705)
by g_object_new_internal (gobject.c:1979)
by g_object_new_valist (gobject.c:2264)
Suggested-by: Carlos Garnacho <carlosg@gnome.org>
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1529
Rely on the seat stage, or other ways to fetch it. Also rely that
there is actually a single stage, so that we assign the right stage
to all events going out of the seat, in a single place.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
This is a bit scattered around, with the setter/getter in Clutter, and
it only being only directly honored in Wayland (it goes straight through
device properties in X11).
Make this private native API, and out of public ClutterInputDevice API.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
Make the upper part agnostic about the device being relative in order
to avoid applying keep-aspect. The X11 bits already are, so make it
sure it's also the case for the native backend.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
As it does seem from a read to libinput code, TOUCH_CANCEL events
actually do contain slot information, and are emitted per-slot.
This means we can avoid iterating over the slots ourselves, they
are still expected to be sent altogether.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
When malformed modes are provided and no valid mode spec is found, mutter
will eventually try to access the last element of an empty list. Warn about
this and exit properly.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1481
Many tablets have a native portrait mode panel, yet come with a keyboard dock,
where the device gets docked in landscape mode. To avoid the display being
on its side when mutter starts while the tablet is docked, we need to take
the accelerometer reported orientation into account even if there is a
tablet-mode-switch which indicates that the device is NOT in tablet-mode
(because it is docked).
Add special handling for the first time the "orientation-changed"
signal gets signalled by the orientation-manager, which happens after it
has successfully claimed the accelerometer with iio-sensor-proxy.
The added special handling of the initial "orientation-changed" signal
does a number of checks:
1. panel_orientation_managed is false because of the tablet-mode-switch and not
because of other reasons.
2. The device has a native portrait mode panel (and thus likely needs rotation
to display the image the right way up when docked).
If all these checks succeed then it continues with creating a new
monitors-config based on the orientation ignoring the panel_orientation_managed
value (for the initial/first "orientation-changed" signal only).
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
The orientation reported by the orientation_manager may have changed while
panel_orientation_managed was false. So when panel_orientation_managed
changes to true we should re-check the orientation.
This fixes the orientation not being correct when e.g. taking a 360 degree
hinges 2-in-1 in clamshell mode (so landscape orientation) and then folding
it into tablet mode while holding it in portrait orientation.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
Add support for the (mostly theoretical) case of an input-device
offering tablet-mode-switch functionality being unplugged.
This makes the has_tablet_switch handling identical to the has_touchscreen
handling, leading to more consistent code.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
Detect if a tablet-mode-switch device is already present when mutter
starts by checking for this from meta_seat_native_constructed. This
mirrors how we also set has_touchscreen from meta_seat_native_constructed.
This fixes tablet-mode-switches only being recognized when they are added
at runtime.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
Unconditionally setting has_touchscreen to check_touch_mode
when a new device gets added leads to has_touchscreen becoming
false when during runtime e.g. an USB keyboard gets plugged in.
Fix this by setting has_touchscreen to TRUE when check_touch_mode
is TRUE and leaving it alone otherwise.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
A first step towards abandoning the CoglObject type system: convert
CoglFramebuffer, CoglOffscreen and CoglOnscreen into GObjects.
CoglFramebuffer is turned into an abstract GObject, while the two others
are currently final. The "winsys" and "platform" are still sprinkled
'void *' in the the non-abstract type instances however.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1496
Mutter still relies heavily on singletons such as its MetaBackend.
For that, the backend implementation has a meta_init_backend() function
which is called at startup from meta_init(), which creates the desired
backend and sets the singleton which is returned by meta_get_backend().
Unfortunately, that means that the backend is never actually freed, and
all the code from the backend finalize function never actually get
called.
Add a meta_release_backend() to free the backend singleton.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1438
The input settings constructor installs callback functions on device
added/remove and tool-changed.
However, on dispose, those signals are not disconnected, meaning that on
teardown, once the devices get removed eventually, the callback will
still fire and call the callback with freed data, causing a crash.
Make sure we clear the signals on devices on dispose, to avoid the crash
on teardown.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1438
CoglMatrix already is a typedef to graphene_matrix_t. This commit
simply drops the CoglMatrix type, and align parameters. There is
no functional change here, it's simply a find-and-replace commit.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
During seat initialization, we process early libinput events (adding all known
devices) before the seat gets a stage assigned. This causes warnings when trying
to handle the corresponding CLUTTER_DEVICE_ADDED events, as they are sent
stageless.
As it is definitely too soon to have those events sent meaningfully, filter
those events out and instead handle the CLUTTER_DEVICE_ADDED emission for all
known devices after the seat receives an stage. This makes the events guaranteed
to be emitted early in initialization, but not so soon that they can't be
handled yet.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1472
Like it's done for the pointer in other places. Without a stage assigned,
some bits (like IM handling) may end up with events ignored, and misbehave.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1413
When a MetaBarrier is first created it allocates a backend
impl object which does the actual heavy lifting.
Unfortunately, that backend object is never freed.
This commit ensures the implementation gets freed when
the barrier object is freed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1451
meta_barrier_destroy is responsible for removing the extra
reference added in meta_barrier_constructed.
Unfortunately, it fails to do this because of a misplaced early
return statement.
This commit removes the spurious return.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1449
In X, buttons 1, 2, 3 are left, middle, right. In evdev, the order is
BTN_LEFT, BTN_RIGHT, BTN_MIDDLE. So setting a scroll button to 2 gave us a
middle button in the X session and a right button in a wayland session.
Fix that by hard-coding the LMR buttons handling.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1433
Even when a direct client buffer has a compatible format, stride and
modifier for direct scanout, drmModePageFlip() may still fail sometimes.
From testing, it has been observed that it may seemingly randomly fail
with ENOSPC, where all subsequent attempts later on the same CRTC
failing with EBUSY.
Handle this by falling back to flipping after having composited a full
frame again.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1410
If there is no laptop panel (for example on a desktop PC or a virtual
machine), attempting to put a NULL monitor in the list of matches
will just make mapping_helper_apply() crash.
Mitigates: https://gitlab.gnome.org/GNOME/mutter/-/issues/1414
Signed-off-by: Simon McVittie <smcv@debian.org>
It's enabled by default when using the i915 driver, but disabled
everywhere else until it can be made reliably an improvement. Until
then, for anyone want to force-enable it, add the string
'dma-buf-screen-sharing' to the experimental features list in GSettings.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1442
Seems DMA buffer based interprocess buffer sharing is more broken than
not, so for now only enable it when using the i915 driver.
For example vmwgfx, qxl and radeon, it results in mmap() failing to mmap the
memory region. Other drivers, e.g. amdgpu will function, but may hit
very slow memory download paths, resulting in worse performance.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1442
We only want the panel autorotation to happen if the laptop has an
accelerometer, and is in tablet mode. Regular laptop mode should
lock the orientation, and let it be configured manually.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
So far, we've expected this signal to not happen whenever autorotation
shouldn't apply (no accelerometer is a strong reason). In future commits
we'll add further checks to this policy, so prevent autorotation to
change the display configuration if the MetaOrientationManager signal
happens but it should be ignored.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
Instead of having everyone check net.hadess.SensorProxy themselves, have
this all controlled by the MetaOrientationManager, and proxied everywhere
else via a readonly property in org.gnome.Mutter.DisplayConfig.
We want to attach more complex policies here, and it seems better to
centralize the handling of the autorotation feature rather than
implementing policy changes all over the place.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
We used to pick the "best" output for each builtin/size/edid categories,
and then pick the "best" (in that order) of those for each input device.
This is most often enough, but is prone to wrong results in some corner
cases (eg. 2 outputs with the exact same dimensions).
Change this to a score mechanism that doesn't leave outputs out. The
weights are the same, but the score is accumulated if an output matches
multiple categories. All outputs are evaluated and sorted by score, and
input devices with the best matches are applied first (as they already
did).
This should break the tie if eg. there's 2 outputs with similar dimensions,
but one of them has some EDID match in addition. The output with multiple
matches will score higher up, while it might have been entirely discarded
with the previous implementation.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1175https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1202
The work at https://gitlab.gnome.org/GNOME/gnome-control-center/issues/239
intended to make integrated devices optionally mappable to other outputs
(in order to allow fix mishandling from our heuristics, or to quickly reach
things in other monitor without changing devices).
This was missed in that plan, we do allow cycling outputs, but we still did
prevent it from doing anything for integrated devices. Fix that, and change
output cycling so we don't allow a "NULL" EDID for integrated devices, this
makes those go through the MetaInputMapper (resulting in one output listed
twice), instead of mapping to the full stage.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1186https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1201
The cursor tracker may give us a valid position, and a
valid cursor sprite, and yet the cursor can be hidden,
meaning we must hide the cursor on the stream as well.
Remove cursor from stream buffer if it's hidden.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1421
Scanouts are taken away after painting. However, when we're
streaming, what we actually want is to capture whatever is
going to end up on screen - and that includes the scanout
if there's any.
Add a before-paint watch that only records new frames if a
scanout is set.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1421
When there's a direct scanout set in the stage view, we
have to use it instead of the view's regular onscreen
framebuffer.
Use the new CoglScanout API to implement blitting to the
stream framebuffer.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1421
This will be used when screencasting monitors so that if
there's scanout in place, it'll still be possible to blit
it to a PipeWire-owned framebuffer, and stream it.
Add a new 'blit_to_framebuffer' vfunc to CoglScanout, and
implement it in MetaDrmBufferGbm.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1421
Just because X11/XI uses a particular terminology doesn't mean we
have to use the same terms in our own API. The replacement terms
are in line with gtk@1c856a208, which seems a better precedent
for consistency.
Follow-up to commit 17417a82a5.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1425
QXL doesn't support mmap():ing a DMA buffer allocated in mutter inside
the PipeWire stream consumer process. To make screen casting work again
on QXL, disable DMA buffer based screen casting for QXL.
Eventually, it should be the client that renegotiates the supported
buffer types, but until then we need this list.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1318
The X server, including Xwayland, can be compiled with different X11
extensions enabled at build time.
When an X11 extension is built in the X server, it's usually also
enabled at run time. Users can chose to disable those extensions at run
time using the X server command line option "-extension".
However, in the case of Xwayland, it is spawned automatically by the
Wayland compositor, and the command line options are not configurable
by users.
Add a new setting to disable a selected set of X extension in Xwayland
at startup, without needing to rebuild Xwayland.
Of course, if Xwayland is not built with a given extension support in
the first place (which is the default for the security extension for
example), that option has no effect.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1405
Delay the addition and removal of devices using ClutterDeviceEvent's so that
they are processed following the libinput event order, and that we don't
have to flush the events on removal.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1371
When a device is removed from the seat the events that this device may have
emitted just before being removed might still be in the stage events queue,
this may lead a to a crash because:
Once the device is removed, we dispose it and the staling event is
kept in queue and sent for processing at next loop.
During event processing we ask the backend to update the last device
with the disposed device
The device is disposed once the events referencing it, are free'd
The actual last device emission happens in an idle, but at this point
the device may have been free'd, and in any case will be still disposed
and so not providing useful informations.
To avoid this, once a device has been added/removed from the seat, we queue
ClutterDeviceEvent events to inform the stack that the device state has
changed, preserving the order with the other actual generated device events.
In this way it can't happen that we emit another event before that the
device has been added or after that it has been removed.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1345
When removing a device that has been just marked as the last in use, we may
try to notify that a NULL device is the last one.
This is not supported, as both update_last_device() and the clients of the
"::last-device-changed" signal are assuming that the last device is always
a valid ClutterInputDevice.
So let's avoid erroring, and stop the idle when clearing the current device.
Related to: https://gitlab.gnome.org/GNOME/mutter/-/issues/1345https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1371
PipeWire reuses buffers, and buffer metadatas, when streaming. When
the cursor is moved to outside the stream, the cursor meta also needs
to be updated, otherwise it'll use the cursor position of whatever is
in the buffer.
Don't bail out when cursor is outside the stream, and ensure to record
a metadata-only frame. This only applies to metadata streams.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1417
Currently, the maximum size for a mouse pointer bitmap for screen
casting is 64x64 pixels.
However, this limit is hit way too often as it is way too low and
results in crashes in either gnome-remote-desktop or mutter.
For example: The a11y settings in g-c-c allow setting a larger pointer
bitmap in order to increase the visibility of the mouse pointer.
With the current limit of 64x64 pixels it is not possible to use the
larger variants of the default mouse pointer bitmap, without
experiencing any crash.
Another way to hit the limit is when display scaling is used or some
game uses a custom (large) mouse pointer bitmap.
The VNC backend in gnome-remote-desktop does not seem to have a maximum
pointer bitmap size.
The RDP backend on the other hand has a maximum pointer bitmap size at
384x384.
Use this size (384x384) as maximum size instead of the current 64x64
size for mouse pointer bitmaps to avoid crashes in mutter and
gnome-remote-desktop and to ensure that bigger mouse pointer bitmaps
can be used.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1414
It is linear config manager created when ensuring configuration.
However, the switch config is not set as LINEAR, but left as UNKNOWN.
This leads switch mode OSD always shows "Join Displays" icon, rather
than the next icon which is "External Only" after connect an external
display and press Super+P once at first time since mutter starts.
This patch moves switch config setting into
meta_monitor_config_manager_create_linear() (and the sibling functions)
to well prepare the monitors config and avoid missing settings.
This is a regression introduced by 149e4d6934.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1362
The delete event was used for signalling the close button was clicked on
clutter windows. Being a compositor we should never see these, unless
we're running nested. Remove the plumbing of the DELETE event and just
directly call meta_quit() when we see it, if we're running nested.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1364
We checked if we were using the usig the X11 backend to decide when to
deal with a11y event posting - in order to make the clutter code less
windowing system dependent, make this check a check whether we're a
display server or not, in contrast to a window/compositing manager
client. This is made into a vfunc ot ClutterBackendClass, implemented by
MetaClutterBackendNative and MetaClutterBackendX11.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1364
Flip flop resize, which is the result of respecting ConfigureNotify
makes test annoyingly racy, as one cannot do
clutter_actor_set_size (stage, 1024, 768);
wait_for_paint (stage);
g_assert_assert (clutter_actor_get_width (stage) == 1024);
The reason for this is any lingering ConfigureNotify event that might
arrive in an inconvenient time in response to some earlier resize.
In order to not risk breaking any current behavior in the X11 CM case
(running as a compositing window manager), only avoid changing the stage
size in response to ConfigureNotify when running nested.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1404
This aims to make sure a view and its resources are destroyed when it
should. Using references might keep certain components (e.g frame clock)
alive for too long.
We currently don't take any long lived references to the stage view
anywhere, so this doesn't matter in practice, but this may change, and
will be used by a to be added test case.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1404
Without doing this, we'd use the same sprite that was last set by
mutter, most likely a leftptr cursor, and fail to update when e.g.
moving the pointer above a text entry and the displayed cursor updated
to a cursor position marker.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1391
The displayed cursor is the one displayed on the screen, e.g. via the
hardware cursor plane, by Xorg, or using the stage overlay.
When screen recording under X11, we don't get a stream of pointer and
cursor updates, as they might be grabbed by some other client. Because
of this, the cursor tracker or cursor renderer are not kept up to date
with positional and cursor state.
To be able to use the stage overlays when recording, we need to be able
to update the overlay without updating the displayed cursor, as we
shouldn't update the X server with cursor state we just retrieved from
it.
Thus, to achieve this, create a separate overlay cursor pointer. When
being a display server, they are always the same, but when using X11,
during screen recording, the overlay one will be polled at a fixed
interval to get a somewhat up to date state.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1391
Always force-track the cursor position (so that the X11 backend can keep
it up to date), and if the cursor wasn't part of the sampled
framebuffer when reading pixels into CPU memory, draw it in an extra
pass using cairo after the fact. The cairo based cursor painting only
happens on the X11 backend, as we otherwise inhibit the hw cursor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1391
On X11 we won't always receive cursor positions, as some other client
might have grabbed the pointer (e.g. for implementing a popup menu). To
make screen casting show a somewhat correct cursor position, we need to
actively poll the X server about the current cursor position.
We only really want to do this when screen casting or taking a
screenshot, so add an API that forces the cursor tracker to track the
cursor position.
On the native backend this is a no-op as we by default always track the
cursor position anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1391
Only when the cursor isn't handled by the backend is the overlay made
visible. This is intended to be used when painting the stage to an
offscreen using clutter_stage_paint_to_(frame)buffer() in a way where
the cursor is always included.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1391
Detect displays marked as 'non-desktop' by the kernel and skip them when
creating the outputs. Mutter is not able to render images that are shown
properly on those devices anyway.
This avoids lighting up attached VR HMDs and showing the GDM login
screen between the eyes in a VR HMD instead of on the monitor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1393
Intended to be used to pass state from screen cast clients down the
line. The first use case will be a boolean whether a screen cast is a
plain recording or not, e.g. letting the Shell decide whether to use a
red dot as the icon, or the generic "sharing" symbol.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1377
The new "id" properties for the MetaCrtc* and MetaOuput* objects are 64-bit
values, so take care to pass 64-bit values when calling g_object_new.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1343.
When using its EGLStream-based presentation path with the proprietary NVIDIA
driver, mutter will use a different function to process page flips -
custom_egl_stream_page_flip. If that fails due to an EBUSY error, it will
attempt to retry the flip. However, when retrying, it unconditionally uses the
libdrm-based path. In practice, this causes a segfault when attempting to
access plane_assignments->fb_id, since plane_assignments will be NULL in the
EGLStream case. The issue can be reproduced reliably by VT-switching away from
GNOME and back again while an EGL application is running.
This patch has mutter also use the custom page flip function when retrying the
failed flip.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1375
Instead of blindly hoping that `$INCLUDE` contains the parent directory
of `gsettings-desktop-schemas`.
Because `gsettings-desktop-schemas.pc` says:
```
Cflags: -I/SOME/DIRECTORY/gsettings-desktop-schemas
```
Which means to include the version that Meson has configured you need
to drop the directory prefix and only `#include <gdesktop-enums.h>`.
This fixes a build failure with local installs triggered by 775ec67a44
but it's also the right thing to do™.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1370
During animation or other things that cause multiple frames in a row
being painted, we might skip recording frames if the max framerate is
reached.
Doing so means we might end up skipping the last frame in a series,
ending with the last frame we sent was not the last one, making things
appear to get stuck sometimes.
Handle this by creating a timeout if we ever throttle, and at the time
the timeout callback is triggered, make sure we eventually send an up to
date frame.
This is handle differently depending on the source type. A monitor
source type reports 1x1 pixel damage on each view its monitor overlaps,
while a window source type simply records a frame from the surface
directly, except without recording a timestamp, so that timestamps
always refer to when damage actually happened.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1361
Now that we don't use the record function to early out depending on
implicit state (don't record pixels if only cursor moved for example),
let it simply report an error when it fails, as we should no longer ever
return without pixels if nothing failed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1361
Both do more or less the same but with different methods - one puts
pixels into a buffer using the CPU, the other puts pixels into a buffer
using the GPU.
However, they are behaving slightly different, which they shouldn't.
Lets first address the misleading disconnect in naming, and later we'll
make them behave more similarly.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1361
Replace the default master clock with multiple frame clocks, each
driving its own stage view. As each stage view represents one CRTC, this
means we draw each CRTC with its own designated frame clock,
disconnected from all the others.
For example this means we when using the native backend will never need
to wait for one monitor to vsync before painting another, so e.g. having
a 144 Hz monitor next to a 60 Hz monitor, things including both Wayland
and X11 applications and shell UI will be able to render at the
corresponding monitor refresh rate.
This also changes a warning about missed frames when sending
_NETWM_FRAME_TIMINGS messages to a debug log entry, as it's expected
that we'll start missing frames e.g. when a X11 window (via Xwayland) is
exclusively within a stage view that was not painted, while another one
was, still increasing the global frame clock.
Addititonally, this also requires the X11 window actor to schedule
timeouts for _NET_WM_FRAME_DRAWN/_NET_WM_FRAME_TIMINGS event emitting,
if the actor wasn't on any stage views, as now we'll only get the frame
callbacks on actors when they actually were painted, while in the past,
we'd invoke that vfunc when anything was painted.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/903
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
This also changes the view construction path used by the renderer view
to use the new 'add_view()' function, meaning we have a common entry
point for views into the renderer, which will be useful later on.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Before we'd create the view in init(), then continue poking at it in
realize(). Move all of the screen stage view initialization to
realize(), as that's when we have all the dependent state available.
This is possible since there is nothing needing it until realizing.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The clutter "thread" repaint callback are not tied to painting, but
indirectly to updating. What the cursor renderer cares about is when we
actually painted, as this is related to the OpenGL fallback paths.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The mutexes was used by ClutterTexture's async upload and to match GDK's
mutexes on X11. GDK's X11 connection does not share anything with
Clutter's, we don't have the Gdk Clutter backend left, and we have
already removed ClutterTexture, so lets remove these mutexes as well.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The native backend had a plain counter, and the X11 backend used the
CoglOnscreen of the screen; change it into a plain counter in
ClutterStageCogl. This also moves the global frame count setting to the
frame info constuctor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
We currently have mutter set a global frame counter on the frame info in
the native backend, but in order to do this from clutter, change the
frame info construction from being implicitly done so when swapping
buffers to having the caller create the frame info and passing that to
the swap buffers call.
While this commit doesn't introduce any other changes than the API, the
intention is later to have the caller be able to pass it's own state
(e.g. the global frame count) along with the frame info.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
We had time unit conversion helpers (e.g. us2ms(), ns2us(), etc) in
multiple places. Clean that up by moving them all to a common file. That
file is clutter-private.h, as it's accessible by both from clutter/ and
src/.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Currently unused, but it's intention is to use as a initial refresh rate
for a with the stage view associated frame clock. It defaults to 60 Hz
if nothing sets it, but the native backend sets it to the associated
CRTCs current mode's refresh rate.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
We'd check if there was any queued redraw on the stage, but this is
inappropriate for two reasons:
1) A monitor and area screen cast source only cares about damage on a
subset of the stage.
2) The global pending-redraw is going away when paint scheduling will be
more view centric.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Add private API to ClutterBackend to set a fallback resource scale
available to Clutter. This API will be used for "guessing" the
resource-scale of ClutterActors in case the actor is not attached to a
stage or not properly positioned yet.
We set this value from inside mutters MetaRenderer while creating new
stage-views for each logical monitor. This makes it possible to set the
fallback scale to the scale of the primary monitor, which is the monitor
where most ClutterActors are going to be positioned.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1276
The portal API requires a screencast session only for absolution motion
with remote desktop, other methods including relative motion do not
require a screencast session.
There is no reason to be more strict than the API actually is, check for
a screencast session only when required, like for absolute motion events
and touch events.
Tested with https://gitlab.gnome.org/snippets/1122
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1307
This avoids some issues which could happen on some setups[0] due to
meta-native-renderer.c:dummy_power_save_page_flip →
meta_onscreen_native_swap_drm_fb implicitly turning of the primary
plane (by destroying the KMS framebuffer assigned to it):
* drmModeObjectSetProperty could return an "Invalid argument" error
between setting a non-empty cursor with drmModeSetCursor(2) and
enabling the primary plane again:
Failed to DPMS: Failed to set connector 69 property 2: Invalid argument
(This was harmless other than the error message, as we always re-set
a mode on the CRTC after setting the DPMS property to on, which
enables the primary plane and implicitly sets the DRM property to on)
* drmModeSetCursor(2) could return an "Invalid argument" error between
setting the DPMS property to on and enabling the primary plane again:
Failed to set hardware cursor (drmModeSetCursor failed: Invalid argument), using OpenGL from now on
[0] E.g. with the amdgpu DC display code.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1240
We delegate the answer through CoglDriverVtable::is_hardware_accelerated
since this is properly a property of the renderer, and not something the
cogl core should know about. The answer given for the nop driver is
admittedly arbitrary, yes it's infinitely fast but no there's not any
"hardware" making it so.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1194
When a touch sequence was rejected, we'd update the event timestamps of
incoming touch events to help with implementing grabs. This was done by
sending a ClientMessage with a counter, and comparing the counter to
decide whether we're seing a replayed event or not.
This had the unforseen consequence that we would potentially end up
destroying all actors including the stage, since, when mutter receives a
ClientMessage event, it would assume that it's a WM_PROTOCOLS event, and
handle it as such. The problem with this approach is that it would
ignore fact that there might be other ClientMessage types sent to it,
for example the touch synchronization one. What could happen is that the
touch count value would match up with the value of the WM_DELETE_WINDOW
atom, clutter would treat this as WM_PROTOCOLS:WM_DELETE_WINDOW, which
it'd translate to clutter_actor_destroy(stage).
Destroying the stage in such a way is not expected, and caused wierd
crashes in different places depending on what was going on.
This commit make sure we only treat WM_PROTOCOLS client messages as
WM_PROTOCOLS client messages effectively avoiding the issue.
This fixes crashes such as:
#0 meta_window_get_buffer_rect (window=0x0, rect=rect@entry=0x7ffd7fc62e40) at core/window.c:4396
#1 0x00007f1e2634837f in get_top_visible_window_actor (compositor=0x297d700, compositor=0x297d700) at compositor/compositor.c:1059
#2 meta_compositor_sync_stack (compositor=0x297d700, stack=<optimized out>, stack@entry=0x26e3140) at compositor/compositor.c:1176
#3 0x00007f1e263757ac in meta_stack_tracker_sync_stack (tracker=0x297dbc0) at core/stack-tracker.c:871
#4 0x00007f1e26375899 in stack_tracker_sync_stack_later (data=<optimized out>) at core/stack-tracker.c:881
#5 0x00007f1e26376914 in run_repaint_laters (laters_list=0x7f1e2663b7d8 <laters+24>) at core/util.c:809
#6 run_all_repaint_laters (data=<optimized out>) at core/util.c:826
#7 0x00007f1e26b18325 in _clutter_run_repaint_functions (flags=flags@entry=CLUTTER_REPAINT_FLAGS_PRE_PAINT) at clutter-main.c:3448
#8 0x00007f1e26b18fc5 in master_clock_update_stages (master_clock=0x32d6a80, stages=0x4e5a740) at clutter-master-clock-default.c:437
#9 clutter_clock_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at clutter-master-clock-default.c:567
#10 0x00007f1e27e48049 in g_main_dispatch (context=0x225b8d0) at gmain.c:3175
#11 g_main_context_dispatch (context=context@entry=0x225b8d0) at gmain.c:3828
#12 0x00007f1e27e483a8 in g_main_context_iterate (context=0x225b8d0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3901
#13 0x00007f1e27e4867a in g_main_loop_run (loop=0x24e29f0) at gmain.c:4097
#14 0x00007f1e2636a3dc in meta_run () at core/main.c:666
#15 0x000000000040219c in main (argc=1, argv=0x7ffd7fc63238) at ../src/main.c:534
and
#0 0x00007f93943c1f25 in raise () at /usr/lib/libc.so.6
#1 0x00007f93943ab897 in abort () at /usr/lib/libc.so.6
#2 0x00007f9393e1e062 in g_assertion_message (domain=<optimized out>, file=<optimized out>, line=<optimized out>, func=0x7f93933e6860 <__func__.116322> "meta_x11_get_stage_window",
#3 0x00007f9393e4ab1d in g_assertion_message_expr ()
#4 0x00007f939338ecd7 in meta_x11_get_stage_window (stage=<optimized out>) at ../mutter/src/backends/x11/meta-stage-x11.c:923
#5 0x00007f939339e599 in meta_backend_x11_cm_translate_device_event (x11=<optimized out>, device_event=0x55bc8bcfd6b0) at ../mutter/src/backends/x11/cm/meta-backend-x11-cm.c:381
#6 0x00007f939339f2e2 in meta_backend_x11_translate_device_event (device_event=0x55bc8bcfd6b0, x11=0x55bc89dd5220) at ../mutter/src/backends/x11/meta-backend-x11.c:179
#7 0x00007f939339f2e2 in translate_device_event (device_event=0x55bc8bcfd6b0, x11=0x55bc89dd5220) at ../mutter/src/backends/x11/meta-backend-x11.c:208
#8 0x00007f939339f2e2 in maybe_spoof_event_as_stage_event (input_event=0x55bc8bcfd6b0, x11=0x55bc89dd5220) at ../mutter/src/backends/x11/meta-backend-x11.c:284
#9 0x00007f939339f2e2 in handle_input_event (event=0x7fff62d60490, x11=0x55bc89dd5220) at ../mutter/src/backends/x11/meta-backend-x11.c:309
#10 0x00007f939339f2e2 in handle_host_xevent (event=0x7fff62d60490, backend=0x55bc89dd5220) at ../mutter/src/backends/x11/meta-backend-x11.c:413
#11 0x00007f939339f2e2 in x_event_source_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../mutter/src/backends/x11/meta-backend-x11.c:467
#12 0x00007f9393e6c39e in g_main_dispatch (context=0x55bc89dd03e0) at ../glib/glib/gmain.c:3179
#13 0x00007f9393e6c39e in g_main_context_dispatch (context=context@entry=0x55bc89dd03e0) at ../glib/glib/gmain.c:3844
#14 0x00007f9393e6e1b1 in g_main_context_iterate (context=0x55bc89dd03e0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/glib/gmain.c:3917
#15 0x00007f9393e6f0c3 in g_main_loop_run (loop=0x55bc8a042640) at ../glib/glib/gmain.c:4111
#16 0x00007f9393369a0c in meta_run () at ../mutter/src/core/main.c:676
#17 0x000055bc880f2426 in main (argc=<optimized out>, argv=<optimized out>) at ../gnome-shell/src/main.c:552
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/338
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/951https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1317
Add a method to ClutterSeat that allows peeking the list of input
devices and allow looping through devices a bit faster. The API left is
private so we can make use of peeking the GList internally, but don't
have to expose any details to the outside, which means we'd have to
eventually stick with a GList forever to avoid breaking API.
Since we now have the peek_devices() API internally, we can implement
ClutterSeats public list_devices() API using g_list_copy() on the list
returned by peek_devices().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1275
Trying to figure out what this comment was actually about, it turns out
that MSC means Media Stream Counter, and as mentioned in an article[0]
is related to DRI3 and the X11 Present extension. Anyway, the comment
has been there raising questions for some years now, I think we can
remove it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
The ID and name are just moved into the instance private, while the rest
is moved to a `MetaCrtcModeInfo` struct which is used during
construction and retrieved via a getter. Opens up the possibility to
add actual sub types.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
Just as with MetaOutput, instead of the home baked "inheritance" system,
using a gpointer and a GDestroyNotify function to keep the what
effectively is sub type details, make MetaCrtc an abstract derivable
type, and make the implementations inherit it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
Instead of the home baked "inheritance" system, using a gpointer and a
GDestroyNotify function to keep the what effectively is sub type
details, make MetaOutput an abstract derivable type, and make the
implementations inherit it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
Now set as a property during construction. Only actually set by the
Xrandr backend, as it's the only one currently not supporting all
transforms, which is the default.
While at it, move the 'ALL_TRANFORMS' macro to meta-monitor-tranforms.h.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
The output info is established during construction and will stay the
same for the lifetime of the MetaOutput object. Moving it out of the
main struct enables us to eventually clean up the MetaOutput type
inheritence to use proper GObject types.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
MetaCrtcInfo and MetaOutputInfo did not represent information about
MetaCrtc and MetaOutput, but the result of the monitor configuration
assignment algorithm, thus rename it to MetaCrtcAssignment and
MetaOutputAssignment.
The purpose for this is to be able to introduce a struct that actually
carries information about the CRTCs and outputs, as retrieved from the
backend implementations.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
That is is_presentation, is_primary, is_underscanning and backlight.
The first three are set during CRTC assignment as they are only valid
when active. The other is set separately, as it is untied to
monitor configuration.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
It was used during configuration to ensure that we always dealt with
every output and CRTC. Do this without polluting the MetaOutput and
MetaCrtc structs with intermediate variables not used by the
corresponding types themself.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
When the stage views the stage is shown on are changed, ClutterStage
currently provides a clutter_stage_update_resource_scales() method
that allows invalidating the resource scales of all actors. With the new
stage-views API that's going to be added to ClutterActor, we also need a
method to invalidate the stage-views lists of actors in case the stage
views are rebuilt and fortunately we can re-use the infrastructure for
invalidating resource scales for that.
So since resource scales depend on the stage views an actor is on,
rename clutter_stage_update_resource_scales() and related methods to
clutter_stage_clear_stage_views(), which also covers resource scales.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1196
Using XDG_CONFIG_HOME allows users to place their keyboard configuration into
their home directory and have them loaded automatically.
libxkbcommon now defaults to XDG_CONFIG_HOME/xkb/ first, see
https://github.com/xkbcommon/libxkbcommon/pull/117
However - libxkbcommon uses secure_getenv() to obtain XDG_CONFIG_HOME and thus
fails to load this for the mutter context which has cap_sys_nice.
We need to manually add that search path as lookup path.
As we can only append paths to libxkbcommon's context, we need to start with
an empty search path set, add our custom path, then append the default search
paths.
The net effect is nil where a user doesn't have XDG_CONFIG_HOME/xkb/.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/936
When we created the DMA buffer backed CoglFramebuffer, we handed it over
to CoglDmaBufHandle which took its own reference. What we failed to do
was to release our own reference to it, effectively leaking it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1283
The stream will clean up the buffers, so let it do that before we
destroy them under its feet. Note that it'll only do this after the
following PipeWire commit:
commit fbaa4ddedd84afdffca16f090dcc4b0db8ccfc29
Author: Wim Taymans <wtaymans@redhat.com>
Date: Mon Jun 1 15:36:09 2020 +0200
stream: allow NULL param and 0 buffers in disconnect
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1283
This cannot be made to work reliably. Some factoids:
- Internal devices may be connected via USB.
- The ACPI spec provides the _PLD (Physical location of device) hook to
determine how is an USB device connected, with an anecdotal success
rate. Internal devices may be seen as external and vice-versa, there is
also an "unknown" value that is widely used.
- There may be non-USB keyboards, the old "AT Translated Set 2 Keyboard"
interface does not change on hotplugging.
- Libinput has an internal series of quirks to classify keyboards as
internal of external, also with an "unknown" value.
These heuristics are kinda hopeless to get right by our own hand. Drop
this external keyboard detection in the hope that there will be something
more deterministic to rely on in the future (e.g. the libinput quirks
made available to us directly or indirectly).
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2378
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2353https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1277
Move Wayland support (i.e. the MetaWaylandCompositor object) made to be
part of the backend. This is due to the fact that it is needed by the
backend initialization, e.g. the Wayland EGLDisplay server support.
The backend is changed to be more involved in Wayland and clutter
initialization, so that the parts needed for clutter initialization
happens before clutter itself initialization happens, and the rest
happens after. This simplifies the setup a bit, as clutter and Wayland
init now happens as part of the backend initialization.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
We failed to use the buffer age when monitors were rotated, as when they
are, we first composite to an offscreen framebuffer, then later again to
the onscreen. The buffer age checking happened on the offscreen, and an
offscreen being single buffered, they can't possible support buffer
ages.
Instead, move the buffer age check to check the actual onscreen
framebuffer. The offscreen to onscreen painting is still always full
frame, but that will be fixed in a later commit.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
Will be used for logging to identify what view a log entry concerns. For
the native and nested backend this is the name of the output the CRTC is
assigned to drive; for X11 it's just "X11 screen", and for the legacy
"X11 screen" emulation mode of the nested backend it's called "legacy
nested".
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
We don't have enough Xlib code in mutter ...
Joking aside, it can be useful to make the cursor invisible
without hiding it, for example for replacing the actual cursor
with an actor in gnome-shell; the real cursor should still
update the focus surface in that case, and not sneak into
screenshots or -casts.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1244
We're iterating inside the PipeWire loop when detecting PipeWire errors,
and shouldn't destroy the PipeWire objects mid-iteration. Avoid this by
first disabling the stream src (effectively stopping the recording),
then notifying about it being closed in an idle callback. The
notification eventually makes the rest of the screen cast code clean up
the objects, including the src and the associated PipeWire objects, but
will do so outside the PipeWire loop iteration.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1251https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1251
In the native backend, the MetaRenderer manages the view by creating one
per CRTC, but until now the MetaStageX11 managed the view for the X11
backend. This caused some issues as it meant meta_renderer_get_views()
not returning anything, and that the view of the X11 screen not being a
MetaRendererView, while in the other backends, all views are.
Fix this by moving the view management responsibility to
MetaRendererX11Cm, and have MetaStageX11 only operate on it via
meta_renderer_x11_cm_*() API. The MetaRendererX11Cm takes care of making
sure the view is always added to the list in the renderer, and turning
X11 screen sizes into "layouts" etc.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1251
"Legacy" is a misleading name, it's just how the native backend and the
X11 backend behaves differently. Instead rename it to 'add_view()' and
add the sanity check to the caller.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1251
They all checked that the remote session service talked with the
correct peer, and some of them did check that there is an associated
screencast session.
Add a new check for the session being started (as it's state is
decoupled with screencast session availability) and move all checks
to a function that is called from all input-oriented DBus methods.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1254https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1258
It was removed in 3.34 as part of 6ed5d2e2. And we thought that was the
only thread that might exist and use X11. But the top gnome-shell crasher
in 3.36 seems to suggest otherwise.
We don't know what or where the offending thread is, but since:
1. We used XInitThreads for years already prior to 3.34; and
2. Extensions or any change to mutter/gnome-shell could conceivably use
threads to make X calls, directly or indirectly,
it's probably a good idea to reintroduce XInitThreads. The failing assertion
in libx11 is also accompanied by a strong hint:
```
fprintf(stderr, "[xcb] Most likely this is a multi-threaded client " \
"and XInitThreads has not been called\n");
```
https://bugs.launchpad.net/bugs/1877075
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1252https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1256
Commit e06daa58c3 changed the tested values to use corresponding valid
enum values instead of negative ones. Unfortunately that made one value
become a duplicate of an existing one and also in part defeated the original
intention of checking the implementation of
`meta_output_crtc_to_logical_transform`.
Use `meta_monitor_transform_invert` to fix both shortcomings.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1242
The 'assert_size' command checks that the size of the window, both
client side and compositor side, corresponds to an expected size set by
the test case.
The size comparison can only be done when the window is using 'csd', in
order for both the client and server to have the same amount of
understanding of the title bar. For ssd, the client cannot know how
large the title bar, thus cannot verify the full window size.
Sizes can be specified to mean the size of the monitor divided by a
number. This is that one can make sure a window is maximized or
fullscreened correctly.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
We were iterating through evcodes, but using API that expects Clutter button
numbers. Instead of transforming those to Clutter numbers to have those translated
back, use the inner seat API that already takes evcodes.
Fixes stuck buttons keys after a virtual device is destroyed while those are
pressed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1239
Inhibiting remote access means any current remote access session is
terminated, and no new ones can be created, until remote access is
uninhibited. The inhibitation is ref counted, meaning there can be more
than one inhibitor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1212
It takes coordinates in stage coordinate space, and will result in
a screen cast stream consisting of that area, but scaled up by the scale
factor of the view that overlaps with the area and has the highest scale
factor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
Will be used by the stage to not paint the overlays. We skip all
overlays since overlays are only ever used for pointer cursors when the
hardware cursors cannot or should not be used.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
These phase callbacks are not intended to be inovked when something
secondary is painting the stage, such as a screen cast stream, or
similar. Thus, only invoke the callbacks when there is a view associated
with the paint context, which will not be the case for offscreen
painting.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
If there is a paint context available (i.e. for the phases that are
during the actual stage paint), pass it along the callbacks, so that
the callback implementations can change their operation depending on the
paint context state.
This also means we can get the current view from the paint context,
instead of the temporarily used field in the instance struct.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
If drmModePageFlip() or custom_page_flip_func fails, process_page_flip() was
forgetting to undo the ref taken for that call. This would leak page_flip_data.
The reference counting works like this:
- when created, ref count is 1
- when calling drmModePageFlip, ref count is increased to 2
- new: if flip failed, ref count is decreased back to 1
- if calling schedule_retry_page_flip(), it takes a ref internally
- if calling mode_set_fallback(), it takes a ref internally
- all return FALSE paths have an explicit unref
- return TRUE path has an explicit unref
This issue was found by code inspection and while debugging an unrelated issue
with debug prints sprinkled around. I am not aware of any end-user visible
issues being fixed by this, as the leak is small and probably very rare.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1209
When testing a laptop with intel and DisplayLink devices, attempting to set the
DL output as the only active output resulted in GNOME/Wayland freezing. The
main event loop was running fine, but nothing on screen would get updated once
the DL output become the only one. This patch fixes that issue.
DisplayLink USB 3 devices use an out-of-tree kernel DRM driver called EVDI.
EVDI can sometimes fail drmModePageFlip(). For me, the flip fails reliably when
hotplugging the DL dock and when changing display configuration to DL only.
Mutter has a workaround for failing flips, it just calls drmModeSetCrtc() and
that succeeds.
What does not work reliably in the fallback path is Mutter keeping track of the
pageflip. Since drmModePageFlip() failed, there will not be a pageflip event
coming and instead Mutter queues a callback in its stead. When you have more
than one output, some other output repainting will attempt to swap buffers and
calls wait_for_pending_flips() which has the side-effect of dispatching any
queued flip callbacks. With multiple outputs, you don't get stuck (unless they
all fail the exact same way at the same time?). When you have only one output,
it cannot proceed to repaint and buffer swap because the pageflip is not marked
complete yet. Nothing dispatches the flip callback, leading to the freeze.
The flip callback is intended to be an idle callback, implemented with a
GSource. It is supposed to be called as soon as execution returns to the main
event loop. The setup of the GSource is incomplete, so it will never dispatch.
Fix the GSource setup by setting its ready-time to be always in the past. That
gets it dispatched on the next cycle of the main event loop. This is now the
default behavior for all sources created by meta_kms_add_source_in_impl().
Sources that need a delay continue to do that by overriding the ready-time
explicitly.
An alternative solution could have been to implement GSource prepare and check
callbacks returning TRUE. However, since meta_kms_add_source_in_impl() is used
by flip retry code as well, and that code needs a delay through the ready-time,
I was afraid I might break the flip retry code. Hence I decided to use
ready-time instead.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1209
When closing the lid of a laptop, we reconfigure all the monitors in order
to update the CRTCs and (if enabled) the global UI scaling factor.
To do this, we try first to reuse the current configuration for the usable
monitors, but if we have only monitor enabled and this one is on the laptop
lid we just end up creating a new configuration where the primary monitor is
the laptop one (as per find_primary_monitor() in MetaMonitorConfigManager),
but ignoring the user parameters.
In case the user selected a different resolution / scaling compared to the
default one, while the laptop lid is closed we might change the monitors
layout, causing applications to rescale or reposition.
To avoid this, when creating the monitors configuration from the current
current state, in case we have only one monitor available and that one is
the laptop panel, let's just reuse this configuration.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1200
While this is fairly incomplete, as to check things fully we need to use
TEST_ONLY in atomic to try out a complete assignment on the device, but
this works well enough for legacy non-modifier cases.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
