Add API to let GNOME Shell have the ability to get notified about remote
access sessions (remote desktop, remote control and screen cast), and
with a way to close them.
This is done by adding an abstraction above the remote desktop and
screen cast session objects, to avoid exposing their objects to outside
of mutter. Doing that would result in external parts holding references
to the objects, complicating their lifetimes. By using separate wrapper
objects, we avoid this issue all together.
Sending button events to a ClutterVirtualInputDevice, the API expects
button codes to be of the internal clutter type. The evdev
implementation incorrectly assumed it was already prepared evdev event
codes, which was not the case. Fix the evdev implementation to translate
from the internal representation to evdev before passing it along to
ClutterSeatEvdev.
The "backends: Move MetaOutput::crtc field into private struct"
accidentally changed the view transform calculation code to assume that
"MetaCrtc::transform" corresponds to the transform of the CRTC; so is
not the case yet; one must calculate the transform from the logical
monitor, and check whether it is supported by the CRTC using
meta_monitor_manager_is_transform_handled(). This commit restores the
old behaviour that doesn't use MetaCrtc::transform when calculating the
view transform.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/216
GNOME Shell relies on the MetaScreen::startup-sequence-changed signal,
which is tied to (lib)startup-notification and therefore X11. As a result,
when we remove the startup sequence of a wayland client, GNOME Shell will
not be notified about this until startup-notification's timeout is hit.
As a temporary stop-gap, go through XWayland even for wayland clients,
so that the signal is emitted when expected.
https://bugzilla.gnome.org/show_bug.cgi?id=768531
For some reason "backends: Remove X11 idle-monitor backend" removed
unrelated warning messages for when generated monitor configurations
that should work didn't, which also made the unit tests fail.
This commit adds them back, which also makes the tests pass again.
(cherry picked from commit d9c18fd5bb)
The framerate for screen cast sources was set to variable within 1 FPS
and the framerate of the monitor being screen casted. This meant that if
the sink didn't match the framerate (e.g. had a lower max framerate),
the formats would not match and a stream would not be established.
Allow letting the sink clamp the framerate range by setting it as
'unset', allowing it to be negotiated.
xdg-foreign clears the `transient_for` of a modal dialog when its
imported parent is destroyed, which would later cause a crash in
`constrain_modal_dialog()` because the transient `NULL`.
So in case a modal dialog has no parent, do not try to constrain it
against its parent.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/174
(cherry picked from commit 912a6f5e3f)
Make it so that each logical monitor has a reference to all the
monitors that are assigned to it.
All monitors has a reference to each output that belongs to it.
Each output has a reference to any CRTC it has been assigned.
https://bugzilla.gnome.org/show_bug.cgi?id=786929
(cherry picked from commit 768ec15ea0)
Treat the main seat as other seats, so we don't have to handle it differently
in specific places. This was already the case before when a real device
was plugged before the startup, but not applied when hotplugging a device.
(cherry picked from commit 15f41c9f68)
When no input devices are available on startup the device manager might be fast
enough to be constructed so that no default stage is set yet, and thus when
main seat virtual devices are created they won't have a proper stage set.
If then we plug a real device, the events that an input manager could generate
won't be associated to any stage and thus won't be processed.
We need then ensure that when we update the stage for the device manager we
(un)associate it also to the main seat devices.
(cherry picked from commit d7bdc1591f)
In devices such as ARM boards there could be no input devices connected on
startup, leading to a crash when we try to process artificial events that
could be queued (as gnome-shell does when syncing pointer).
Those events still should refer to a device and, in case we don't have one
provided by libinput we should still return the core devices defined in the
main seat.
(cherry picked from commit 3e85ac8131)
Commit 47131b1d ("frames: Handle touch events") introduced an assert to
make sure that all mouse button actions are handled in mutter.
However, mice can have a more than 5 buttons, so simply ignore the
"other" actions instead of aborting.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/160
(cherry picked from commit 473bf38753)
Compositor effects change the actor size and position, which can lead to
inconsistent output enter/leave notifications, leaving clients' surfaces
without any output set.
Update output enter/leave notifications after all compositor effects are
completed so that we give clients accurate output location.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/104
(cherry picked from commit 17a745bf81)
When using plugins, the effects will affect the MetaWindowActor size
and position.
Add a new signal "effects-completed" wired to the corresponding
MetaWindowActor which is emitted when all effects are completed so that
derived objects can be notified when all effects are completed and use
the actual size and position.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/104
(cherry picked from commit 85bbd82ae8)
After 20176d03, the Wayland backend only synchronizes with the
compositor after a geometry was set, and it was different from
the current geometry.
That commit was mistakenly comparing the geometry before chaining
up, which would yield a false negative on the case where the
client didn't call set_geometry() before commit().
Fix that by caching the old geometry locally, chain up (and thus
apply the new geometry rectangle), then comparing the old and
current geometry rectangles.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/150
(cherry picked from commit cf734999fb)
This is just done on wayland as it'll break horribly on X11, we let
this happen through pointer emulated events in XISelectEvents evmask
instead.
Some things had to be made slightly more generic to accomodate touch
events. The MetaFrames shall lock onto a single touch at a time, we
don't allow crazy stuff like multi-window drag nor multi-edge resizes.
https://bugzilla.gnome.org/show_bug.cgi?id=770185
Mark CAPS lock as a modifier (as it should) so that when using XKB
options to change the default behaviour of CAPS lock, the new assigned
key can by used as a sticky key as well.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/112
(cherry picked from commit 6df2b7af55)
Input method can inject key events, which leads to multiple reported key
press/release events for a single user action.
Ignore those events as this confuses keyboard accessibility.
(cherry picked from commit c01b099dbd)
When using two monitors size by side with different scales, once the
cursor moves from one output to another one, its size changes based on
the scale of the given output.
Changing the size of the cursor can cause the cursor area to change
output again if the hotspot is not exactly at the top left corner of the
area, causing the texture of the cursor to change, which will trigger
another output change, so on and so forth causing continuous surface
enter/leave event which flood the clients and eventually kill them.
Change the logic to use only the actual cursor position to determine if
its on the given logical monitor, so that it remains immune to scale
changes induced by output scale differences.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/83
(cherry picked from commit 67917db45f)
While MetaStage, MetaWindowGroup and MetaDBusDisplayConfigSkeleton don't
appear explicitly in the public API, their gtypes are still exposed via
meta_get_stage_for_screen(), meta_get_*window_group_for_screen() and
MetaMonitorManager's parent type. Newer versions of gjs will warn about
undefined properties if it encounters a gtype without introspection
information, so expose those types to shut up the warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
Various code assumed PipeWire function calls would never fail. Some can
actually fail for real reasons, and some currently can only fail due to
OOM situations, but we should still not assume that will always be the
case.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/102
(cherry picked from commit 0f9c6aef99)
The destroyed signal that was emitted if an imported surface was not
available when created, for example if the handle was invalid or
already unexported, was emitted on the wrong resource.
(cherry picked from commit 98d7024288)
We require logind for the native backend, but the backend itself is
optional. However since commit 06c357d78, we will always throw an
error if neither logind nor elogind are available, even when the
backend is disabled.
As we still support "auto" - that is, whether the native backend is
enabled depends on whether its dependencies are available - the
easiest option is to make sure we always include either elogind or
libsystemd in the dependency check rather than erring out explicitly
if neither is found.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/96
(cherry picked from commit 82564772dc)
The current implementation of the XdgSurface v6 protocol does not check
if the window changed before calling meta_window_wayland_move_resize().
The problem with this approach is that calling this function is a costly
operation since we enter the compositor side. In GNOME Shell case, it is
in JavaScript, which triggers a GJS trampoline. Calling this function on
every mouse movement is naturally as terrible as it could be - and is
exactly what happens now.
This commit adds the necessary checks to only call move_resize() when
the window actually changed, or when it needs to be updated.
https://bugzilla.gnome.org/show_bug.cgi?id=780292
Issue: #78
This will be used by the next commit to determine when a window
geometry change should be ignored or not. Normally, it would be
enough to just check if the position and sizes changed.
The position, in this case, is relative to the client buffer, not
the global position. But because it is not global, there is one,
admitedly unlikely, situation where the window state is updated
while the client size and relative positions don't change.
One can trigger this by e.g. tiling the window to the half-left of
the monitor, then immediately tile it to half-right. In this case,
the window didn't change, just it's state, but nonetheless we need
to notify the compositor and run the full move/resize routines.
When that case happens, though, the MetaWindowWayland is tracking
the pending state change or a move. And this is what we need to
expose.
https://bugzilla.gnome.org/show_bug.cgi?id=780292
Issue: #78
In the old, synchronous X.org world, we could assume that
a state change always meant a synchronizing the window
geometry right after. After firing an operation that
would change the window state, such as maximizing or
tiling the window,
With Wayland, however, this is not valid anymore, since
Wayland is asynchronous. In this scenario, we call
meta_window_move_resize_internal() twice: when the user
executes an state-changing operation, and when the server
ACKs this operation. This breaks the previous assumptions,
and as a consequence, it breaks the GNOME Shell animations
in Wayland.
The solution is giving the MetaWindow control over the time
when the window geometry is synchronized with the compositor.
That is done by introducing a new result flag. Wayland asks
for a compositor sync after receiving an ACK from the server,
while X11 asks for it right away.
Fixes#78
To check if a subsurface is effectively synchronized, we walk the
subsurface hierarchy to look for a non-subsurface parent or a subsurface
being synchronized.
However, when client is closing, the parent surface might already be
gone, in which case we end up with a surface being NULL which causes a
NULL pointer dereference and a crash.
Check if the parent surface is NULL to avoid the crash, and consider
it's already synchronized if it is NULL to avoid further updates.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/124
(cherry picked from commit 52fdd24467)
Before we just set it to "none", but this was not enough since various
calls will depend on not just the context being active, but the main
rendering surface.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/21
(cherry picked from commit ae26cd0774)
When deriving the global scale directly from the current hardware state
(as done when using the X11 backend) we are inspecting the logical
state they had prior to the most recent hot plug. That means that a
primary monitor might have been disabled, and a new primary monitor may
not have been assigned yet.
Stop assuming a primary monitor has an active mode before having
reconstructed the logical state by finding some active monitor if the
old primary monitor was disabled. This avoids a crash when trying to
derive the global scale from a disabled monitor.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/130
(cherry picked from commit 0b3a1c9c31)
These paths implicitly relied on the forwarded IM key events having
a source_device backed by a real HW device. This assumption is no
longer held true since commit b5328c977.
Explicitly check the INPUT_METHOD flag so they are handled as they
should despite not being "real HW" events.
As a follow up to the patch from a95cbd0a, we need to make sure
that the pointer is out of the way as well when monitors changed,
since that's the event that will prevail in some cases. Besides,
this is also consistent with what the code before a95cbd0a was,
which initialized the pointer position in the same way both in
this case and in the real_post_init() function.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/157
Centering the pointer at startup causes undesired behaviour if
it ends up hovering over reactive elements, that might react
to that positioning, causing confusion. This is the case of
the login dialog when a list of different users is shown, as
centering the pointer at startup in that case will get the
user in the center of the screen pre-selected, which is not
the expected behaviour (i.e. pre-selecting the first one).
Fix this by simply moving the pointer out of the way, close
to the bottom-right corner, during initialization.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/157
