The CRTC cursor sprite scale was incorrectly assumed to be always 1.0
when using the default not-scale-monitor-framebuffer mode. This is
harmless in most cases, as most clients provide HiDPI capable cursors,
but for the ones that didn't, we'd end up drawing their cursors
unscaled, when using the cursor planes.
Fix this by using the "texture scale" which is what is intended for
this.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2477
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2698>
Cursor planes tend to be ARGB8888 and support no other format (ideally
we should not hard code this, but un-hard-coding that is for another
day), and if we put e.g. a XRGB8888 buffer in there, it'll either result
in the gbm_bo allocation failing (it doesn't allow USE_CURSOR with any
other format) or mode setting failing if using dumb buffers directly.
In the former case, we'll fall back to OpenGL indefinitely, and in the
latter, we'll have failed mode sets as long as we try to set the invalid
cursor buffer as the cursor plane.
Change things to process all buffers that are not ARGB8888 using the
scale/rotate machinery we already have, turning XRGB8888 into ARGB8888.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2477
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2698>
Attaching a new buffer with a different size than the old one means
that the viewport needs to be recalculated.
Not doing this caused the viewport to be incorrectly applied when
viewport_src_rect remained the same after attaching such buffer.
Pipeline reset usually happens when applying a new viewport,
but it doesn't happen when the viewport values remain the same.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2689>
A client may provide a positioner that places the window outside of its
parent. This isn't allowed, according to spec, so we hide the window and
log a warning. This, however, leads these affected clients with an
incorrect view of what is mapped or not, meaning it becomes harder to
recover.
Fix this by sending xdg_popup.done when we hide the popup due to an
invalid position. Don't error out the client, let the bug slide, as
that's a less jarring experience for existing applications that
reproduce this than being disconnected, which practically feels like a
crash.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2408
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2645>
In constrast to x11, Wayland has sane handling for touch events and
allows the compositor to handle a touch event while the clients are
already seeing it. This means we don't need the REJECTED state on
Wayland, since we can also grab sequences after the client has seen
them.
So disallow moving sequences to the REJECTED state on Wayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2508>
Updating of the paint volume used for culling these days happens
during the finish-layout stage, not while painting. Also we have
geometry-based, not paint-based picking anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1492>
Rename the `last_paint_volume` to `visible_paint_volume`: That avoids
confusion with the `had_effects_on_last_paint_volume_update` flag and
also makes it clear that this paint volume is the currently visible one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1492>
Rename the paint_volume_valid flag to has_paint_volume in order to
better reflect what it's for.
The name "paint_volume_valid" implies that the paint volume can be
invalidated and thus sounds like it's involved with some kind of
caching. The flag that's actually involved with caching is
"needs_paint_volume_update", while "paint_volume_valid" is only meant to
store whether the actor has a paint volume to work with.
So rename paint_volume_valid to has_paint_volume to avoid confusion
about which flag is used for caching.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1492>
For clarity and for further improvements, introduce a separate function
to update the paint volume instead of doing that inside
_clutter_actor_get_paint_volume_mutable().
Also add a FIXME comment for a possible bug I noticed while working on
it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1492>
Since ClutterActor now properly caches its paint volume and ClutterText
tries hard to invalidate its own cached paint volume on every redraw
anyway (that's more often than ClutterActor invalidates its own paint
volume), we can simply rely on the caching of the paint volume done by
ClutterActor and invalidate that on every redraw.
So remove the private cached paint volume from ClutterText and all its
invalidation machinery.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1492>
The function _clutter_paint_volume_get_stage_paint_box() actually
doesn't modify the paint volume that's passed to it, so make that a bit
more clear by passing a const paint volume as the argument.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1492>
These days it's possible to chain up into the default get_paint_volume()
implementation again, which renders
clutter_actor_get_default_paint_volume() unnecessary. So remove that
function and move clutter_actor_update_default_paint_volume() back into
real_get_paint_volume() where it belongs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1492>
When modifiers are enabled on mutter on some of the older i915 systems observed
Black-screen on 2nd monitor during multi-head use cases, upon debugging observed
that disabling modifiers on these systems resolved the Black-screen issue:!1618.
This issue depends whether we have enough DBuf space to provide required bandwidth
for the userspace demands. Those platforms which have less Display Buffer, will
just have more chance to face lack of it. However it still depends on various
factors like amount of planes(i.e the more planes we have, the more we divide the buffer),
refresh rate, bpp and so on.
This affects watermark calculations and the minimum blocks required for at least
wm level 0. If we don't have sufficient ddb at least for wm0 for all planes in
the configuration then it is rejected.
Until we have TEST_ONLY commit solution is built we could make sure to disable
modifiers support on these older i915 systems based on udev rules defined in this commit.
This commit makes sure that modifiers are still usable on latest i915 systems.
List of PCI-IDs are referred from:
f8bf2a9a15/include/pci_ids/iris_pci_ids.h
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/1618
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2641>
It's not really a backend thing, and we'll want to profile e.g. loading
the backend too, so create it very early and destroy it very late and
let MetaContextMain own it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2678>
This change fixes the issue where the cursor is always
embedded in the frames even when the client has requested
the cursor information be sent as metadata in the stream.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2629>
This reverts commit eac227a203.
Currently, Flatpak applications can bypass the X11 permission setting
and access the X server through abstract sockets because X11 authentication
is not enforced for the current user ID.
Fix this by always requiring X11 authentication for Xwayland. This also
means applications without XAUTHORITY set to the file with Mutter's
Xwayland credentials cannot connect to X, including apps launched from
VT or SSH.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2633>
