Let's try to consolidate our documentation in doc/ in the repo. This
includes some documentation from README.md, the HACKING.md coding style
and the gitlab wiki.
The README.md file now links to all top-level topics (i.e. not reachable
via other topics).
This also includes a few small changes to make things more consistent.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3465>
This addresses the following race condition:
1. Window+MetaFrame are created non-fullscreen, _MUTTER_FRAME_EXTENTS
is initialized through widget measuring, accounting for frame.
2. Window and MetaFrame become fullscreen.
3. MetaFrameContent gets first size allocation, already fullscreen.
4. Borders were initialized to 0,0,0,0, become set to 0,0,0,0 correctly
reflecting fullscreen, however notify::borders is not emitted.
5. _MUTTER_FRAME_EXTENTS stays accounting for the frame extents.
It sounds sensible to have the borders initialized to a meaningful value,
so account for the first time the border would be set due to the content
being (re)sized, and let this first value trigger notify::borders resulting
in _MUTTER_FRAME_EXTENTS updates.
Since all later _MUTTER_FRAME_EXTENTS changes happen through content
resizes, we only have to cater for this initial handover between the
frame/content initialization paths done through widget measuring and
the later paths done through MetaFrameContent resizes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2937
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3476>
The test makes sure the YCbCr formats create the expected image and we
don't accidentally break it.
Like all wayland tests, this is now part of mutter/wayland, mutter/tty,
and mutter/kvm and will use either shm or dma-buf depending on which
suite is chosen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3371>
Finding the shm offset and shm stride for each plane is the main issue.
The rest is just creating multiple textures for each plane.
One assumption is that shm planes are always contiguous in memory so the
next plane comes directly after the size of the current plane.
The size of a plane is determined by the height and stride. There is
only a single stride parameter for shm buffers but we assume that the
first plane is always non-subsampled which gives us a number of "logical
elements" on one line (stride / bpp of the first plane). The stride of
the other planes is then the number of logical elements devided by the
subsampling factor and multiplied by the bpp of the plane.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3371>
The assumption is that all planes are always contiguous, and we don't
have any multi-plane formats where the first plane is subsampled.
The stride of the entire buffer is then just the stride of the first
plane and the stride of the other planes is derived from that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3371>
Instead of forcing every user of WaylandBuffer to create a listener and
destroy the wl_resource and the WaylandBuffer object, provide a default
listener which does it for the user.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3371>
The texture coordinates of all planes should be the same in theory so
using the coordinates of the first plane works.
The reason for this change is that Cogl somehow doesn't manage to get us
the correct coordinates for the 3rd plane in some circumstances. This is
really a workaround but not wrong in any way.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3176
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3469>
ClutterInputFocus/GtkIMContext uses char based offset for
delete_surrounding, however, text_input_v3 uses byte based offset for
it. Currently only GTK with mutter can work correctly via text_input_v3
because they both forget to convert between char based offset and byte
based offset.
This commit fixes it in mutter by saving committed surrounding text in
MetaWaylandTextInput and converting char based offset to byte based
offset with the UTF-8 encoded surrounding text.
Fixes <https://gitlab.gnome.org/GNOME/mutter/-/issues/2146>.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2712>
Calculating the mipmap width as half of the texture width leads to a
mipmap width of zero for textures with width of 1 which leads to an
early exit instead of a mipmap texture.
Fixes: 16fa2100d ("shaped-texture: Stop using MetaTextureTower and use GL mipmapping instead")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3468>
A surface commit may change the buffer scale but not attach a new
buffer. In that case, the size of the previously attached buffer needs
to be consistent with the new buffer scale.
Fixes: 7649e2f3ab ("wayland/surface: Move buffer size check to meta_wayland_surface_commit")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3466>
meta_wayland_surface_get_buffer_width/height uses the currently applied
buffer, which may have a different size.
Fixes: 7649e2f3ab ("wayland/surface: Move buffer size check to meta_wayland_surface_commit")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3466>
Multiple reasons:
* More consistent with the protocol spec language.
* Ensures the size is checked and the protocol error sent from a
protocol processing context, instead of whatever context
meta_wayland_surface_commit might get called from.
* The latter implies that surface->resource is guaranteed to be valid.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3211
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3463>
Integrate it into the code, instead of depending on MetaDisplay
notify::focus-window for it. Now, instead of focusing explicitly the
stage window, we focus a NULL window, and let the MetaX11Display
determine whether focus should go to the stage window if there's
a focused actor, or the no_focus_window if nothing has focus.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3269>
We currently offer the mechanism for GNOME Shell to implement, and
while this is not exercised often (our entries are typically surrounded
by a ClutterGrab ensuring key events, so this is reserved to grab-less
entries, probably there are some in extensions), this is arguably
something Mutter should cover by itself without GNOME Shell guidance.
This is only necessary on the X11 backend, although it is conceptually
more tied to the MetaX11Display connection, so perform the focus
tracking there only if not running as a Wayland compositor (i.e. --x11).
This avoids the only case where the low-level
meta_x11_display_set_input_focus_xwindow() function is used, or rather
makes it completely a MetaX11Display implementation detail, leaving
only the MetaDisplay API as the high-level entry points to handle
window key focus.
The public API that allowed GNOME Shell to implement these mechanisms
is also gone in this commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3269>
There might not be a single plane that is "for" a CRTC, so remove the
API that made it appear as if it did. The existing users only cared if
there was some plane for said CRTC, so replace the getters with API that
just checks the existance at all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
When there are a set of primary planes, and a set of CRTCs, where each
plane can be used on multiple CRTCs, we need to make sure that when we
mode set and page flip, each CRTC gets assigned an individual plane that
isn't used with any other CRTC.
Do this during the monitor resource assignments that sets up later to be
applied configurations of the mode setting objects, but with the new
hooks into the backend, so that we don't need to teach the monitor
config manager about planes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2398
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
This means that it doesn't necessarily mean what transform / rotation
the hardware resource gets, e.g. it instead represents the logical
transform related to the configured mode. This allows us to postpone
checking the plane capabilities until later (as rotation capabilities
depends is a plane property), when a plane has been assigned.
This was in practice already handled when configuring the
transform-via-offscreen case, handled when creating the view, and the
mode setting configuration.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
When we're configuring monitors, allow backends to add backend specific
assignments during resource assignment (mapping connectors and CRTCs
etc).
This will later allow the native backend's KMS monitor resources to
assign a primary plane and optionally a cursor plane during
configuration. This will then dictate what plane will be used for
primary plane updates, as well as cursor updates, until reconfigured
again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
