Create a fake monitor region right of the right-most monitor and if a
horizontal barrier extends into that region, fail the barrier. Barriers
are aligned on the top/left edge of the pixel so the most natural
barrier of (e.g. 0-1024) is also wrong - it's one pixel into the next
monitor.
Check this for nonexisting screens on the right too to avoid clients
suddenly failing when multiple monitors are present.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3319>
Assuming two 1920x1080 screens next to each other: a horizontal barrier
starting at 1920 going east is always outside the left screen.
Assuming two 1920x1080 screens on top of each other: a vertical barrier
starting at 1080 going south is always outside the top screen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3319>
When running headless, only the invalid modifiers are advertised.
That breaks with the NVIDIA proprietary driver which then rejects the
buffers created with the invalid modifier, and that kills Xwayland,
meaning that running Xwayland on top of a mutter based compositor
headless is not possible.
The reason the modifiers are not sent is because AddFb2 is not supported
when running headless.
Other compositors (weston, wlroots) would still send the modifiers even
without AddFb2, and Xwayland works fine on those compositors when
running headless.
Remove the requirement for AddFb2 to send the modifiers, so that
Xwayland can work fine on top of mutter headless with the NVIDIA
proprietary driver.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3060
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3320>
`clutter_actor_destroy()` queues a stage update. Under certain
circumstances - i.e. when run in a very slow container - this can race
with the stage update triggered by the following
`clutter_virtual_input_device_notify_button()`, occasionally resulting in
`wait_stage_updated()` to return before the
`on_event_return_propagate()` callbacks ran, making the test fail.
This notably became more common since
8f27ebf87e (clutter/frame-clock: Start next update ASAP after idle period)
landed.
Thus wait for a stage update to happen after `clutter_actor_destroy()`,
preventing the race.
Fixes: f6da583d06 (tests/clutter/event-delivery: Add tests for implicit grabbing)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3332>
Instead of g_get_monotonic_time. This makes sure last_presentation_time_us
advances by refresh_interval_us.
Doesn't affect test results at this point, but it will with the next
commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3174>
Certain kernel drivers can take an unreasonably long time to
complete mode setting operations. That excessive CPU time is charged
to the process's rlimits which can lead to the process getting killed
if the thread is a real-time thread.
This commit inhibits real-time scheduling around mode setting
commits, since those commits are the ones currently presenting as
excessively slow.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3037
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3324>
At the moment if a thread is made real-time there's no going back,
it stays real-time for the duration of its life.
That's suboptimal because real-time threads are expected by RTKit to
have an rlimit on their CPU time and certain GPU drivers in the kernel
can exceed that CPU time during certain operations like DPMS off.
This commit adds two new ref counted functions:
meta_thread_{un,}inhibit_realtime_in_impl
that allow turning a thread real-time or normally scheduled. At the same
time, this commit stores the RTKit proxy as private data on the thread
so that it can be reused by the above apis.
A subsequent commit will use the new APIs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3324>
Most of the code writes "real-time" as "realtime" not "real_time".
The only exception is one function `request_real_time_scheduling`.
This commit changes that function for consistency.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3324>
If we queued a mode set, but didn't end up compositing all frames, we'll
have pending mode sets in a hash table waiting to be applied. If we
before all monitors again try to reconfigure things we should drop the
old pending mode sets and start fresh.
We already do this when we're doing so when generating views, but when
just unsetting modes, we didn't, so fix that.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2242612
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3318>
We had a function called "reset_modes()" on MetaRendererNative, but what
it expected to do was to unset all modes on all CRTCs. Despite this, it
had code to unset modes on unconfigured CRTCs, probably because it was
used for multiple things in the past.
Make this a bit easier to follow by renaming the function
"unset_modes()" and fold the function doing the unsetting into the
function itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3318>
Intel has started to advertise big gamma LUT sizes on some hardware
because the hardware supports segmented LUTs. This means they have a lot
more precision at certain segments then others. The uAPI can't expose
this functionality meaningfully so they chose to expose a huge number of
TAPs to sample from to their segmented LUT.
This increase in uAPI LUT size resulted in stack overflows because we
allocated the LUT on the stack. This commit moves it to the heap
instead.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3064
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3322>
1. Centralize stride calculation in one function.
2. For dmabufs query the stride instead of assuming a certain value.
3. For system memory buffers use the pixel format to calculate the
stride.
4. Stop negotiating `SPA_PARAM_BUFFERS_size` and
`SPA_PARAM_BUFFERS_stride`.
2. fixes an actual bug where we reported wrong max buffer sizes,
resulting in crashes in Gstreamer when doing area screencasts on AMD
GPUs.
The reasoning for 4. is that the values were possibly wrong for
dmabufs as the negotiation happens before we create any buffers.
Further more neither Mutter nor the common consumers required it.
The later either ignore the values (OBS), always accept (gstpipewiresrc)
them or calculate the exact same possibly wrong values (libwebrtc).
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6747
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3311>
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>
This is helpful when we add callbacks that should be dispatched in the
KMS impl thread.
This invalidates an assumption about callbacks not being in the impl
context, so some asserts for that are also removed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This signal is emitted before terminating the thread, but also when
resetting the thread type. This is to allow thread implementations to
make sure they have no stale pending callbacks to any old main contexts.
This commit "terminates" the impl thread even if there is no actual
thread; this is to trigger the "reset" signal, also when switching from
a user thread to a kernel thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This means we can add COGL_TRACE*() instrumentation that is grouped
correctly in sysprof. If kernel threading is enabled, they will end up
in a "Compositor (KMS thread)" group (ignoring translations).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
Real time scheduling is needed for better control of when we commit
updates to the kernel, so add a property to MetaThread that, if the
thread implementation uses a kernel thread and not a user thread, RTKit
is asked to make the thread real time scheduled using the maximum
priority allowed.
Currently RTKit doesn't support the GetAll() D-Bus properties method, so
some fall back code is added, as GDBusProxy depends on GetAll() working
to make the cached properties up to date. Once
https://github.com/heftig/rtkit/pull/30 lands and becomes widely
available in distributions, the work around can be dropped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
Also add an API to inhibit the kernel thread from being used, and make
MetaRenderDeviceEglStream inhibit the kernel thread from being used if
it's active.
The reason for this is that the MetaRenderDeviceEGlStream is used when
using EGLStreams instead of KMS for page flipping. This means the actual
page flipping happens as a side effect of using EGL/OpenGL, which can't
easily be done off thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This will be necessary in order to default to 'kernel' and then switch
to 'user' if the thread instance can no longer be properly multi
threaded.
To avoid having the same thread impl creating and destroying
GMainContext's, this also means always creating a GMainContext for the
thread-impl. When running in user-thread mode, the GMainContext is
wrapped in a wrapper source and dispatched as part of the real main
thread GMainContext, and when in kernel-thread mode, it runs
independently in the dedicated thread.
This has the consequence that the wrapper source will always have the
priority of the highest impl context GSource, but only after it has
dispatched once. Would we need it earlier than that, we either need a
way to introspect existing sources in a GMainContext and their
priorities, or manually track known sources in MetaThreadImpl.
The wrapper source will never be below 0, as that'd mean it could reach
INT_MAX priority if it had no more sources attached to it, meaning it'd
never be dispatched again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
While doing this, rename the old synchronous functions to more clearly
communicate that they expect to actually process the update during the
call, not just post it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
While the default when passing NULL will be the main context of the main
thread, make it possible to specify another main context, so that
result handlers can be invoked on the right thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
Callbacks could be queued to be invoked either on the impl side or the
main thread side of the thread; change this to take a GMainContext,
which effectively means a callback can be queued to be invoked on any
thread that has a GMainLoop running on its own GMainContext.
Flushing is made to handle flushing callbacks synchronously on all
threads. This works by keeping a hash table of queued callbacks per
thread (GMainContext); when flushing (from the main thread), callbacks
on the main thread context is flushed, followed by synchronization with
all the other threads.
meta_thread_flush_callbacks() is changed to no longer return the number
of dispatched callbacks; it becomes much harder when there are N queues
spread across multiple threads. Since it wasn't used for anything, just
drop the counting, making life slightly easier.
Feedback to thread tasks are however always queued on the callers
thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This means each test is run 4 times:
* with atomic mode setting using a kernel thread,
* with atomic mode setting using a user thread,
* with legacy mode setting using a kernel thread, and
* with legacy mode setting using a user thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This isn't a problem for user space threads, as there are no race
conditions, but when kernel thread support is introduced, we must make
sure that e.g. the main loop is actually running before quitting it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This uses the queue that was introduced when migrating impl task
management from MetaThread to MetaThreadImpl, with the exception that
it's now fully used as an actual queue. It now has a GSource that sits
on the right GMainContext that is dispatched whenever there are tasks to
execute.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
It's the impl side that wants to add impl side idle sources, or fd
sources, etc, so make it part of MetaThreadImpl.
This changes things to be GAsyncQueue based. While things are still
technically single threaded, the GAsyncQueue type is used as later we'll
introduce queuing tasks asynchronously, then eventually queuing across
thread barriers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
It currently does exactly what MetaKms and MetaKmsImpl did regarding the
context separation, which is to isolate what may eventually run on a KMS
thread into a separate unit. It works somewhat like a "user thread",
i.e. not a real thread, but will eventually learn how to spawn a
"kernel thread", but provide the same API from the outside.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
Remote desktop version 2 added a new method ConnectToEIS .
ConnectToEIS allows clients to requests a file descriptor from the
compositor which can then be used directly from libei.
Once established, the communication between compositor and application
is direct, without the need to go through the portal process(es).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
Accessibility should be handled on the receiving end, if needed. Make
sure this is the case by listening on some signals, verifying they are
only triggered if we're not capturing input.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
This adds the actual input capturing rerouting that takes events and
first hands them to the input capture session, would it be active.
Events are right now not actually processed in any way, but will
eventually be passed to a libei client using libeis.
A key binding for allowing cancelling the capture session is added
(defaults to <Super><Shift>Escape) to avoid getting stuck in case the client
doesn't even terminate the session.
The added test case makes sure that the pointer moves again after
pressing the keybinding.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
When a relative pointer motion gets constrained (e.g. a monitor edge or
barrier), save the constrained relative motion delta too.
This will later be used to send the remaining motion delta to input
capture clients.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
An input only grab is a ClutterGrab on the stage that doesn't have an
explicit actor associated with it. This is useful for cases where event
should be captured as if focus was stolen to some mysterious place that
doesn't have anything in the scene graph that represents it.
Internally, it's implemented using a 0x0 sized actor attached directly
to the stage, and a clutter action that consumes the events. An
input-only grab takes a handler, user data and a destroy function for
the user data. These are handed to the ClutterAction, which handles the
actual event handling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
Adding a barrier and later enabling the input capture session will
create MetaBarrier instances for each added input capture barrier.
The barriers are created as "sticky" which means that when a pointer
hits the barrier, it'll stick to the point of entry, until it's
released.
The input capture session is also turned into a state machine with
explicit state, to more easily track things.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
This allows for a sticky barrier to hold the pointer until it is
released, but the owner of the barrier doesn't need a barrier event to
release it. It will be used to implement input capturing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
A sticky barrier means that a pointer in motion intersecting a barrier
doesn't move once having hit it. The intention with this is to allow an
input capture clients to continue a motion once a barrier is hit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
This API aims to provide a way for users to capture input devices under
certain conditions, for example when a pointer crosses a specified
barrier.
So far only part of the API is implemented, specifially the session
management as well as zone advertisement, where a zone refers to a
region in the compositor which edges will eventually be made available
for barrier placement.
So far the remote access handle is created while the session is enable,
despite the input capturing isn't actually active yet. This will change
in the future once it can actually become active.
v2: Remove absolute/relative pointer, keep only pointer (ofourdan)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
This was a temporary fix until there was a better crossing event
delivery mechanism that accounted for actor changes beneath the pointer.
We nowadays have that, and don't seem to need this extra kick to get
crossing events triggered (and cursor changes, etc) when windows appear
or disappear under the pointer.
This commit is effectively a revert of commit
a64dba4d7a.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6808
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3104>
With window_is_terminal gone, "strict" and "smart" focus mode have no
behavioural difference. Let's broaden the scope of strict focus mode,
such that windows never automatically focus unless they are an ancestor
to the transient.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3063>
As noted in the comments of window_is_terminal, this is a hack. This
code has not been touched for the better part of a decade. App res_class
tends to differ between Wayland and X11, so it is likely that none of
these apps have been recognised as terminals under Wayland ever. Also,
there are reports that strict focus mode also does not work under X11,
likely due to changes in these terminal apps over the years resulting
in different res_class than those manually specified in here. Let's remove
this hack and change strict focus mode accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3063>
Instead of using `clutter_actor_get_resource_scale()`, we now deduce the
intended buffer scale from the window by dividing the unscaled size by
the final actor size. This is more correct as while the return value of
`clutter_actor_get_resource_scale()` depends only on the monitor where
the surface resides, the actual scale of the surface is determined
solely by the application itself. `get_resource_scale` will differ from
the actual buffer scale if the application only supports 100% scaling
(Xwayland), or is performing scaling with wp_viewporter (clients using
fractional_scale_v1).
This also fixes a mismatch between the calculated buffer sizes between
`meta_window_actor_get_buffer_bounds` and
`meta_window_actor_blit_to_framebuffer` which causes broken
screencasting for Chromium 114 and later when using the native Ozone
Wayland backend.
Additionally, this commit also changes
`meta_window_actor_blit_to_framebuffer` from using a simple translation
to using an inverted matrix transformation of the transformation matrix
between the parent of the window actor and the surface actor to ensure
maximum sharpness for fractionally scaled windows.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3053>
Previously, restarting mutter in an X11 session resulted in
the previously set color temperature not being applied.
Fix that by applying the color temperature right after
the org.gnome.SettingsDaemon.Color proxy has been created.
Furthermore, only call `update_all_gamma()` from `on_gsd_color_ready()`
when the temperature has actually changed. Otherwise there is no need
since the current temperature has already been (or will soon be) applied
to all ready color devices.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3008>
We'd get a re-entry like scenario when destroying the PipeWire stream
object, where PipeWire would call the stream process vfunc. When this
happened, we had already destroyed the stream, so don't try to dequeue
or anything, just do an early exit. Fixes the following crash in the
test case client:
#0 pw_stream_dequeue_buffer() in /usr/lib64/libpipewire-0.3.so.0.367.0
#1 on_stream_process() at ../src/tests/screen-cast-client.c:348
#2 do_call_process() in /usr/lib64/libpipewire-0.3.so.0.367.0
#3 flush_items() in /usr/lib64/spa-0.2/support/libspa-support.so
#4 loop_invoke() in /usr/lib64/spa-0.2/support/libspa-support.so
#5 impl_send_command.lto_priv.0() in /usr/lib64/libpipewire-0.3.so.0.367.0
#6 suspend_node.lto_priv.0() in /usr/lib64/libpipewire-0.3.so.0.367.0
#7 pw_impl_node_set_state() in /usr/lib64/libpipewire-0.3.so.0.367.0
#8 client_node_removed() in /usr/lib64/pipewire-0.3/libpipewire-module-client-node.so
#9 pw_proxy_destroy() in /usr/lib64/libpipewire-0.3.so.0.367.0
#10 pw_stream_disconnect() in /usr/lib64/libpipewire-0.3.so.0.367.0
#11 pw_stream_destroy() in /usr/lib64/libpipewire-0.3.so.0.367.0
#12 stream_free() at ../src/tests/screen-cast-client.c:530
#13 main() at ../src/tests/screen-cast-client.c:803
#14 __libc_start_call_main() at ../sysdeps/nptl/libc_start_call_main.h:58
#15 __libc_start_main() at ../csu/libc-start.c:360
#16 _start() in /home/jonas/Dev/gnome/mutter/build/src/tests/mutter-screen-cast-client
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3095>
If the timelines don't get destroyed they keep references to frame
clocks. Later tests check for the destruction of those frame clocks and
then can fail if the frame clock is implemented slightly differenty.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3084>
In remote desktop sessions, streams can be created and destroyed
on-the-fly.
If a stream is gone, it is not necessarily an error.
So, don't treat that situation like an erroneous one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2911>
The previous logic didn't work correctly at least when priority-based
preeption wasn't supported by the DRM driver, such as in the case
of amdgpu. The call to glGetQueryObjecti64v would block on client
work which is already in progress (most likely for the next frame)
and delay notifying the ClutterFrameClock about presentation.
Conveniently, the Wayland transactions mechanism guarantees that all
fences of a dma-buf buffer are signalled before the buffer is
included in a frame, which means that dma-buf buffers are ready for
presentation when being directly scanned-out.
Direct scanout is only supported for dma-buf buffers too, which means
that all buffers going through direct scanout are effectively ready
and require no GPU rendering before presentation.
Assuming zero rendering time for dma-buf buffers going through direct
scanout simplifies the code and removes the need for
glGetQueryObjecti64v, thus avoiding the aforementioned issue where it
could block for longer than expected.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2766
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3080>
Depending on the ordering of the surface-associated resources
being destroyed, we may fall into the following situation:
- wl_surface is destroyed
- destruction notifications for the surface runs
- The MetaWaylandKeyboard attempts to synchronize the window
focus
- The MetaWindow is not destroyed yet, so the focused window
remains the same, and the MetaWaylandKeyboard keeps the same
focus MetaWaylandSurface.
- wl_surface finalizes destruction, MetaWaylandSurface now has
a NULL resource
- xdg_toplevel destructor kicks in, it unmanages the window
- The current focus window is again looked up, forced to look
a different window
- The MetaWaylandKeyboard focus now changes, tries to leave the
old surface, but it has a NULL resource already, and raises
a protocol error.
If the order is inverted, the window being unmanaged triggers a
focus change into a different window, the MetaWaylandKeyboard
triggers a focus change while the MetaWaylandSurface is still
intact, it succeeds, and the window gets properly destroyed.
In order to make this independent of the order, it makes sense
to make MetaWaylandKeyboard do like the other objects tracking
focus surfaces, and have it care of its own little parcel. The
surface destructor changed to simply unsetting the keyboard focus
to NULL (guaranteeing that the old focus is left while the surface
resource is still up), and leaving potential focus changes to
the xdg_toplevel_destructor->unmanage->update_focus paths.
Doing that alone is basically a revert of commit 228d681b, thus
is still subject to keyboard focus being lost after a popup is
destroyed. Change the approach to trigger the focus sync (and
new focus surface lookup) so it happens from xdg_popup_destructor
specifically to popups and alike xdg_toplevel.
Fixes: 228d681b ("wayland: Trigger full focus sync after keyboard focus surface is destroyed")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2853
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3077>
Current behavior pushes a window which receives focus to the start of
the MRU list on every workspace it is on. By focusing a sticky window
the default focus on all other workspaces changes as well. This is fine
for sticky windows explicitly marked as sticky by the user but if a
window is on a secondary output and workspaces are only on the primary
output the behavior is unexpected. Instead we want the window to be the
default focus only on the current workspace but also keep those windows
in a relative MRU order to each other on all workspaces.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2681
Fixes: 058981dc1 ("workspace: Focus the default window only if no window is focused")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2909>
This avoids use-after-free when handle_start() is called following
handle_stop() during the lifetime of the MetaProfiler. This happens
on repeated profiling sessions using Sysprof.
Fixes: e16d68372 ("profiler: Add API to register profiler threads")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3076>
We need to juggle with some things here to keep key event ordering
and accounting consistent.
The keyboard internal state changes (and maybe modifier event emission)
happening through meta_wayland_seat_update() should ideally happen
from the same key events that reach the client through wl_keyboard.key,
so that wl_keyboard.modifier events are emitted in the right relative
order to other key events.
In order to fix this, we need to decide at an earlier point whether
the event will get processed through IM (and maybe be reinjected),
thus ignored in wait of IM-postprocessed events.
This means we pay less attention to whether events are first-hand
hardware events for some things and go with the event that does
eventually reach to us (hardware or IM).
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5890
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3044>
Given the presence of IMs and the different paths in event handling to reach
one of them, we cannot make guesses about whether should stick to the original
hardware-triggered event, or wait/prefer a second hand IM event that might or
might not arrive. We also have no say for other IM foci unrelated to wayland
(e.g. ClutterText) triggering the double event emission.
So go with it and maintain our own internal state for keys, we already kinda
do, but mainly for warning purposes, at the time of updating the
MetaWaylandKeyboard state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3044>
Currently, we let the same function handle key event filtering as they
are passed to the IM, and the IM events resulting in actions like text
commit or preedit changes.
Split these two aspects into filter/process functions, and port
ClutterText to it. MetaWaylandTextInput still handles everything in
a single place, but that will be split in later commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3044>
This means initializing the pointer position in MetaSeatImpl
synchronously too, otherwise it's not guaranteed querying the seat state
will result in the expected position.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3071>
I have a monitor which can report two preferred modes: 5120x1440@240
and 3840x1080@60. Since they are enumerated in this order by KMS,
init_output_modes would end up using 3840x1080@60 (and it was impossible
to select any 5120x1440 mode in the GNOME display settings).
Fix this by using meta_kms_connector_get_preferred_mode, which returns
the first KMS mode with DRM_MODE_TYPE_PREFERRED.
v2:
* Use meta_kms_connector_get_preferred_mode. (Jonas Ådahl)
Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3055>
This will consist of device-added events, meaning before init finishes,
we can derive some state that depends on the set of input devices
available on startup, such as cursor visibility.
This avoids cursor visibility switching between hidden and visibility
during startup.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3070>
This opens up for a possibility to handle initial events (devices
discovered on startup) during initialization, meaning we can figure out
a more correct initial state that depends on available input devices.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3070>
This is different from "warping" as it doesn't necessarily result in a
pointer motion event. This can be helpful during initializing so we can
avoid faked pointer events that would otherwise need to be special cased
to not appear as actual pointer movements.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3070>
The stage already maintains its own list of stage-views via
clutter_stage_peek_stage_views(), it's a bit superfluous to copy that list
around all the time into priv->stage_views of ClutterActor. Let's deal with
that by returning clutter_stage_peek_stage_views() when
clutter_actor_peek_stage_views() gets called for the stage.
In order to make sure ClutterActor::stage-views-changed still gets emitted
correctly for the stage, always emit that signal on the ClutterStage when
the stage views get invalidated. This now depends on the backend only
actually invalidating the views and calling
clutter_stage_clear_stage_views() when things have actually changed, but
that should be the case.
This needs a change in one of the stage-views tests, namely the one which
tests stage-view-changed emission on the stage: Here we now see an emission
of stage-views-changed, but that signal emission actually seems correct.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
There were two issues with using the shape region to derive an input
region.
Firstly, the shape region is against the client rectangle, while the
surface actor needs it to be against the buffer rectangle. Fix this by
offsetting the shape region before passing it along.
Secondly, we can't just intersect the shape and input region, since that
leaves out the window decorations. Fix this by only intersecting the
input region covering the client part, and the shape region, and then
union that with the input region covering the rest.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3045>
Don't try to handle things by threads enabling/disabling the main trace
context on-demand, just have a clear start/stop API. For the D-Bus API,
it becomes more straight forward, and for the persistent variant too, as
it avoids having to pass garbage input when it's known that arguments
will be discarded.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2998>
Persistent profiling was started via an env var, but that's rather hard
to discover and remember without grepping; change to use a command line
argument.
The profiler is started early, even during (though late in)
configuration, but configuration should ideally be instant and pointless
to configure.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2998>
Under X11 hiding the backend implies also unmapping the stage window, if
we do that after that we've closed the display we may end up in a
BadWindow error because such window seems to be destroyed together with
the compositor output parent (even though we are not notified about), so
to prevent this, reparent the backend window during compositor unmanage,
setting it back as a root window child.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2835
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3020>
We currently lock the capability of the MetaOrientationManager to emit
the ::orientation-changed signal, but otherwise keep reading the current
orientation and returning it if we are asked politely through
meta_orientation_manager_get_orientation().
This may bring issues e.g. around suspend/resume, since there may be other
parts of the code trying to get the current orientation without receiving
::orientation-changed signals, this may result in the display orientation
being effectively rotated, then stay locked after that.
In order to fix this, make the MetaOrientationManager return a fixed
orientation while locked, only updated after changes in the lock state.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2600
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3021>
This is missed, leaving the cursor renderer disconnected from the stage
updates that could trigger further frame callbacks on the cursor, leaving
some clients like Xwayland stuck with cursors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3025>
We do in fact allow these combinations of configuration since the Settings
Wacom panel revamp. We no longer need to look up Wacom device features,
since this is allowed for all the devices that have these settings.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3012>
We avoided setting the device matrix applying to the tablet tool (used if the
tablet is in absolute coordinates mode) if the device is configured for relative
motion, but forgot to apply the matrix if changing the device back to absolute
mode, this made the device seemingly forget its attached display until later
configuration changes.
In order to avoid the hassle of looking up the right display again on unrelated
configuration changes, make the matrix be always set on the device, but only
actually used in absolute coordinates mode. This makes the device able to
seamlessly switch between modes and remain mapped to the right display.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3012>
