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>
The new CLUTTER_FRAME_CLOCK_STATE_SCHEDULED_NOW state is almost
identical to CLUTTER_FRAME_CLOCK_STATE_SCHEDULED, with one important
difference being that it avoids updates from being repeatedly
rescheduled "now" when multiple calls to
clutter_frame_clock_schedule_update_now() are done before the source
is actually dispatched.
Such repeated calls to schedule an update "now" may actually postpone
the dispatch if the CPU is very busy and the source dispatch is
delayed, defeating the purpose of scheduling a frame "now".
It also allows rescheduling "now" when the frame clock is uninhibited
after being inhibited while an update was scheduled "now". This may
be important in cases where the frame clock is inhibited for very
short periods in which it would otherwise lose the state of being
scheduled "now".
Scenarios such as this would become more common with the introduction
of variable refresh rate since it makes scheduling "now" a commonplace
occurrence.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3561>
Currently, the paint-volumes/redraws debug flags displays the actor
debug
names on top of the paint volume making it very unusable. Especially
that you can easily get the relevant actor from looking glass.
The motivation is to reduce the usage of pango (through the text node)
in order to possibly move all the fonts bits to gnome shell
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3571>
This removes an incorrect implicit assumption in
calculate_next_update_time_us() that a frame may only be scheduled
once in the duration of a refresh cycle. It accomplishes this by
setting last_next_presentation_time_us on presentation feedback
instead of calculating it every time an update is scheduled.
Specifically, it corrects the intended scheduling logic in scenarios
like the following, when all of the below occur in the context of a
single refresh cycle:
1. Frame update (1) is scheduled normally, and
"is_next_presentation_time_valid" is set to TRUE
2. Frame update (1) is dispatched but ends up being "empty" (no
presentation necessary)
3. Frame update (2) is scheduled "now" and
"is_next_presentation_time_valid" is set to FALSE
4. Frame update (2) is dispatched but ends up being "empty" (no
presentation necessary)
5. Frame update (3) is scheduled normally, and since
"is_next_presentation_time_valid" is set to FALSE, the
"early presented event" logic is unintentionally skipped in
calculate_next_update_time_us().
6. Frame update (3) is dispatched and ends up being a "non-empty"
update, but its update time was calculated incorrectly because
some logic was skipped.
Scenarios such as this would become more common with the introduction
of variable refresh rate since it makes scheduling "now" a commonplace
occurrence.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3560>
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>
I haven't seen this cause a problem but it looks like the worst case is
that it would have put the wrong refresh rate value in CoglFrameInfo
for multi-monitor systems of differing frequencies. But even that seems
unlikely given `_cogl_xlib_renderer_output_for_rectangle` chooses the
output with the greatest overlap of the partially-correct rectangle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3569>
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>
