We need a way for mutter to exit if no available GPUs are going to work.
For example if gdm starts gnome-shell and we're using a DRM driver that
doesn't work with KMS then we should exit so that GDM can try with Xorg,
rather than operating in headless mode.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/223
(cherry picked from commit deb541ef5a)
DRM drivers can be opened by meta_launcher_open_restricted() even if they don't
implement modesetting. However, drmModeGetResources() will return NULL.
Check whether that happened in meta_gpu_kms_new() and return with an error
instead of crashing.
Fixes#223.
For historical reasons meta_monitor_is_active() checked whether it is
active by checking whether the main output have a CRTC assigned and
whether that CRTC has a current mode. At a later point, the MetaMonitor
got its own mode abstraction (MetaMonitorMode), but
meta_monitor_is_active() was never updated to use this.
An issue with checking the main output's CRTC state is that, if there is
some CRTC mode combination that for some reason isn't properly detected
by the MetaMonitorMode abstraction (e.g. some tiling configuration not
yet handled), meta_monitor_is_active() would return TRUE, even though no
(abstracted) mode was set. This would cause confusion here and there,
leading to NULL pointer dereferences due to the assumption that if a
monitor is active, it has an active mode.
Instead, change meta_monitor_is_active() to directly check the current
monitor mode, and log a warning if the main output still happen to have
a CRTC with a mode assigned to it. This way, when an not undrestood CRTC
mode combination is encountered, instead of dereferencing NULL pointers,
simply assume the monitor is not active, which means that it will not be
managed or rendered by mutter at all.
https://gitlab.gnome.org/GNOME/mutter/issues/130
(cherry picked from commit 4d465eac08)
When a transient window is destroyed, the expected behavior is that
focus is passed to the ancestor if possible. This was broken for
quite a while until the previous commit, so add a test case to make
sure it doesn't happen again.
https://gitlab.gnome.org/GNOME/mutter/issues/15
(cherry-picked from commit 137f22236c)
Since commit b3b9d9e16 we no longer have to pass the unmanaging window
to make sure we don't try to focus it again, however the parameter also
influences the focus policy by giving ancestors preference over the normal
stack order.
https://gitlab.gnome.org/GNOME/mutter/issues/15
(cherry picked from commit d99442d6e6)
We refuse to move focus while a grab operation is in place. While this
generally makes sense, there's no reason why the window that owns the
grab shouldn't be given the regular input focus as well - we pretty
much assume that the grab window is also the focus window anyway.
In fact there's a strong reason for allowing the focus change here:
If the grab window isn't the focus window, it probably has a modal
transient that is focused instead, and a likely reason for the focus
request is that the transient is being unmanaged and we must move
the focus elsewhere.
https://gitlab.gnome.org/GNOME/mutter/issues/15
(cherry picked from commit 148da24f95)
If drmModeSetCrtc() is called with no fb, mode or connectors for some
CRTC it may still fail, and we should handle that gracefully instead of
assuming it failed to set a non-disabled state.
Closes https://gitlab.gnome.org/GNOME/mutter/issues/70
(cherry picked from commit 6e953e2725)
If the surface is gone before `meta_xwayland_keyboard_grab_end()` is
called, we would bail out early leaving an empty grab, which will cause
a segfault as soon as a key is pressed later on.
Make sure we clean up the keyboard grab even if the surface is gone.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/255
(cherry picked from commit 252dd52439)
To avoid a known race condition in the wl_output protocol documented in
https://phabricator.freedesktop.org/T7722, mutter delays the `wl_output`
destruction but nullify the `logical_monitor` associated with the
`wl_output` and the binding routine `bind_output()` makes sure not to
send wl_output events if the `logical_monitor` is `NULL` (see commit
1923db97).
The binding routine for `xdg_output` however does not check for such a
condition, hence if the output configuration changes while a client is
binding to xdg-output (typically Xwayland at startup), mutter would
crash while trying to access the `logical_monitor` which was nullified
by the change in configuration.
Just like `bind_output()` does for wl_output, do not send xdg-output
events if there is no `logical_monitor` yet.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/194
(cherry picked from commit 68ec9ac017)
If a client asks for xdg-output before we have set the output's logical
monitor, we would end up crashing with a NULL pointer dereference.
Make sure we clear the resource's user data when marking an output as
inert on monitor change so that we don't end up with a Wayland output
without a logical monitor.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/194
(cherry picked from commit 48eaa36d41)
When we update the main monitor, there is a rule that makes it so that
popup windows use the same main monitor as their parent. In the commit
f4d07caa38 the call that updates and
fetches the main monitor of the toplevel accidentally changed to update
from itself, causing a indefinite recursion eventually resulting in a
crash.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/279
(cherry picked from commit e191c21e04)
meta_window_wayland_update_main_monitor() would skip the monitor update
if the difference in scale between the old and the new monitor would
cause another monitor change.
While this is suitable when the monitor change results from a user
interactively moving the surface between monitors of different scales,
this can leave dangling pointers to freed monitors when this is
triggered by a change of monitor configuration.
Make sure we update the monitor unconditionally if not from a user
operation.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/189
(cherry picked from commit a3da4b8d5b)
meta_window_wayland_update_main_monitor() would skip the monitor update
if the difference in scale between the old and the new monitor would
cause another monitor change.
While this is suitable when the monitor change results from a user
interactively moving the surface between monitors of different scales,
this can leave dangling pointers to freed monitors when this is
triggered by a change of monitor configuration.
Make sure we update the monitor unconditionally if not from a user
operation.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/189
(cherry picked from commit a3da4b8d5b)
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
