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>
The stage has the knowledge about input that is ongoing over it
(incl. things like styli and touchpoints). Add an iterator API
for these devices/touchpoints, so they can be used for calculations
and heuristics in other places of the code.
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>
So far, we expected all events to have input devices set on them, IM events
lost theirs with commit 6aa42d6dad. This somewhat made sense, because IM
events are not backed by any actual device, they are generated by us in
response to eg. an OSK key press.
To fullfil the assumption that all devices at least have a logical input
device set, pass the seat to the clutter_event_im_new() constructor and then
set the device to the logical keyboard device. The source_device we leave
empty, since there is no actual physical device that this event came from.
Fixes: 6aa42d6dad
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3236>
The assertion for !implicit_grab_cancelled in the
`grab_actor == old_grab_actor` case of
clutter_stage_notify_grab_on_pointer_entry() is meant to do a simple
sanity-check to ensure the grab machinery is working as intended: During a
seat grab, all input gets delivered to the tree inside the grab, and all
implicit grabs outside of that tree are cancelled.
When a new seat grab on the same actor as the existing one happens, we run
through the cancellation machinery for implicit grabs anyway, so we might as
well check that the assumption mentioned above holds true: By asserting that
no implicit grabs were cancelled, we know that no implicit grabs exist
outside of the existing seat grab tree.
This assertion is slightly over-eager though due to the way we set
implicit_grab_cancelled: We initialize it to TRUE in the
entry->press_count > 0 case and then only set it to FALSE once we find an
implicit grab that may remain active. If there are no implicit grabs though
(while entry->press_count is still >0), we never set implicit_grab_cancelled
to FALSE, triggering the assertion in question even though no implicit grabs
got cancelled.
There's two possible solutions for this: Either dropping the assertion, or
refactoring it so it observes the situation where the implicit grabs were
already undone. This commit implements the latter.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2700
Fixes: debbd88f8c ("clutter/stage: Cancel parts of implicit grabs when ClutterGrabs happen")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3216>
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>
We currently have a bit of a disaster area wrt X11 error handling,
with all of Cogl/Clutter/Mutter offering implementations with different
expectations and different degrees of integration with other error
handlers.
It makes more sense to have a single X11 error handling implementation
that is used in all those places. Mtk seems like the reasonable place
to have this kind of general API, so adopt the more advanced code
at src/x11.
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>
