With EI support wired to XTEST, and oeffis being enabled in Xwayland
means that XTEST will always go through the XDG portal.
While this the intended behavior for the general use case of Xwayland
running rootless on a desktop compositor, that breaks when Xwayland is
running on a nested compositor, because the portal is for the entire
session and not limited to the nested Wayland compositor.
Enable XDG portal support in Xwayland only when we managed to connect
to the GNOME session manager, which means we are running in a full
desktop session, and not in any form of nested mode.
This is determined by simply using the status returned by set_gnome_env()
which will fail if not connected to a GNOME Session manager.
See-also: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1586
See-also: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1170
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3047
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3303>
The function set_gnome_env() is used to pass environment variables
though DBus using the "org.gnome.SessionManager".
If that fails, it means we are not running in a full environment, which
might be useful to determine whether Xwayland should enable the portal
support.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3303>
This makes sure the new update takes effect over the pending update for
any common properties. It matches the other users of
meta_kms_update_merge_from.
Fixes: 27ed069766 ("kms/impl-device: Add deadline based KMS commit scheduling")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3316>
When a configuration has a fractional scale, but we're using a physical
monitor layout, we can't use the scale, but if we do, we end up with
wierd issues down the line. Just discard the config if we run into this.
Eventually we probably want to store the layout mode in the
configuration so we can handle more seamless switching between physical
and logical layout mode, but first do this.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3057
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3299>
The surface actors may not have a valid allocation when running the
test. The preferred height, which `clutter_actor_get_size()` returns
in that case, can be wrong in certain cases, making us not add the black
background when it's actually needed.
Query the allocation instead, even at the expense of additional
relayouts.
While on it, sneak it some small cleanups.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3024
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3310>
There's two aspects from its documentation
(https://xkbcommon.org/doc/current/group__state.html#gae56031a8c1d48e7802da32f5f39f5738)
affecting us here:
1. "This function is similar to xkb_state_key_get_syms(), but intended for
users which cannot or do not want to handle the case where multiple
keysyms are returned (in which case this function is preferred)."
We are indeed in that field, and have been for a long time.
2. "This function performs Capitalization Keysym Transformations."
This is unlike the xkb_key_get_syms() function that we use, and
convenient here for parity with X11 since it behaves exactly that
way.
Fixes cases where the keysym for some keys is not properly capitalized
when caps lock is toggled, due to the output of capslock+key being
different from shift+key. An example of this is 'é' in french(azerty)
layout (bound to the '2' key). Even though shift+2 outputs '2',
capslock+é should output 'É'.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3058
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3306>
This is similar, but reserved for the crossing events induced by the
input shape changes on our overlay window. The mechanism in the previous
commit does again protect against this, so this mechanism may go away.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3267>
Focus follows mouse is meant to avoid focusing windows that happened
to pop up under the pointer, e.g. due to mapping, workspace changes,
etc... On X11, this has been done since ancient times through a
moderately complex synchronization mechanism, so mutter would know
to ignore crossing events caused on those situations.
This mechanism is much prior to XInput 2 though, where we may know
this in a more straightforward way: If the sourceid of the crossing
event is a logical pointer (i.e. equals deviceid), the crossing event
was triggered logically, and not through user input.
Perform this simpler check, and drop the existing mechanism to
ignore logically induced crossing events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3267>
The virtual stream source with CURSOR_MODE_EMBEDDED uses
META_STAGE_WATCH_AFTER_PAINT as the callback for recording its frame. In
this stage of the paint though, there is no ClutterPaintContext anymore
(there only is a paint context during the paint, not afterwards).
The callback (actors_painted()) tries to get the redraw clip from the paint
context, and we end up with a NULL pointer crash.
We actually do still have a redraw clip at this point, so because everyone
uses the paint context to get the redraw clip anyway, just pass the redraw
clip to the stage watches directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3283>
After an event has been handled such that it bypasses both Clutter and
Wayland, e.g. when handling a keybinding, bypass_clutter would get
unset in the presence of a wayland grab. This means that the event is
handled both as a keybinding and by Clutter.
In the case of switcher popups in gnome-shell in the presence of a gtk4
autohide popover this meant that instead of selecting the next element,
it would select the one after that. If there are only two elements, as
is common with input sources, this would mean going back to the current
one, preventing switching them with a single press of the keybinding.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6738
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3054>
When a device is added, libei does not allow adding additional regions
for that particular device, as it is already advertised to the EI
client.
As a result, mutter currently effectively only adds the first region to
a device, but not the others.
This makes input in multi monitor sessions only possible on one monitor,
as the EI client cannot look up the other regions, since they were not
advertised to it.
Fix this situation by not adding and resuming the device, when a shared
device is used.
Instead, for shared devices, always add all regions first, and then
after that, add and resume the device.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3273>
Use the previously added API to release acquired mapping ids, when the
corresponding stream is destroyed.
Otherwise, the remote desktop session would maintain a whole bunch of
unused mapping ids, as their corresponding streams are already
destroyed, but maybe not the session.
Such situation would be a remote multimonitor session, where the amount
of used virtual monitors changes multiple times during the session.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3273>
The remote desktop session currently provides a mechanism to acquire
mapping ids.
However, when they are not used anymore, they currently cannot be
removed and thus just linger around.
So, add an API to release these acquired ids.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3273>
Avoid passing the MetaSeatImpl, since it may be potentially null at
MetaSeatNative construction time. An example of this triggering issues
are mousekeys, since those work on an emulated pointer device created
indirectly after a keyboard device is added (and the right settings are
enabled) at a time that the MetaSeatImpl is still being created, so the
MetaSeatNative cannot yet have a reference to it.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2869
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3278>
These objects already have a pointer to the ClutterSeat that has a
pointer to the MetaSeatImpl in its native implementation. This data
may be considered pretty much immutable (a pointer to the seat is
held, and the native implementation will shut down the implementation
thread within ClutterSeat finalization.
Avoids some awkward code, since the MetaInputDeviceNative needs to
be aware of the Clutter object implementation and the implementation
object.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3278>
vc4's implementation of `drmModeAtomicCommit` seems to require a few
milliseconds advanced notice or else it will miss the frame deadline.
That's too high for our deadline evasion threshold which is measured
in microseconds. Let's stop trying to use deadline timers on vc4 to
avoid this conflict without having to disable atomic KMS.
Suggested-by: Jonas Ådahl <jadahl@gmail.com>
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2953
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3279>
It's the 10 bit equivalent to NV12 and uses the same layout as P016, i.e.
16 bit components with the lowest 6 bits set to 0 (padding), allowing us
to use 16 bit "subformats".
Thus adding support is quite trivial as we can reuse the NV12 shader.
The format is widely supported in decoding and display hardware (on Intel
since Kaby Lake), as well as modern codecs (AV1, VP9, HEVC) and has
visible quality advantages over NV12.
Note that the additional colors are lost if composited to a 8 bit RGB
framebuffer. Switching between direct scanout and compositing can thus
cause quality differences. This is no new phenomena, however, as the
same is the case already for e.g. GL clients using 10 bit formats -
including video players.
Also note that P012 and P016 could trivially added as well - it's not
done here as they are uncommen and thus hard to test.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3244>
These shaders can be used for similar formats with other component
sizes since the values are represented as floats. So whether the source
value was stored in 8bit, 10bit or 16bit doesn't matter - the driver
will covert it for us.
Thus use a Weston-inspired, more general naming scheme.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3244>
They are needed as "subformats" for higher bit YCbCr formats, such as
P010, and we don't plan to use or expose them otherwise. Thus don't
implement any conversion or packing features.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3244>
Realizing a cursor will assume view related state objects are valid so
they can mark them as dirty. This assumption broke when there were a
scale changed that happened with multiple CRTCs, as we'd create view
object by view object as we realized the texture. Realizing the texture
would trigger a signal that had the handler assuming the validity of all
view objects, but if we only had gotten to the first, the second view
would not be there yet, thus we'd be doing a NULL pointer dereference.
Creating the view objects first, then handling the updating avoids this
problem by making the already done assumption valid on hotplugs.
The test case added tests exactly this series of events, and uses a
virtual monitor as a cheap trick to make the KMS CRTC based view the
first one, and an arbitrary view the second that previously had its view
object initialized too late.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3012
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3262>
The cursor surface is decided by the "current" surface; if that alone
changed (e.g. current surface was destroyed), we didn't update the
cursor, meaning it either got stuck, or got hidden if the client exited
completely.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3262>
It's hard to tell why turning on HDR mode failed without these log
messages. It could be missing support in the sink (EDID/DisplayID) or
missing support in the driver/display hardware (connector properties) or
just a failure turning it on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3251>
When the actor gets a new "main" surface assigned, it adds the
new surface to the stack of surface actors, but forgets to remove
the old one.
This stale pointer in the array may cause invalid reads and crashes
after the assigned surface is disposed, e.g. when destroying the
MetaWindowActor tries to disconnect signals from all accounted
surface actors.
Fixes: 9a2c8b2592 ("window: Add suspend state")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3252>
Commit 3bfcb6d1 fixed the check for tiling via keybindings, but
ignored a subtle edge case when tiling with the pointer: The
monitor used for tiling is the monitor with the pointer, which
is not necessarily the one that contains the largest part of the
window.
That is, the correct monitor to check against depends on the
context where the function is called. We can either figure
it out automatically via the current window drag, or make it
a parameter.
The latter is clearer, because the callers already decide which
monitor to use for tiling anyway.
Fixes: 3bfcb6d1b9 ("window: Fix portrait orientation check for tiling")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3248>
These snippets are retrieved anew every time a window is resized. But
callers never modify them, they're effectively read-only so cache them
at the place of creation.
This is required to convince the pipeline hash that each reuse of the
same snippet really is the same snippet and so the pipeline is unchanged.
`CoglPipelineSnippetList` only does shallow comparisons and there's no
need right now to reimplement it as a deep comparison.
This eliminates the log message:
> Over 50 separate %s have been generated which is very unusual,
> so something is probably wrong!
which isn't actually a leak but more a warning about wasting time.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6958
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3224>
GInitable initialization is failable, currently, it may fail before error
traps are initialized, but error traps would be invariably deinitialized on
finalize() of the failed object. This results in an assert hit, on top of the
original failure to initialize the backend.
The libX11 error handlers are a pure client-side construct, and not a server
request, they just need XInitThreads() called to set up the library-side locks
protecting access to the global variable. This is done beforehand already at
meta_backend_x11_init(), so initialize the error traps around that time too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3242>
Commit 9c3b130f67 changed slightly destruction order to handle use-after-free
situations, but missed a small new one introduced by the order change: The
MetaX11Display may schedule callbacks through MetaLaters, which depend on the
MetaCompositor, which is now freed before the MetaX11Display.
Since there is no winning move here, make the MetaX11Display aware of this
by avoiding to remove the callback if the MetaCompositor is already gone.
The MetaLaters infrastructure is already fully freed at this point (incl. the
data it contained), so this shouldn't be a leak.
Fixes: 9c3b130f67 ("display: Fix destruction order")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3247>
Use work area from the monitor that the window is currently on to
determine if tiling should be allowed.
Window tiling is disabled for monitors with portrait orientation, but
the work area we use to detect portrait orientation is taken from the
monitor that currently has the mouse pointer.
This works fine for edge tiling using the mouse, but this is broken when
using keybindings for window tiling because your mouse pointer could be
on a different monitor that has horizontal orientation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3199>
While adjusting the monitor layout of my docked laptop, mutter got a
segfault while attempting to dereference the frame_info struct. This
happened on gnome-shell 44.4-1.fc38.
cogl_onscreen_peek_head_frame_info() just forwards the call to
g_queue_peek_head() which returns NULL in the event that the queue is
empty. If finish_frame_result_feedback() is expected to always be called
with a non-empty queue there's still a bug somewhere, but regardless
this API can legitimately return NULL so it should be checked for prior
to dereferencing.
Fixes: 61801a713a ("onscreen/native: Avoid freezing the frame clock on failed cursor commits")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3229>
If we are making an update that only disables CRTCs, we would not
actually post it, but just drop it then post nothing, as it wasn't ever
added to the mode set update hash table. This resulted in hotplugs where
we loose the all the connectors we had, where we want to disable all
CRTCs and enable nothing, to fail to disable said CRTCs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3073>
This removes the implicit dependency on `display->stack_tracker`
existing and being valid in `on_stack_changed()` because
now it is the stack-tracker's responsibility to subscribe
to the "changed" signal of the stack and handle the changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3202>
The _NET_WM protocol, written before the birth of XInput 2.x, does have
no notion of different input devices whatsoever. Anyways, in a X11 session
it is safe to assume this refers about the Virtual Core Pointer since
every input device by default drives it (incl. touchscreens through the
"pointer emulating sequence", and styli).
This assumption falls apart in a Wayland session with non-pointer input,
since we do actually distinguish between all the distinct pointer devices
and touchpoints, and do not let them emulate mouse input.
We do need to specify a device/sequence there to drive the window
move/resize operation. The _NET_WM_MOVERESIZE message just gives us the
x/y root coordinates the resize was started from, so work from there
into guessing what is the most likely device/sequence that did trigger
the request on the client side.
Conversely, on Wayland we do not need to check for possible race
conditions in the pressed button states since we have larger guarantees
about not missing these events if we checked for the button modifier
mask beforehand, so make that race condition check specific to the
X11 sessions.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2836
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3059>
There can be events which don't not have source devices set on them, because
they are not backed by real hardware and rather generated by us, for example
IM events coming from the shell's OSK.
So don't assume all events have a source device in
update_pointer_visibility_from_event() and rather ignore those without one,
as we are only interested in events coming from "real hardware" here.
This fixes an issue where the mouse pointer would appear on devices without
any input from actual mice/touchpads on OSK key presses.
Fixes: 6aa42d6dad
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3236>
When we call get_grab_info() to get the sequence, device and coordinates for
a touch window drag, as the device we use the device from the
MetaWaylandPointer, assuming that it's set to the core pointer.
In the case where there is no pointer device present on the seat (so no
mouse nor touchpad), the wayland pointer remains disabled though, and
pointer->device is NULL.
This means touch window dragging on hardware without pointer devices
present is broken (because MetaWindowDrag assumes that there's a valid
device passed in meta_window_drag_begin()). Fix it by taking the core
pointer directly from ClutterSeat instead of going the extra detour through
MetaWaylandPointer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3238>
If meta_eis_viewport_get_position() returned FALSE, the variable
'has_position' would be initialized. This variable represents
exactly the return value of meta_eis_viewport_get_position(),
so just assign it to the variable directly.
Spotted by Coverity.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3237>
CLUTTER_SCROLL_SOURCE_UNKNOWN only generates continuous scroll events
and no discrete scroll events.
As a result, scrolling only works in applications, that support high
resolution scroll wheels, like GTK4 applications.
GTK3 applications, on the other hand, don't support high resolution
scroll wheel events, and such scrolling does not work in these
applications.
Fix this issue by using the scroll source CLUTTER_SCROLL_SOURCE_WHEEL.
Since commit 92a90774a4 ([0]),
CLUTTER_SCROLL_SOURCE_WHEEL generates discrete events to ensure that
scrolling in legacy applications still works.
[0]: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2664
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3235>
We need to trigger a mode set when power-save changes to 'on' if it's
purely about power saving, but when they arrive as part of a hotplug
event, we'll handle all that later, in the monitors-changed handling,
that contains the new configuration.
This avoids a crash that happens due to the mode set being queued on now
disabled connectors.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2985
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3233>
We can change power save mode for two reasons: gsd-power told us to, or
we saw a hotplug event. Sometimes it's useful to be able to make the
distinction to why a power save mode changed, so add a reason to the
signal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3233>
If the deadline timer is disabled (like on nvidia-drm or when
`MUTTER_DEBUG_KMS_THREAD_TYPE=user`), then we need to call
`meta_kms_device_set_needs_flush` on every cursor movement. But some were
getting skipped if they coincided with page flips, which resulted in some
cursor movements failing to schedule the frame clock. This resulted in
unnecessary levels of frame skips when using lower frequency input devices
which are less likely to provide another event within the same frame period.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3002
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3210>
Add a pair of calls to ensure the error trap infrastructure
survives for the MetaBackend. This will help on later commits that
largely operate on the MetaBackendX11 Display.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3230>
Keep a per-display list of error traps, so we don't mix them
together, and possibly deem unintended error traps outdated.
This means init/deinit calls are now stackable, and need to
happen evenly. In order to honor this, move the MetaX11Display
error trap destrution to finalize.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3230>
This forces not using the seat_proxy. But still allows the use of
session_proxy.
On tests, headless mode is explicitly set and it might not be available a
systemd session. To avoid test failing on this situation skip using
meta_launcher wich uses session_proxy and seat_proxy.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3093>
If we're a input-only remote desktop session, create libei regions on an
absolute pointer device corresponding to all logical monitors. This
allows absolute pointer motions without screen casting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3228>
Sometimes it makes no sense to have a shared pointer device, for example
when they have no set region occupying the global stage coordinate
space. This applies to for example window screen cast based pointer
device regions - they are always local to the window, and have no
position.
We do need shared absolute devices in some cases though, primarily
multi-head remote desktop, where it must be possible to keep a button
reliably pressed when crossing monitors that have their own
corresponding regions.
To handle this, outsource all this policy to the one who drives the
emulated input devices. Remote desktop sessions where the screen casts
correspond to specific monitors (physical or virtual), we need to make
sure they map to the stage coordinate space, while for window screencast
or area screencasts, we create standalone absolute pointer devices with
a single region each.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3228>
We already have the remote desktop session ID, and we'll soon need the
actual remote desktop session in the screen cast session, so pass it on
construction.
The old screen cast type is set implicitly instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3228>
A MetaEisViewport represents an absolute region backend by e.g. a
pointer device. There are two kinds: a standalone viewport, which
corresponds to a viewport that has no neighbours, and a non-standalone,
which represents a region of a global coordinate space.
The reason for having non-standalone viewports is to allow to mirror the
logical monitor layout of a desktop, while the standalone are meant to
represent things that are not part of the logical monitor layout.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3228>
How EIS will be used depends on its context, meaning we'll have multiple
EIS contexts that expose different things. To prepare for this remove
the global socket since that won't work with multiple contexts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3228>
This fixes a compiler warning:
```
src/x11/events.c:523:1: warning: ‘get_event_name’ defined but not used [-Wunused-function]
523 | get_event_name (MetaX11Display *x11_display,
| ^~~~~~~~~~~~~~
```
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3223>
This used to be the behavior, until commit 5d35138df0 changed the meaning
of the return value of MetaCursorRendererClass::update_cursor(). This
made the user of pure-overlay cursors (singular, MetaWaylandTabletTool)
miss their overlays.
Change the return value, so that it matches the desired behavior of
a backend-less overlay-only cursor renderer.
Fixes: 5d35138df0 ("cursor-renderer: Make 'handled_by_backend' state 'needs_overlay'")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3218>
We react on changes to has_hw_cursor, but always try to inhibit if
there is no cursor sprite. While this looks like a reasonable optimization
with the typical situation of one cursor renderer, it may fall into
inhibiting twice without knowing to unwind, e.g.:
1. has_hw_cursor: TRUE, cursor_sprite: !=NULL -> inhibit
2. has_hw_cursor: FALSE, cursor_sprite: NULL -> inhibit
3. has_hw_cursor: TRUE, cursor_sprite: !=NULL -> uninhibit, but once
And this may also result in the CLUTTER_PAINT_FLAG_NO_CURSORS flag
staying on for Tablet cursors, that (so far) always use overlay paths.
This results in invisible tablet cursors after using the mouse at
least once.
Fixes: e52641c4b6 ("cursor-renderer/native: Replace HW cursor with KMS cursor manager")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3218>
Under strange timings, the GTK frames client may implicitly queue
relayouts that end up disagreeing with the latest frame size as
given by Mutter, this results in GTK calling XResizeWindow, and
Mutter plain out ignoring the resulting XConfigureRequestEvent
received.
This however makes GTK think there's pending resize operations,
so at the next resize it will freeze the window, until enough
resizes happened to thaw it again. This is seen as temporary
loss of frame-sync ness (e.g. frozen frame, and other weird
behavior).
In order to make GTK happy and balanced, reply to this
XConfigureRequest, even if just to ignore it in a more polite
way (we simply re-apply the size Mutter thinks the frame should
have, not GTK), this results in the right amount of
ConfigureNotify received on the frames client side, and the
surface to be thawed more timely, while enforcing the size as
managed by Mutter.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2837
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3189>
This is meant for compatibility purposes with the shell extensions
avoiding to break a bunch of them in the last minute and we would
drop it in the GNOME 46 release.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3128>
Currently, Meta/Cogl/Clutter makes use of cairo_rectangle_int_t despite
the existance of MetaRectangle.
In order to make MetaRectangle usable in Cogl/Clutter as well, Mtk would
provide such base types that are shared across the various private
libraries
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3128>
Dropped obsolete Free Software Foundation address pointing
to the FSF website instead as suggested by
https://www.gnu.org/licenses/gpl-howto.html
keeping intact the important part of the historical notice
as requested by the license.
Resolving rpmlint reported issue E: incorrect-fsf-address.
Signed-off-by: Sandro Bonazzola <sbonazzo@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3155>
This used to be the case before the refactor at commit 43cee4b6b6,
use_clipped_redraw would be unset before the larger check if has_buffer_age
was set, but clutter_damage_history_is_age_valid() was FALSE. This got
replaced by a check just on the latter, which will also be FALSE if
has_buffer_age is not present.
We have other means to achieve clipped redraws, so this slight change
culled all of them.
Fixes: 43cee4b6b6 ("stage-impl: Do clipped redraws when drawing offscreen")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2771
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3221>
This changes how state is tracked by introducing an explicit state. We
need this since we use asynchronous calls to the out of process
component that handles actual inhibitation, including idleness.
This means if inhibitations changes rapidly, we might end up with an
incorrect state if we e.g. try to uninhibit while we're currently trying
to inhibit.
This is done by adding a state variable that accounts for the pending
state, as well as the active state, with a function that looks at the
current conditions to derive what state we should be in, and what state
we are in, to decide what the next action should be.
For example, if we're trying to inhibit, but now wants to uninhibit,
we'll wait for the inhibit call to complete, recheck what we want, which
would result in an async uninhibit call being made.
Fixes: 388b534062 ("wayland: Implement idle inhibit protocol")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3219>
This fixes the following
1. Minimize window; minimize animation starts
2. Do something that immediately destroys the animated actor (e.g. terminate)
3. This triggered the timeline of the animation to emit a "stopped"
signal while all transitions of the actor were destroyed
Previously we'd implicitly animate the scale again (set_scale(..)) which
created a new transition The hash table iterator didn't like this and
abort():ed
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3213>
The 'suspend state' is meant to track whether a window is likely to be
visible any time soon. The hueristics for this are as follows:
* If a window is hidden, it will enter the 'hidden' state.
* If a window is visible, and unobscured, it will enter the 'active'
state.
* If a window is visible, but obscured by another window, it will enter
the 'hidden' state.
* If there is a mapped clone of a window, it will enter the 'active'
state.
* If the window has been in the 'hidden' state for 3 seconds, it will
enter the 'suspended' state.
This will eventually be communicated to Wayland clients so that they can
change their behaviour to e.g. save power.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3019>
Previously it transformed a physical CRTC coordinate to a logical desktop
coordinate. But current and future users of the function all require
conversion from logical coordinates to physical coordinates. We would have
had to always invert the transform parameter which is a waste of time when
we can instead just invert the function behaviour.
We also simplify the parameters to show both the point coordinate and the
area dimensions are potentially transformed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3180>
When creating a new stream, check if the preferred format is
different from the default (COGL_PIXEL_FORMAT_BGRX_8888). If
it is, then also include it in the list of potential formats
for the stream.
COGL_PIXEL_FORMAT_BGRX_8888 is still passed around as it's
both the default, and the fallback for when things go wrong.
When creating buffers, use the negotiated SPA format instead
of a hardcoded value. We leave it to PipeWire to figure out
what's the best format, since clients may not support the
preferred format of the stream.
Due to how chaotic things got, this commit also cleans up
the create_pipewire_stream() to use an auxiliary array of
SPA formats, which is then iterated on in order to generate
the format pods.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3175>
In future commits, we will want to create DMA-BUFs with pixel
formats other than COGL_PIXEL_FORMAT_BGRX_8888. In preparation
for that, let's start passing a new pixel format parameter to
this function, and the corresponding winsys vfunc.
All callers of this function pass COGL_PIXEL_FORMAT_BGRX_8888
for now. Next commits will change that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3175>
Freeing the window opaque region rather than the frame one when was
leaking the frame opaque region and wrongly setting the window opaque
region to NULL.
Fixes: 82b2b7688 ("core: Add infrastructure to keep window frames' opaque regions")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3188>
This is something the compositor could now track by itself, instead of
being pushed through events. It also makes more sense to do this directly
when the grabbing conditions change, as opposed to the next event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3185>
Except for the tests that launches `mutter`, use a custom shell
implementation. It's roughly a copy of default.c with some cleanups on
top. A custom shell allows for a bit more freedom when doing testy
things.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3185>
This splits culling into two different phases to move unobscured region
culling to pre-paint to fix#2680. This is needed as direct scanout
skips the paint phase altogether, but the pre-paint phase always runs as
it's used for selecting the direct scanout surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3127>
With the ClutterEvent subtype structs sealed, this remains the only useful
struct type that is now usable on the Javascript side. Make all
ClutterActorClass event vmethods use ClutterEvent, and update all users
to this change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3163>
In test situations we sometimes do not create a libinput context, so
our check on dispose to see if we need closing the input thread is off
if META_SEAT_NATIVE_FLAG_NO_LIBINPUT was provided.
Check the input thread existing instead, since that is the thing we
want to undo here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Move the string construction bits in the event logging happening in
MetaSeatImpl to a clutter_event_describe() call, so that it has more
freedom in fiddling with ClutterEvent internals, and may be potentially
reused in other places.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Add methods, and change the API of some rarely used methods, in order
to make all event info currently held/necessary accessible through
ClutterEvent getters, instead of direct field access.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Since the full decomposed modifier state is unused, and only the
effective modifier mask matters to users, the new constructors take
just this effective modifier mask. This means this helper went
unused in the port to the new constructors, so can be now dropped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Since the full decomposed modifier state is unused, and only the
effective modifier mask matters to users, the new constructors take
just this effective modifier mask. This means this helper went
unused in the port to the new constructors, so can be now dropped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
This is done from the backend X11 connection, but needs directing at times
from the frontend X11 connection. Commit 5a8509f895 added a XEvent
argument presumably for possible future expansions that did never come.
Since this function is nothing about events, drop the XEvent argument and
make the name a little bit more ad-hoc (according to what it does, at
least).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Despite the attempt to make this a generic interface, this was
pretty much used only by the X11 backend, and now it ported away
from it.
This now stands unused and may be removed, in favor of backends
each creating and injecting events as they please.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
This is about the only reason now to go through the ClutterBackend
translate_event vmethod. We can do that directly, and stop requiring the
generic vmethod that is actually just used for X11 events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
There's no need for an XEvent filter, since this is already code close enough
to MetaBackendX11 XEvent handling and always required anyways. Make the a11y
configuration checks happen directly from MetaBackendX11 event handling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
We are pretty much guaranteed that the first event will be handled after
the cogl renderer has been set up. We can avoid the loop through
ClutterBackend vmethods and X11 event filters, and call this directly
from the code that is already close to the MetaClutterBackendX11.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Stop taking a ClutterEvent and pass the essentials here (x/y/evtime),
we don't have a ClutterEvent handy in all places that we call this
API, and it feels awkward to create one just for calling this vmethod.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
It is a bit backwards that events contain information about
the stage they are being handled by. It makes more sense to
specify in the ClutterEvent handling entrypoint the stage
that will handle the event.
As a first step, add this ClutterStage argument, even though
the information is still carried through the event in order to
keep satisfying calls to the getter function.
This entrypoint has been also renamed to clutter_stage_handle_event(),
so that its ownership/namespace is clearer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Nowadays, all our MapNotify event handling happens already prior to
the MetaCompositorX11 handling of XEvents. It does not make sense to
channel these events again through the backend, at best all it could
lead to is double handling of the same events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
These "features" are somewhat less featured, it's becoming too ugly
to handle all of them with a single API call. The clear outlier are
buttons, so move them to a separate function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3005>
queue_update() in a previous iteration was called in two situations:
* A page flip was already pending, meaning if we would commit an
update, it'd fail with EBUSY.
* A update was marked as "always-defer" meaning it should only be
processed from the deadline callback (would there be one). These were
used for cursor-only updates.
In the latter, we had to arm the deadline timer when queuing a new
update, if it wasn't armed already, while in the former, we would
currently idle, waiting for the page flip callback. At that callback
would the deadline timer be re-armed again.
Since we're only handling the former now, we'll never need to arm the
timer again, so remove code doing so. The code removed were never
actually executed anymore, after the "always-defer" flag on updates was
removed.
Fixes: 27ed069766 ("kms/impl-device: Add deadline based KMS commit scheduling")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2940
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3150>
Primary plane updates were forgetting to do this in OnscreenNative, but
rather than do it for each post there we should simply do it for each
post.
This fixes cursor stutter in the fallback path (not using deadline timers)
where needs_flush_crtcs would remain populated but CRTC_NEEDS_FLUSH would
never be emitted, because handle_flush hadn't been called for the last
post.
This is safe as the current use of scheduled flushing is only for cursor
updates, and since cursor updates happen on the same thread as processing,
and due to the fact that we always use the most up to date cursor position
when flushing, we never risk leaving an old cursor state unflushed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3138>
Implement importing of multi-plane formats. For now, only support
importing planes individually using "sub-formats". This is the most
commonly driver-supported approach in the moment, used by other
Wayland compositors as well.
In the future we will additionally want to support importing the formats
directly and let the drivers handle conversion internally.
Co-Authored-By: Robert Mader <robert.mader@collabora.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2191>
So they can be derived from the DRM format as well.
While updating the users, ensure we don't announce support for
DRM formats in zwp_linux_dmabuf_v1 if the MetaMultiTextureFormat is
INVALID. This will be used for YUV subformats in following commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2191>
To be able to later support more complex YUV formats, we need to make
sure that MetaShapedTexture (the one who will actually render the
texture) can use the MetaMultiTexture class.
Co-Authored-By: Robert Mader <robert.mader@collabora.com>
Co-Authored-By: Daniel van Vugt <daniel.van.vugt@canonical.com>
Co-Authored-By: Sebastian Wick <sebastian.wick@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2191>
In future commits, we want to be able to handle more complex textures,
such as video frames which are encoded in a YUV-pixel format and have
multiple planes (which each map to a separate texture).
To accomplish this, we introduce a new object `MetaMultiTexture`: this
object can deal with more complex formats by handling multiple
`CoglTexture`s.
It supports shaders for pixel format conversion from YUV to RGBA, as
well as blending. While custom bleding is currently only required for
YUV formats, we also implement it for RGB ones. This allows us to
simplify code in other places and will be needed in the future once
we want to support blending between different color spaces.
Co-Authored-By: Robert Mader <robert.mader@collabora.com>
Co-Authored-By: Sebastian Wick <sebastian.wick@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2191>
When we see a mode set, the cursor manager will update all the cursor
planes so they are set correctly as part of the mode set. KMS updates
are always per-device, and what was wrong was that it didn't filter out
CRTCs on devices that wasn't part of the mode set.
Reported-by: Michel Dänzer <mdaenzer@redhat.com>
Tested-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3130>
It returns non-0 if there are any hints in the WM_NORMAL_HINTS
property, 0 if there are none.
Fixes the mouse cursor changing to the resize shape over the decorations
of non-resizable windows.
Fixes: c7b3d8c607 ("frames: Push error traps around various X11 calls")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3096>
With libdecor, window moving/resizing only works with
the pointer, not with touch.
The meta_wayland_pointer_can_grab_surface checks for subsurfaces,
but the meta_wayland_touch_find_grab_sequence does not.
Add a similar subsurface check to
meta_wayland_touch_find_grab_sequence.
Closes: GNOME/mutter#2872
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3125>
Removing duplication, making it easier to add new formats and ensuring
that the native backend and Wayland clients can use the same formats.
Also improve related build files so the Wayland backend can be build
without the native backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
1. Move into the new 'common' folder and build for Wayland as well
so we will be able to share the code in follow-up commits.
2. Rename to cogl-drm-formats to make it more obvious that the format
map is more than an utility these days.
3. Drop the unused CoglTextureComponents part (see also previous
commit).
4. Move the map to the header, simplifying some future use-cases.
5. Sync formats with MetaWaylandBuffer and MetaWaylandDmaBufBuffer and
also use newly introduced opaque formats where appropriate.
This avoids duplicated code, ensures that new drm-formats added to
the dmabuf protocol have an adequate representation in Cogl from which
information like alpha support can be easily derived and finally
ensures we don't crash if the mappings got out of sync.
6. Remove some likely untested formats. In case some of these are
actually needed on certain hardware, we can test whether we got
the correct mapping by also adding support for the corresponding
wl_shm_format in MetaWaylandBuffer by extending the gradient test in
https://gitlab.freedesktop.org/jadahl/wayland-test-clients
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
The default cogl blend string is
`RGBA = ADD (SRC_COLOR, DST_COLOR*(1-SRC_COLOR[A]))` which is alpha
blending with premult fragment results. We do not clear the src
framebuffer and even if we did set alpha to 1 in the src fb, the
resulting alpha would be 1 and we want to check the alpha of the
fragment color.
Just turn off any kind of blending instead and write out the fragment
color to the fb.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
To obtain a float between 0 and 1 we have to devide the integer by the
highest possible value instead of the number of values.
Fixes off by one errors in the tests on some hardware/driver
combinations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
So we can properly handle matching DRM and WL_SHM formats in a unified
manner.
Add extensive testing between these and existing pre-multiplied alpha
formats, i.e. all formats we support on Wayland.
Note that unfortunately for some format combinations the value in the
alpha channel is not cleared as expected, likely because of fast-paths
in Cogl. If both source and destination format is opaque, it always
works, however. This thereby includes all cases where they are the same.
Co-Authored-By: Jonas Ådahl <jadahl@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
We can schedule an update from the cursor manager, but that doesn't mean
there will be an actual plane assignment changed at the time of the
update processing, since for example we might have "touched" a CRTC, but
already left it before the processing started, meaning we have nothing
to change after all.
Add a test case that checks that this works properly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This removes the old hardware cursor management code and outsources it
to MetaKmsCursorManager. What the native cursor renderer still does,
however, is the preprocessing i.e. rotating/scaling cursor that wouldn't
otherwise be fit for a cursor plane.
The cursor DRM buffers are instead of being per cursor sprite now per
CRTC, meaning we don't need to stop doing hardware cursors if part of
the cursor is on an output that doesn't support it. This is why the
whole scale/transform code changed from being per GPU to per CRTC.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
It can be quite slow to set up the test environment inside the VM, as
well as outside, leaving very little time for the test itself. While
it'd be nice to not run the mock env etc outside the VM, let's just bump
the timeout for now, to avoid unnecessary timeout failures.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
If we turn of a CRTC, we might have invalidated the cursor manager for
the same CRTC, but that should not mean a cursor plane is assigned when
turning off the CRTC.
Add a test case for this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This new manager object intends to take over management of the cursor
plane from the native cursor renderer. It's API is intended to be used
from the main thread, except for the _in_input() function, but mainly
operates in the KMS context, i.e. the KMS thread.
It makes use of an "update filter" that is called before each
MetaKmsUpdate is turned into a atomic KMS commit or a set of legacy
drmMode*() API calls. When the cursor position has been invalidated,
it'll assign the cursor plane in the filter callback, using an as up to
date as possible pointer position as the source for the cursor plane
position.
Cursor updates from the input thread schedules updates for the affected
CRTCs which will cause the filter to be run, potentially for cursor-only
commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This adds some plumbing to get the "default" paint flags for regular
stage painting, where one either wants to paint the overlay, or not.
If inhibited, the 'no-cursors' paint flag is used, otherwise the 'none'
flag. This will be used to allow having a per stage view hw cursor
state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This makes it possible to post KMS updates that will always defer until
just before the scanout deadline. This is useful to allow queuing cursor
updates where we don't want to post them to KMS immediately, but rather
wait until as late as possible to get lower latency.
We cannot delay primary plane compositions however, and this is due to
how the kernel may prioritize GPU work - not until a pipeline gets
attached to a atomic commit will it in some drivers get bumped to high
priority. This means we still need to post any update that depends on
OpenGL pipelines as soon as possible.
To avoid working on compositing, then getting stomped on the feet by the
deadline scheduler, the deadline timer is disarmed whenever there is a
frame currently being painted. This will still allow new cursor updates
to arrive during composition, but will delay the actual KMS commit until
the primary plane update has been posted.
Still, even for cursor-only we still need higher than default timing
capabilities, thus the deadline scheduler depends on the KMS thread
getting real-time scheduling priority. When the thread isn't realtime
scheduled, the KMS thread instead asks the main thread to "flush" the
commit as part of the regular frame update. A flushing update means one
that isn't set to always defer and has a latching CRTC.
The verbose KMS debug logging makes the processing take too long, making
us more likely to miss the deadline. Avoid this by increasing the
evasion length when debug logging is enabled. Not the best, but better
than changing the behavior completely.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
