At first it was called seal(), but then updates could be amended after
being posted, given a flag. That flag has been removed, so we can go
back to sealing, since it's once again acts more as a seal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
We test direct client buffer scanout using a TEST_ONLY commit on atomic,
and with various conditions in non-atomic, but if we end up failing to
actually commit despite this, handle the fallout asynchronously. What
this means is that we'll reschedule a new frame immediately.
For this to work, the same scanout buffer needs to be avoided for the
same CRTC. This is done by using the newly added signal on the
CoglScanout object to let the MetaWaylandBuffer object mark the current
buffer as non-working for the onsrceen that it failed on. This allows to
re-try buffers on the same onscreen when new ones are attached.
This queues a full damage, since we consumed the qeued redraw rect. The
redraw rect wasn't lost - it was accumulated to make sure the whole
primary plane was redrawed according to the damage region, whenever we
would end up no longer doing direct scanout, but this accumulation only
works when we're not intentionally stopping to scanout. For now, lets
just damage the whole view, it's just an graceful fallback in response
to an unexpected error anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
Stage view users can schedule updates at ease with
clutter_stage_view_schedule_update(), but couldn't schedule update
"now". Make that easy too by adding
clutter_stage_view_schedule_update_now().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
If we call schedule(), which will schedule an update some time in the
future, and then schedule_now(), we should reschedule the frame clock to
update immediately, and not some time in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
If we get a "ready" page flip feedback, it means the page flip was
symbolic, i.e. not real, e.g. as a result of an update that didn't
change the state of the primary plane. Warn if there is a "next fb"
meaning we expected to have a new buffer that we flipped to.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
This will later be emitted when a scanout failed, e.g. by the not-test commit
failing for some reason, or drmModePageFlip() failing even if the
pre-conditions for scanout in the simple KMS backend passed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
This is intended to be used only for plane assignment, and CRTC like
changes, so that one can e.g. change a cursor plane on a pending update
that changes the primary plane, before it has been committed to KMS.
The kms-updates test overrides the get-state function MetaKmsCrtc. This
is needd to not have the update mechanism not clamp the gamma size to 0,
as vkms reports the gamma length 0. By pretending it's 3, we can test a
simple and small gamma lut is merged correctly when merging updates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
This looks like a bug: There's no reason why windows which advertise
min-size hints that are exactly the size of the workarea should not be
allowed to maximize, so change the checks here to allow for that.
The commit message of 7f64d6b9 also makes the point that this was not
intended, as it says "larger than".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2873>
Surfaces belonging to a screen-casted window should always be considered
visible even if they are not visible on any stage view - be it because
they are on a different workspace, minimized or occluded.
Doing this in an optimal fashion is highly complex right now -
interdependent with (and somewhat similar to) ClutterClones. Thus treat
stream-casted surfaces similar to those with clones, with the small
difference that even a fully invisible surface still gets a primary view
- the fastest one. This ensures that clients never refresh too slow for a
screen-cast, at the cost of sometimes refreshing too fast.
The later only happens on certain multi-monitor setups and should thus be
acceptable.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
There is an increasing number of cases where we want the frame callback
logic to run for a stage-view and the complexity needed to avoid these,
combined with the likelyhood of bugs, arguably does not justify the
benefit any more.
Thus unconditionally schedule updates for all stage-views when frame
callbacks are requested.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
Screen-casted windows need to be considered visible in various situations
but existing APIs such as `clutter_actor_is_effectively_on_stage_view()`
don't do so. Add new API that allows checking if a surface belongs to a
screen-casted window for the respective cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
The introduction of the META_GRAB_OP_WINDOW_FLAG_UNCONSTRAINED
flag threw off some checks around keyboard-driven resize. This
was partly because there were some == checks that did not account
for that flag maybe being enabled, but also the handling
of META_GRAB_OP_KEYBOARD_RESIZING_UNKNOWN into a definite
resize direction was maybe unsetting that flag. Fix both things
at the same time.
Fixes: 2d8fa26c8e ("core: Pass "frame action" grab operations as an "unconstrained" grab op")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2629
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2871>
From the scale factors available to it, Mutter will now try to select
the scale factor that makes the UI's size as close as possible to the
size it would be, w/o scaling, on a display at 135 PPI (for mobile
displays) or at 110 PPI (for stationary displays)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2653>
After !2489, the active workspace's MRU list is now used to pick
the next focus window instead of the stack order.
This list is currently only updated on focus, which can lead to
surprising behavior when closing a window after activating its
ShellApp in the shell.
That is because raising a window (as part of shell_app_activate())
will only change the stacking order, so when closing the active
app window, the focus will switch to whatever had focus before the
app was activated, not the app's next window.
In order to allow gnome-shell to address this, add a new
raise_and_make_recent() method that also adjust the MRU order.
https://gitlab.gnome.org/GNOME/mutter/-/issues/2540
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2866>
The pointer to the manager, the peer name and the ID are things that are
always metadata related to a session, so make them properties on the
interface instead of duplicating them. The implementations still need to
keep track of them, but their existance is shared.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2713>
This class is intended to be used as a base class for D-bus interface
implementations that deal with "session" objects, i.e. a D-Bus object
representing a certain session of some kind, e.g. a screen cast session.
It handles things such as hooking up to the D-Bus client watcher,
generates IDs, handles shutdown procedures.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2713>
It's currently not set by anything, and will only be used by
non-abstract implementations of a future D-Bus interface session
manager. When interface implementations gets ported to this new type,
their MetaDbusSession implementations will set this vfunc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2713>
This means the MetaDbusSession interface takes a more active role
instead of being something that more or less sends signals to the
interface implementor. This will allow better control when using
MetaDbusSession to manage these sessions, instead of their non-abstract
variants.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2713>
Allows for creating LUTs at some fixed size which maintains enough
precision for concatenating or otherwise manipulating the LUT without
having to care about the precision of the hardware.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
If the device supports the atomic API the property based API is used to
write gamma updates and the legacy API is used in the non-atomic case.
The current state is read from the legacy API always though which can be
different from the property API. This commit always uses the correct API
to update the state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
