In a following commit we will start supporting scaled and croped
surfaces, thus, in preparation, update the logic to three common cases:
1. only one surface, fullscreen (most apps)
2. a content surface and a black background surface which the client
does not want to unmap, fullscreen
3. top-level subsurface covers the whole window and is opaque (Firefox)
The remaining currently supported cases should be fairly uncommen and
and harder to compute.
Note that we already check that the window cover the stage view in
MetaCompositorView.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177>
This allows us to pass on the related data from CoglScanouts.
If dst_rect does not match the mode, we assume that not covered areas
are opaque black - usually black bars around a centered surface.
While such driver behaviour does not appear to be documented (well) yet,
it seems to be followed by all known existing drivers and is used in a
similar way in ChromeOS.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177>
We need an object to hold additional scanout related information, such
as scaling and positioning data. Turn CoglScanout into such an object,
moving the interface into CoglScanoutBuffer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177>
Except meta_window_x11_get_group, which is still used by GNOME Shell
and we can't make it a private API for now.
Will need further investigation and could be done as a future
step
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3555>
The macro used to call into a bunch of other macros so let us turn it
into a single function.
This would simplify things for the next commit that puts the MetaGroup
usage behind a X11 ifdef
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3555>
If such a failure is followed by a successful frame then the Cogl frame
queue would have size 2, leading to an assertion failure in
`meta_onscreen_native_notify_frame_complete`:
```
g_assert (!cogl_onscreen_peek_head_frame_info (onscreen));
```
Notifying on the failure however keeps the Cogl frame queue limited to
a size of 1 and we recover gracefully with only a missed frame and a
warning message.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3278
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3565>
Popups were missing the "input focus" unification in the pointer
seat, triggering MetaWaylandKeyboard focus changes underneath. On
one hand this missed moving all associated focus with it, on the
other hand this made keyboard and global input focus get out of
sync, and bring funky behavior like keyboard focus loss after
dismissing popups.
Fixes: 7b232d9f65 ("wayland: Keep track of the "input focus" on MetaWaylandSeat")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3256
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3568>
In some circumstances, we may end up with outputs with the same
vendor/product/serial, in which case we have a hard time finding the
right one to map tablets to, since configuration only has these 3
pieces of data.
Add the handling of a 4th argument containing the output name
based on the connector (e.g. HDMI-1), so that it can be used to
disambiguate the output if necessary.
This only kicks in if there actually are multiple outputs with the
same EDID data. A goal of the configuration as it was stored was to
remain useful if the user changed how the device is physically
connected to the computer, this remains true for the vast majority
of users having a single thing of each.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3556>
Our hashtable stores tools by the serial but our stylus tool and eraser
tool share the same serial - they only differ by the tool type.
This results in only one tool being created and this tool re-used for
the other type tool. Fun side-effects of this are that the stylus ends
up using the eraser pressure curve (or vice versa).
Hack around this by bit-flipping the serial for the eraser to
make it distinct - this is the only place we need to wrorry .
Closes#1884
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3542>
For barrier validation, check_barrier() would start from the
(presumably) left-most monitor and walk the neighbor monitors to the
right.
This is assuming that there is always a monitor at (0.0), which is not
necessarily the case. If the first monitor on the left is not aligned at
the top, there is no logical monitor at (0.0) causing a NULL pointer
derefence.
Instead of starting from the monitor at (0,0), start from the primary
logical monitor, as there is necessarily one.
Fixes: 85885c6 - Check barriers don't extend into nonexisting monitors
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3272
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3562>
There doesn't seem to be a good reason to keep this code in
`MetaWaylandSurface`. Moving it to `MetaWaylandBuffer` cleans things
up and will allow us to tread buffers differently depending on their
type.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3559>
For secondary GPU rendering contexts we currently might choose an EGL
config with a format which is not supported on all primary planes. The
renderer is created when a GPU is detected and lighting up outputs and
thus assigning CRTC and primary planes can happen at any point after
that. This means we have to make sure that all possible plane
assignments will work with the rendering context when we create it.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3235
Fixes: cc7bca073 ("crtc/kms: Dynamically assign primary and cursor planes")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3512>
It can be used to force a specific RGB range. Some monitors don't follow
the specification and expect a signal different from what we send. This
property allows to force a mode which hopefully then works correctly for
the sink.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3535>
A ring will naturally go from 355 degrees to 5 degrees (or vice versa),
giving us the illusion of a direction change. Avoid this by assuming
that any change larger than 180 degrees is actually the equivalent
smaller change in the other direction.
Closes#1885
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3545>
BTN_STYLUS is the lower one and traditionally (read: in X) maps to
middle button (2), BTN_STYLUS2 is the upper one and traditionally maps
to right button (3).
This is also what GTK does and our desktop actions too map MIDDLE to
BTN_STYLUS and RIGHT to BTN_STYLUS2.
See also gtk!6168
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3541>
The code that maybe flushed IM state before processing a key event
became ineffective at commit 7716b62fa2, since the handle_event()
method on MetaWaylandTextInput won't handle key events, only IM
events and touch/button press events causing IM state to be
committed. Basically, the events that directly change the IM state.
Move this ineffective code to the the filter_event() method handling
the key presses in order to let the IM maybe filter them, and handle
them so that any key event that is let through (both key events
previously injected by the IM, and key events that the IM chooses to
ignore) will ensure that the pending IM state is flushed before the
key event is handled and emitted to the client.
This brings back lost guarantees of orderly event emission when IMs
alternate key events and IM actions.
Fixes: 7716b62fa2 ("clutter: Separate ClutterInputFocus event processing and filtering")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3090
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3536>
adwaita-icon-theme updated its cursor metaphors and changed all DnD
cursors to use arrows instead of hands, except for the grab related
ones. Mutter was using "grabbing" as default DnD cursor, which now
does not match the other DnD cursors ("copy" and "no-drop") anymore.
Change this to the "default" cursor.
Additionally, because the "no-drop" cursor now puts a stronger emphasis
on the crossed out symbol also prefer "default" for
META_CURSOR_DND_IN_DRAG and only use "no-drop" for things that
explicitly don't accept a drop.
Related: https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/merge_requests/63
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3532>
When Wayland clients send commits without a buffer attached ("empty"
commits), they may lead to stage updates that do not result in any
frame being submitted for presentation ("empty" updates).
Due to how frame scheduling is handled, there can be many such
"empty" updates in a single refresh cycle. If frame callbacks were
emitted after each of these "empty" updates, and if the client
sending "empty" commits was using frame callbacks to throttle the
same logic that results in these "empty" commits being sent, it would
result in a feedback loop between Mutter and the client where the
client would send "empty" commits and Mutter would reply almost
immediately with a frame callback causing the client to send "empty"
commits continuously.
As such, when an "empty" update is detected, frame callbacks are
scheduled to be emitted only once in every refresh cycle, avoiding the
feedback loop.
When a "non-empty" update is detected, frame callbacks are instead
emitted immediately to allow clients to draw their next frame as soon
as possible. It is safe to emit frame callbacks in this case because
the frame for the current refresh cycle is already "finalized" and
that any commit sent by the client at that point would only be handled
in a future refresh cycle.
To implement this, the previous logic had used
meta_frame_native_had_kms_update() to detect "non-empty" updates,
assuming that those would always result in a KMS presentation with the
native backend.
However, this approach misses the fact that virtual monitors do not
use KMS, and as such do not result in KMS presentation even for
"non-empty" updates. As a result, frame callbacks would not be emitted
immediately, resulting in unintended throttling of client rendering.
Instead, assume that it is safe to emit frame callbacks immediately
whenever an update results in the frame clock waiting to be notified
of presentation, since this is also when commits sent by clients are
scheduled to be handled in a future refresh cycle.
This issue was mostly hidden because frame callbacks would be sent
immediately when the target presentation time for the frame had
changed compared to the previous frame. However, this behavior was
removed in 26d8b9c69 ("wayland: Remove unnecessary dispatch of frame
callback source"), exposing the issue.
Fixes: a7a7933e0 ("wayland: Emit frame events in GSource after "empty" updates")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3263
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3549>
Calculate the frame deadline in ClutterFrameClock's
calculate_next_update_time_us() rather than in MetaWaylandCompositor's
on_after_update().
The specifics of the deadline calculation for a given frame should be
implementation detail of the frame clock and and remain internal to
allow extensibility.
This extensibility is specifically useful for scenarios where a
different deadline calculation is needed due to alternative frame
scheduling logic, such as for VRR.
No change in behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3521>
To avoid communicating lower frame rate to clients through frame
callbacks, it is important to avoid delaying the source dispatch when
a dispatch is already scheduled.
To that end, the previous logic would emit pending frame callbacks
immediately in case a source dispatch was still scheduled for the
previous refresh cycle and then (potentially) schedule another source
dispatch for the current refresh cycle.
However, emitting pending frame callbacks immediately would send
frame events for every pending frame callback, including for the
current "empty" update. Scheduling another source dispatch for the
current cycle was then unnecessary and potentially undesirable
because there may not even be another "empty" update during the cycle.
Instead, let the already-scheduled source dispatch handle emitting any
pending frame callbacks, and do not schedule an additional source
dispatch for the current cycle as it may not be needed.
This approach is useful because it removes an implicit assumption
that the refresh rate is fixed and that target presentation time
remains constant within a refresh cycle. This assumption does not
apply for VRR.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3521>
The value of this variable represents the last point in time in
which an update would be allowed to scheduled for the given frame.
Rename it for clarity and in preparation for the next commits.
No change in behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3521>
The value returned from clutter_frame_get_target_presentation_time()
is always same as the value returned from
clutter_frame_get_min_render_time_allowed() when they are called
consecutively because both functions effectively return the value of
frame->has_target_presentation_time. This is with the assumption
that this variable is only ever modified by the same thread that
also executes on_after_update().
As such, a case where the former returns FALSE after the latter
returned TRUE is not possible, which means the line that sets
"target_presentation_time_us = 0;" is effectively unreachable.
Acknowledging this fact allows the call to
clutter_frame_get_target_presentation_time() to be moved outside the
"else" case and into the "if" condition itself. This is done in
preparation for the next commits.
No change in behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3521>
In various public APIs, Clutter used to return a PangoDirection
while we have a text direction enum defined in Clutter.
This allows us to drop pango dependency from meta making it specific
to cogl-pango & clutter
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3531>
It adds the following clarification:
```
Starting from version 5, the invalid_format protocol error is sent if
all planes don't use the same modifier.
```
We already send an error, just the wrong one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3450>
Set the deadline timer state as "inhibited" in case a permission error
is returned while attempting to arm the deadline timer. This makes each
device enable its deadline timer again after a VT switch.
Also print a note in this case instead of a warning as such errors are
expected during a VT switch and should not raise concerns.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3259
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3534>
For now, this function only enables the deadline timer in case it was
inhibited. This would result in an attempt to use the deadline timer
again after a device is resumed.
If the conditions that resulted in the timer becoming inhibited
remain, it is expected to return to this state after the next frame
and before being armed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3534>
The "disabled" state indicates that the deadline timer is disabled
for the lifetime of the device, while the "inhibited" state indicates
that it is disabled temporarily for the device.
This distinction is needed to handle each state differently in a
following commit. For now, only "disabled" is used.
No change in behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3534>
This allows GNOME Shell to communicate the user desired XKB model
to the compositor instead of sticking with the pc105 default.
Particularly useful for those with a custom keyboard layout/irregular
keyboards.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2760>
Transient dialogs are meant to be placed centered over their
parent. However as we don't use the DIALOG window type on
wayland, this currently only works for modal dialogs.
To fix this, also apply the policy to NORMAL windows for
wayland clients.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3533>
Some panels only support fixed resolutions and fixed refresh rate with reduced blanking:
Established Timings I & II: none
Standard Timings: none
Detailed Timing Descriptors:
DTD 1: 2560x1600 120.001823 Hz 8:5 203.283 kHz 552.930000 MHz (345 mm x 215 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 6 Vback 85 Vpol N
DTD 2: 2560x1600 48.000295 Hz 8:5 81.312 kHz 221.170000 MHz (345 mm x 215 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 6 Vback 85 Vpol N
...
Minimum Pixel Clock: 552922 kHz
Maximum Pixel Clock: 552922 kHz
When using mirror mode, resolutions like 2560x1440 120Hz can be too high
to meet the pixelclock limitation, so 2560x1440 90Hz is selected
instead. However, the panel only supports 120Hz so using 90Hz result to
failed mode set.
So add reduced blanking to fallback mode, so correct refresh rate can be
used.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3449>
Since StDrawingArea in gnome-shell is the only user of ClutterCanvas,
it is possible to move ClutterCanvas completely out of Mutter to
gnome-shell. This allows to remove another Cairo dependency from
Mutter.
This patch removes ClutterCanvas code from Mutter.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3470>
To paraphrase jadahl: we have a dedicated KMS thread now, which also
has realtime scheduling enabled unconditionally. realtime scheduling
on the main thread isn't too great of an idea, considering GC can
take a hot minute.
And to quote rmader: we most likely won't be able to make the main
thread rt as long as we use GJS and thus have GC.
So let's get rid of it! It's just been breaking things anyways.
This just ignores the setting; we'll fully remove it when GNOME 46
comes around.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3296>
This is the unified focus (key, IM, pads, ...) for the focus window.
Just like MetaWaylandPointer and others keep track of the "current"
surface, this is the "current" surface for those (not necessarily
the focused surface, e.g. in the case of compositor grabs).
Since this unified focus will exist regardless of keyboard
capabilities (e.g. even if just for "logical" focus like IM/clipboard
that does not depend on input devices), it does not make sense
to trigger a focus sync on keyboard capability changes, the focus
is staying the same, we however need to focus the keyboard interface
to the already existing focus when the capability is enabled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3511>
Instead of letting the MetaDisplay be aware of the Wayland compositor,
and take care of updating its focus. This makes the MetaWaylandCompositor
able to track focus changes by itself, using MetaDisplay as the source
of truth.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3511>
If we happen to be changing focus to a window *while* taking focus
away from Clutter widgetry, we would unintendedly trigger reentrance
in a way that the old focused window remained in focus, by asking
to focus the default focus window in an untimely manner.
To handle this reentrancy, delay dropping the Clutter key focus
until the window focus changed, so that the focus change will look
up the default focused window in the workspace, and find the up to
date one.
Fixes: ae102ee301 ("x11: Refactor ClutterStage key focus management")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3467>
Trying to get the xwindow of a wayland only window would fail when
casting to a x11 window. Which happens as
meta_x11_display_set_input_focus is called whenever the focused
window changes, whether it is a wayland or x11 one
Fixes: bc9cd123e ("window: Move xwindow to WindowX11")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3506>
