We have meta_verify_logical_monitor_config() already, and it does a few checks that
meta_verify_monitors_config() doesn't do yet, so let's also call
meta_verify_logical_monitor_config() when verifying the whole config.
We'll rely on this being part of meta_verify_monitors_config() soon, because we'll
stop calling meta_verify_logical_monitor_config() from the config parser.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3596>
We forgot to check whether multiple groups of monitors are actually
all connected with each other, so fix that.
[jadahl: Rewrote algorithm to detect split groups]
[jadahl: Added test case]
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3596>
The first event happening for a new touch will be the CLUTTER_ENTER
event generated when picking it. Use this event for registration of
the touch info, so that MetaWaylandEventHandler.get_focus_surface may
get the right focus surface for the device/sequence on the first try.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3889>
And notably, don't cancel touch when an event handler is being
removed. Touch events are largely unaffected by most Wayland
grabs (pointer constraints, popups), so we might be cancelling
input too early if one of these wayland grabs was effective when
touch interaction began, but stopped sometime between touch updates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3889>
Touch events are implicitly grabbed to the surface they began in,
and are not affected by the focus handler. However these events
will appear to come from the core pointer device, which might lead
to the wrong device being updated.
Ignore events with a sequence, since the default focus handler
does not intend to do anything with them.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3889>
On a hybrid machine with i915 primary and nvidia-drm (470) secondary,
`meta_render_device_egl_stream_initable_init` calls
`meta_kms_inhibit_kernel_thread` to change from the default 'kernel'
thread type to 'user'. And soon after that it would
`meta_render_device_egl_stream_finalize` because I'm not actually
using that GPU, and calls `meta_kms_uninhibit_kernel_thread`.
So during startup Mutter would default to a realtime kernel thread,
switch to a user thread (which doesn't support realtime), and then
switch back to a realtime kernel thread.
In the middle of all that, while the thread type was 'user' and
realtime disabled, something was invoking `ensure_crtc_frame` which
created a `CrtcFrame` without a deadline timer. Soon after that the
thread type changed back to 'kernel' with deadline timers expected, but
our existing `CrtcFrame` has no deadline timer associated with it. And
so it would never fire, causing the cursor to freeze whenever the primary
plane isn't changing. And the problem was permanent, not just the first
frame because each `CrtcFrame` gets repeatedly reused (maybe shouldn't
be called a "Frame"?).
Now we adapt to switching between kernel and user thread types by adding
and removing the deadline timer as required.
Close: https://gitlab.gnome.org/GNOME/mutter/-/issues/3464
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3950>
Colord is a system service which will result in a polkit dialog showing
up when connecting a remote session.
We want to get rid of colord eventually anyway, so disconnecting virtual
monitors from colord isn't an issue.
Fixes: f5ce2ddf3c ("color-manager: Create color devices also for virtual monitors")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3942>
If we finish compositing in time, the composited result will be
submitted prior to the deadline timer is triggered, and we'll be fine,
and if not, at least the cursor updates will be smooth, which makes it
appear smoother than not.
There is a risk that this can negatively impact composited updates when
moving the cursor, so make it possible to toggle a paint-debug flag for
now until this has been more tested.
This also mean we need to disarm the deadline timer after handling
update, as there might be a scheduled cursor update pending, but we
already handled it, so disarm the timer.
Here is an illustration of the difference.
In the following scenario, with disarming, the composited frame E, and
the cursor movement C gets presented. With this branch, only the cursor
movement C gets presented.
```
* A: beginning of composited frame
* B: begin notification reaches KMS thread
* C: cursor moved
* D: calculated deadline dispatch time (disabled with the branch)
* E: KMS update posted
* F: KMS update reaches KMS thread
* G: actual deadline (and with branch and gets committed)
Compositor thread: --------A---------------E---------
\ \
\ \
KMS thread: -----------B------C----D---F-G----
```
In the following scenario, by not disarming, the cursor update C will be
presented, and the would-be-delayed composited frame E would be delayed
anyway, i.e. fixing cursor stutter.
```
* A: beginning of composited frame
* B: begin notification reaches KMS thread
* C: cursor moved
* D: calculated deadline dispatch time (and with branch will be dispatched)
* E: KMS update posted
* F: actual deadline
* G: KMS update reaches KMS thread (and with branch gets postponed)
Compositor thread: --------A---------------E---------
\ \
\ \
KMS thread: -----------B------C----D-F-G------
```
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3184>
Although we track updates for EGL_DEVICE, they are often empty because
the primary plane has a custom page flip method. That means there's
no CRTC latched yet, but we do know exactly which CRTC is associated
with the flip. Set it so the update can still be processed.
Fixes: 27ed069766 ("kms/impl-device: Add deadline based KMS commit scheduling")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3939>
If other handlers (e.g. DnD) are on top of the popup grab focus, we
may want it to move outside same-client surfaces as the popup grab
specifies.
Check that it is the current handler before making same-client checks,
so that these handlers on top have an opportunity to find other
surfaces, e.g. during DnD from a popup.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1681
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3937>
Move away from tracking presses/releases directly, since there might be
other event handlers on top that might prevent the popup event handler
to fully track all events. The replacement is using event state modifiers,
which will use information set from the backend, and is enough to determine
there's no more pressed buttons without tracking prior event history.
This makes the popup event handler able to interact with other event
handlers that might be on top, and consume button release events for
themselves (e.g. DnD), no longer resulting in a stuck popup grab.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3937>
The relationship between MetaKmsConnector and MetaDrmLease is already
stored in MetaDrmLeaseManager::leased_connectors.
Change the type of MetaDrmLeaseManager::connectors to a GList.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3922>
As in the protocol definition for wp_drm_lease_connector_v1::withdrawn:
Sent to indicate that the compositor will no longer honor requests
for DRM leases which include this connector. [...] Compositors are
encouraged to send this event when [...] the connector gets leased
to a client.
Withdrawn the leased connectors and, if they are available once the
lease finishes, advertise them again.
Related to: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/322/
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3922>
And stop passing in the color states from the RendererNative. We also
keep the color states updated by listening for changes in the color
device.
The RendererX11Cm has a single view and no mapping to a specific color
device, so we handle the absense of a color device as well and rely on
ClutterStageView to have the default color states.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3930>
This allows us to destroy and create a new offscreen dynamically, when
the rotation or color state changes.
An idle gsource with priority higher than CLUTTER_PRIORITY_REDRAW is
used to ensure the an offscreen exists when required without having to
allocate in the redraw process.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3930>
This is usually an indication of a failed drop operation if the
drop site didn't request any target. Check for this specifically
on XDnD button release, so that we can cancel the DnD operation
right away.
Inspired on a fix from Jonas Ådahl.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3821>
We were relying on the drag source surface to keep receiving events
thanks to it being implicitly grabbed by the button press. This
broke at some point, making the Xdnd drag source unable to keep
directing the DnD operation as it is expected by X11 clients.
To fix this, make the Xdnd MetaWaylandEventInterface stick itself
to the drag source surface keeping the focus of the device driving
the DnD operation, so that the X11 client can still handle events
from it.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3511
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3821>
Currently, we would only disable a11y if a certain flag is passed
but the function is always called with NONE flag. Instead
drop the flag, use a new environment variable for that
That value is then used by actors to short-circuit get_accessible
implementation and return NULL if the accessibility is not enabled
Also clean the other accessibility functions
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3917>
Instead of doing that in both MetaStage & CallyStage.
This allows ClutterStage to also emits the relavant acessibility
bits directly without having a roundtrip through Cally
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3917>
The generic term updated can mean anything. This is specifically about
calibration related updates like changing the sink colorimetry
(Colorspace, HDR metadata) and changes to the white point for night
light etc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3904>
Previously the color device was destroyed when it was attached to a
monitor that was going away. However, the MetaMonitor objects are
ref-counted and can stay around for longer, even if the underlying
resources went away. We need color devices for as long as the
MetaMonitors are alive.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3904>
Every monitor should eventually have a corresponding color device. To
make sure this can work, we must handle situations where the color
manager didn't connect to colord yet, and thus isn't ready.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3904>
