When memfd_create isn't used, the file isn't sealed. Therefore, we
should skip test_readonly_seals on the fallback case. This fixes
compilation error on FreeBSD 12, which does not support memfd_create.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1229
We were iterating through evcodes, but using API that expects Clutter button
numbers. Instead of transforming those to Clutter numbers to have those translated
back, use the inner seat API that already takes evcodes.
Fixes stuck buttons keys after a virtual device is destroyed while those are
pressed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1239
Move to center uses all monitors for calculating work area.
This can lead to an unexpected behaviour on some monitor
configurations resulting in current window being split between
monitors. We should move window to the center of the active display.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1073
Inhibiting remote access means any current remote access session is
terminated, and no new ones can be created, until remote access is
uninhibited. The inhibitation is ref counted, meaning there can be more
than one inhibitor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1212
When resizing an X11 window with client side decorations, the shadow is
clipped by the frame bounds so that we don't need to paint the shadow
under the opaque areas covered by the window and its frame.
When the X11 client uses the EMWH synchronization mechanism (like all
gtk-3 based clients), the actual window may not be updated so that the
actual window and it frame may be behind the expected window frame
bounds, which gives the impression of de-synchronized shadows.
To avoid the issue, keep a copy of the frame bounds as a cache and only
update it when the client is not frozen so that the clipping occurs on
the actual content.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1178https://gitlab.gnome.org/GNOME/mutter/merge_requests/1214
It takes coordinates in stage coordinate space, and will result in
a screen cast stream consisting of that area, but scaled up by the scale
factor of the view that overlaps with the area and has the highest scale
factor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
Will be used by the stage to not paint the overlays. We skip all
overlays since overlays are only ever used for pointer cursors when the
hardware cursors cannot or should not be used.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
These phase callbacks are not intended to be inovked when something
secondary is painting the stage, such as a screen cast stream, or
similar. Thus, only invoke the callbacks when there is a view associated
with the paint context, which will not be the case for offscreen
painting.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
If there is a paint context available (i.e. for the phases that are
during the actual stage paint), pass it along the callbacks, so that
the callback implementations can change their operation depending on the
paint context state.
This also means we can get the current view from the paint context,
instead of the temporarily used field in the instance struct.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
A paint flag affects a paint operation in ways defined by the flags.
Currently no flags are defined, so no semantical changes are defined
yet. Eventually a flag aiming to avoid painting of cursors is going to
be added, so that screen cast streams can decide whether to include a
cursor or not.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
If drmModePageFlip() or custom_page_flip_func fails, process_page_flip() was
forgetting to undo the ref taken for that call. This would leak page_flip_data.
The reference counting works like this:
- when created, ref count is 1
- when calling drmModePageFlip, ref count is increased to 2
- new: if flip failed, ref count is decreased back to 1
- if calling schedule_retry_page_flip(), it takes a ref internally
- if calling mode_set_fallback(), it takes a ref internally
- all return FALSE paths have an explicit unref
- return TRUE path has an explicit unref
This issue was found by code inspection and while debugging an unrelated issue
with debug prints sprinkled around. I am not aware of any end-user visible
issues being fixed by this, as the leak is small and probably very rare.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1209
When testing a laptop with intel and DisplayLink devices, attempting to set the
DL output as the only active output resulted in GNOME/Wayland freezing. The
main event loop was running fine, but nothing on screen would get updated once
the DL output become the only one. This patch fixes that issue.
DisplayLink USB 3 devices use an out-of-tree kernel DRM driver called EVDI.
EVDI can sometimes fail drmModePageFlip(). For me, the flip fails reliably when
hotplugging the DL dock and when changing display configuration to DL only.
Mutter has a workaround for failing flips, it just calls drmModeSetCrtc() and
that succeeds.
What does not work reliably in the fallback path is Mutter keeping track of the
pageflip. Since drmModePageFlip() failed, there will not be a pageflip event
coming and instead Mutter queues a callback in its stead. When you have more
than one output, some other output repainting will attempt to swap buffers and
calls wait_for_pending_flips() which has the side-effect of dispatching any
queued flip callbacks. With multiple outputs, you don't get stuck (unless they
all fail the exact same way at the same time?). When you have only one output,
it cannot proceed to repaint and buffer swap because the pageflip is not marked
complete yet. Nothing dispatches the flip callback, leading to the freeze.
The flip callback is intended to be an idle callback, implemented with a
GSource. It is supposed to be called as soon as execution returns to the main
event loop. The setup of the GSource is incomplete, so it will never dispatch.
Fix the GSource setup by setting its ready-time to be always in the past. That
gets it dispatched on the next cycle of the main event loop. This is now the
default behavior for all sources created by meta_kms_add_source_in_impl().
Sources that need a delay continue to do that by overriding the ready-time
explicitly.
An alternative solution could have been to implement GSource prepare and check
callbacks returning TRUE. However, since meta_kms_add_source_in_impl() is used
by flip retry code as well, and that code needs a delay through the ready-time,
I was afraid I might break the flip retry code. Hence I decided to use
ready-time instead.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1209
According to the XSetSelectionOwner libX11 documentation:
[...] If the owner window it has specified in the request is later
destroyed, the owner of the selection automatically reverts to None,
but the last-change time is not affected.
This is indeed visible through the selection_timestamp field in
XFixesSelectionNotify events.
Use this to check whether the selection time is recent-ish (thus
likely coming from an explicit XSetSelectionOwner request) and honor
the client intent by setting a "NULL" owner. If the selection time
is too old, it's definitely an indication of the owner client being
closed, the scenario where we do want the clipboard manager to take
over.
This fixes two usecases:
- X11 LibreOffice / WPS clear the selection each time before copying
its own content. Mutter's clipboard manager would see each of those
as a hint to take over, competing with the client over selection
ownership. This would simply no longer happen
- Password managers may want to clear the selection, which would be
frustrated by our clipboard manager.
There's a slight window of opportunity for the heuristics to fail
though, if a X11 client sets the selection and closes within 50ms, we
would miss the clipboard manager taking over.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1206
The X11 selection source was being preserved after unsetting its
ownership. This is no leak as it would be eventually replaced by
another source, or destroyed on finalize. But it's pointless to
keep it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1206
Test the two modes of MetaAnonymousFile, MAPMODE_SHARED and
MAPMODE_PRIVATE and make sure they don't leak data to other FDs when
writing to an FD provided by `meta_anonymous_file_get_fd` even though
the data of both FDs is residing in the same chunk of memory.
We do all the reading tests using mmap instead of read() since using
read() on shared FDs is going to move the read cursor of the fd. That
means using read() once on the shared FD returned by
meta_anonymous_file_get_fd() in MAPMODE_PRIVATE breaks every subsequent
read() call.
Also test the fallback code of MetaAnonymousFile in case `memfd_create`
isn't used for the same issues.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1012
Add MetaAnonymousFile, an abstraction around anonymous read-only files.
Files can be created by calling meta_anonymous_file_new(), passing the
data of the file. Subsequent calls to meta_anonymous_file_open_fd()
return a fd that's ready to be sent over the socket.
When mapmode is META_ANONYMOUS_FILE_MAPMODE_PRIVATE the fd is only
guaranteed to be mmap-able readonly with MAP_PRIVATE but does not
require duplicating the file for each resource when memfd_create is
available. META_ANONYMOUS_FILE_MAPMODE_SHARED may be used when the
client must be able to map the file with MAP_SHARED but it also means
that the file has to be duplicated even when memfd_create is available.
Pretty much all of this code was written for weston by Sebastian Wick,
see https://gitlab.freedesktop.org/wayland/weston/merge_requests/240.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1012
Instead of having everything clumped at MetaWaylandDataManager,
split the primary selection to its own struct. This manager is
handled separately from wl_data_device_manager and other selection
managers, so they would be able to interoperate between them, even.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1193
This is still an openly defined struct, as we will need accessed
by "subclasses". Same principle applies than with the
MetaWaylandDataSource refactor, this is not meant to introduce
functional changes, so just go with it.
On the bright side, the interactions are now clearer, so it could
be made saner in the future.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1193
The split wasn't 100% clean, and some extra private API had to be
added for it (but well, looking at the API, it's already evident
there's a cleanup/streamlining task due). This is meant to be a
refactor with no functional changes, so just go with it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1193
We already have a signal callback that translates selection ownership changes to
data_device/primary .selection events. Given both will be run when a data source
is being replaced, and this event emission being deleted is kinda short sighted
in that in only knows about Wayland, rely entirely on MetaSelection::owner-changed
emission.
Fixes spurious .selection(null) events being sent when a compositor-local source
takes over the selection without the focus changing (eg. screenshot to clipboard).
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1160https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1204
We are meant to send a .cancelled event after the drop is performed
in certain situations, but only for version>3 clients. Since this is
all version 3 business, only set the drop_performed flag for v3
clients. This drops the need to perform version checks at the time
of cancelling (which is present for other usecases in v1).
Fixes emission of wl_data_source.cancelled for v1 clients.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1177https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1203
For the cases where we read a fixed size from the selection (eg. imposing
limits for the clipboard manager), g_input_stream_read_bytes_async() might
not read up to this given size if the other side is spoonfeeding it content.
Cater for multiple read/write cycles here, until (maximum) transfer size is
reached.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
Flushing the X11 selection output stream may happen synchronously or
implicitly, in which case there is not a task to complete. Check there
is actually a task before returning errors. We additionally set the
pipe_error flag, so future operations will fail with an error, albeit
with a more generic message.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
If a write_async() comes up while we are flushing on the background,
the task will be queued, but not deemed a reason on itself to keep
flushing (and finish the task) after a property delete event.
To fix this, do not ever queue up write_async tasks (this leaves
priv->pending_task only used for flush(), so the "flush to end"
behavior in the background is consistent). We only start a
background flush if there's reasons to do it, but the tasks are
immediately finished.
All data will still be ensured to be transfered on flush/close,
this makes the caller in this situation still able to reach to it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
It does not make sense to check for the stream not being closed,
this might happen multiple times during the lifetime of the stream
for a single transfer. We want to notify the INCR transfer just
once.
Check for the explicit conditions that we want, that the remaining
data is bigger than we can transfer at once, and that we are not
yet within the INCR transfer.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
The stream automatically flushes after data size exceeds the
size we deem for INCR chunks, but we still try to copy it all.
Actually limit the data we copy, and leave the rest for future
INCR chunks.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
INCR transfers are mandated to finish with a final 0-size XChangeProperty
roundtrip after the final data chunk. Actually honor this and ensure we
iterate just once more for this.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
This seemed to work under the assumption that a flush() call can
only result in one INCR roundtrip. This is evidently not true, so
we should hold things off until all pending data is actually flushed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
If say we want 32bit data, but have 2 bytes stored, we would simply
ignore flush requests. Allow (and don't clear) the needs_flush flag
if we have less than the element size accumulated.
Instead handle this in can_flush(), so it's triggered whenever we
have enough data to fill 1 element, or if the stream is closing
(seems a broken situation, but triggered by the caller).
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
XMaxRequestSize/XMaxExtendedRequestSize are documented to return
the maximum size in 4-byte units, whereas we are comparing this
to byte lenghts. We can afford 4x the data here.
Since I don't know the payload size of the XChangeProperty request,
be generous and allot 400 bytes for it, we have some to spare.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
When closing the lid of a laptop, we reconfigure all the monitors in order
to update the CRTCs and (if enabled) the global UI scaling factor.
To do this, we try first to reuse the current configuration for the usable
monitors, but if we have only monitor enabled and this one is on the laptop
lid we just end up creating a new configuration where the primary monitor is
the laptop one (as per find_primary_monitor() in MetaMonitorConfigManager),
but ignoring the user parameters.
In case the user selected a different resolution / scaling compared to the
default one, while the laptop lid is closed we might change the monitors
layout, causing applications to rescale or reposition.
To avoid this, when creating the monitors configuration from the current
current state, in case we have only one monitor available and that one is
the laptop panel, let's just reuse this configuration.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1200
Try to bypass compositing if there is a fullscreen toplevel window with
a buffer compatible with the primary plane of the monitor it is
fullscreen on. Only non-mirrored is currently supported; as well as
fullscreened on a single monitor. It should be possible to extend with
more cases, but this starts small.
It does this by introducing a new MetaCompositor sub type
MetaCompositorNative specific to the native backend, which derives from
MetaCompositorServer, containing functionality only relevant for when
running on top of the native backend.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
We need to coordinate with MetaCompositor during pre-paint so that we
have control over whether MetaLater callbacks happen first, or the
MetaCompositor pre-paint logic.
In order to do so, make MetaLater listen to a new signal "pre-paint" on
MetaCompositor, that is called MetaCompositors own pre-paint handling.
This fixes an issue where the top window actor was calculated after the
MetaCompositor pre-paint handling, meaning the top actor being painted
was out-of-date.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Since the order of destruction during MetaDisplay tear down is a bit
unordered, there are pieces that try to destruct its compositing
dependent pieces (i.e. queued MetaLater callbacks) after MetaCompositor
has been cleaned up, meaning we need to put some slightly awkward NULL
checks to avoid crashing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
MetaCompositor is the place in mutter that manages the higher level
state of compositing, such as handling what happens before and after
paint. In order for other units that depend on having a compositor
instance active, but should be initialized before the X11 implementation
of MetaCompositor registers as a X11 compositing manager, split the
initialization of compositing into two steps:
1) Instantiate the object - only construct the instance, making it
possible for users to start listening to signals etc
2) Manage - this e.g. establishes the compositor as the X11 compositing
manager and similar things.
This will enable us to put compositing dependent scattered global
variables into a MetaCompositor owned object.
For now, compositor management is internally done by calling a new
`meta_compositor_do_manage()`, as right now we can't change the API of
`meta_compositor_manage()` as it is public. For the next version, manual
management of compositing will removed from the public API, and only
managed internally.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
While at it, fix some style inconsistencies, for now use a single
singleton struct instead of multiple static variables, and
other non-functional cleanups. Semantically, there is no changes
introduced.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
This will check whether the current backing buffer is compatible with
the primary plane of the passed CoglOnscreen. Since this will extend the
time before a buffer is released, the MetaWaylandBufferRef is swapped
and orphaned if a new buffer is committed before the previous one was
released. It'll eventually be released, usually by the next page flip
callback.
Currently implemented for EGLImage and DMA-BUF buffer types.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Advertising support for modifiers means we will most likely not not be
able to scan out client buffers directly, meaning it just as likely that
we won't be able to scan out even fullscreen windows without atomic KMS.
When we have atomic support, we should advertise support for modifiers
if atomic is used to drive the CRTCs, as we by then can check whether we
can scan out directly, place in an overlay plane, etc.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
While this is fairly incomplete, as to check things fully we need to use
TEST_ONLY in atomic to try out a complete assignment on the device, but
this works well enough for legacy non-modifier cases.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Instead of always swapping buffers and flipping the back buffer, make it
possible to scan out a provided buffer directly without swapping any EGL
buffers.
A buffer is passed as an object implementing the empty CoglScanout
interface. It is only possible to do this in the native backend; and the
interface is implemented by MetaDrmBufferGbm. When directly scanned out,
instead of calling gbm_surface_lock_front_buffer() to get the gbm_bo and
fbid, get it directly from the MetaDrmBufferGbm, and use that to create
the page flip KMS update.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Better to have the relevant object figure out whether it is a good
position to be unredirectable other than the actor, which should be
responsible for being composited.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
This removes the MetaWindowX11::priv pointer. It is replaced with a
meta_window_x11_get_private() helper function, and another method to get
the client rect without going through MetaWindowX11Private.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Surface buffers are created with meta_drm_buffer_new_acquire(), taking a
gbm_surface acquiring the gbm itself, and meta_drm_buffer_new_take()
that takes over ownership of a passed gbm_bo.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Currently a buffer use count always reaches zero before it is replaced.
This is due to the fact that at the point a new buffer is attached, the
last potential user releases it (the stage) since the currently
displayed frame has a composited copy of the buffer.
This may however change, if a buffer is scanned out directly, meaning it
should not be released until the page flip callback is invoked.
Prepare for this by making the buffer reference a heap allocated struct,
enabling us to keep a pointer to it longer than the buffer is attached.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
The CRTC level transform (not necessarily the hw transform) must be
taken into account when calculating the position of the CRTC in the
stage coordinate space, when placing the hw cursor, otherwise we'll
place the cursor as if the monitor was not rotated.
This wasn't a problem in the past, as with rotation, we always used the
OpenGL cursor, so the issue newer showed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1199
The port to per CRTC views was incomplete; we still used the logical
monitor layout as the stage view layout, while still using one view per
CRTC.
This worked fine for most cases, e.g. regular monitors, tiled or
non-tiled, transformed or non-transformed. Where it broke, however, was
when a monitor consists of multiple CRTCs. We already have the layout a
CRTC corresponds to on the stage kept with the CRTC metadata, so use
this directly.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1170https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1199`
The CRTC level transform (i.e. not necessarily the one set on the
hardware) is what is relevant for calculating the layout the CRTC will
have on the stage, so only use the one that can be handled by the
hardware for the CRTC assignment.
This makes the CRTC layout valid for tiled monitors.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1199
Previously the tile coordinate was used to offset a CRTC scanout
coordinate within a larger framebuffer. Since 3.36 we're always
scanning out from (0, 0) as we always have one framebuffer per CRTC; we
instead use the tile coordinate to calculate the coordinate the tile has
in the stage view. Adapt calculation to fulfil this promise instead of
the old one.
This also corrects the tiled custom monitor test case.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1199
test_client_new might return early if conditions are not met, leaving some
allocated data around without freeing it.
Since we're not using the client before, there's no need to initialize it early
and just initialize it when it's going to be returned.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1195
Dereference the loop variable rather than the original list head. This
fixes a regression introduced in 4413b86a3 ("backends: Replace
ClutterDeviceManager usage in favor of ClutterSeat", 2019-10-04) which
broke button scrolling with trackballs.
Closes:https://gitlab.gnome.org/GNOME/mutter/-/issues/1120
Most visible with xwayland-on-demand, at the time of setting things up
for X11 selections, we don't forward the current state. This makes the
first started X11 app oblivious to eg. the current clipboard.
Syncing selections up at the time of initializing the X11 selection
stuff ensures that doesn't happen.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1186
On VT switch, the devices are removed, which means for Wayland disabling
the keyboard.
When the keyboard is disabled, the associated `xkb_state` is freed and
recreated whenever the keyboard is re-enabled when switching back to the
compositor VT.
That means the `xkb_state` for Wayland is lost whereas the same for
clutter is kept, which causes to a discrepancy with locked modifiers on
VT switch.
To avoid that issue, preserve the XKB info only to dispose it when the
keyboard is eventually finalized.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/344https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1185
The motion events of tablets for example need to be mapped on the
selected screen area if the input device is configured to use only a
part of the active logical monitor.
To achieve this behavior each motion event is transformed using the
transformation matrix set for the input device.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1118
At some point we crossed the streams... In a short timespan we had
1f00aba92c merged, pushing WacomDevice to a common parent object,
and dcaa45fc0c implementing device grouping for X11.
The latter did not rely on the former, and just happened to
merge/compile without issues, but would promptly trigger a crash
whenever the API would be used.
Drop all traces of the WacomDevice internal to MetaInputDeviceX11.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1183
Currently we check whether a window is alive everytime it's focused.
This means that an application that doesn't respond to the check-alive
event during startup always showing the "application froze" dialog,
without the user ever trying to interact with it.
An example where this tends to to happen is with games, and for this
particular scenario, it's purely an annoyance, as I never tried to
interact with the game window in the first place, so I don't care that
it's not responding - it's loading.
To avoid these unnecessary particular "app-is-frozen" popups, remove the
alive check from the focus function, and instead move it back to the
"meta_window_activate_full()" call. To also trigger it slightly more
often, also add it to the path that triggers the window focus when a
user actively clicks on the window.
This means that we currently check whether a window is alive on:
* Any time the window is activated. This means e.g. alt-tab or
selecting the window in the overview.
* The user clicks on the window.
Note that the second only works for an already focused window on
Wayland, as on X11, we don't refocus it. This particular case isn't
changed with this commit, as we didn't call meta_window_focus() to begin
with here.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1182
This fixes an issue where a non-maximized screen casted window would be
stretched to fill the whole screen cast stream, instead of just the crop
that corresponds to the current window size.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1174
Picking now only happens on allocated actors, but the
callback in the actor-pick test is not waiting for the
stage to run an allocation cycle. Ideally, we'd wait
for this cycle, but for now, forcing an allocation works
as well.
Allocate the overlay actor in the actor-pick test.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1169
Normally we bail out in `sync_actor_geometry()`. The comment there
states:
```
Normally we want freezing a window to also freeze its position; this allows
windows to atomically move and resize together, either under app control,
or because the user is resizing from the left/top. But on initial placement
we need to assign a position, since immediately after the window
is shown, the map effect will go into effect and prevent further geometry
updates.
```
The signal for the initial sync originates in `MetaWindow` though and predates
`xdg_toplevel_set_maximized`, which again calls `meta_window_force_placement`,
triggering the signal too early. As a result, Wayland clients that start up
maximized have a wrong map animation, starting in the top-left corner.
In order to fix this without changing big parts of the geometry logic and risking
regressions, force the initial sync again before mapping.
Solution suggested by Jonas Ådahl.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1164
IBusInputContext/ClutterInputFocus/GtkIMContext all go for offset+len
for their ::delete-surrounding signals, with offset being a signed int
(neg. to delete towards left of selection, pos. to delete towards right
of selection) and len being an unsigned int from the offset (and
presumably, skipping the current selection).
The text-input protocols however pass in this event two unsigned integers,
one being the length of text to delete towards the left of the selection,
and another the length of text to delete towards the right of the selection.
To translate properly these semantics, positive offsets shouldn't account
for before_length, and negative offset+len shouldn't account for after_length.
The offset/length approach may of course represent deletions that are
detached from the current cursor/selection, we simply delete the whole range
from the cursor/selection positions then.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/517
The input method can assign a negative value to
clutter_input_method_delete_surrounding() to move the cursor to the left.
But Wayland protocol accepts positive values in delete_surrounding() and
GTK converts the values to the negative ones in
text_input_delete_surrounding_text_apply().
https://gitlab.gnome.org/GNOME/mutter/issues/539
