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
(cherry picked from commit 04d429b743a641c81e2fd8b683a8ec40775b3213)
It does not make sense to notify flushes mid-transfer. We should wait
till the data is actually finished before notifying on the pending
task.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
(cherry picked from commit 0b21dcfe08c9a3ac137da518d6ef5f3a80528883)
This should only be sent if the selection can be sent at once, or
if we are right about to notify on the first chunk of an INCR
transfer.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
(cherry picked from commit 7c939d78c2b20989412a710665cbbea6b12ff8dd)
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
(cherry picked from commit 8a2b82897db66b3edbe985a370429b4f36b9918c)
Together with some other state. We can do this altogether on task
notification, instead of lost somewhere in this function flow.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
(cherry picked from commit e95c365cf01837862f87dea90190b47392ee7f67)
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
(cherry picked from commit 967966cdee13306501eacd3f25791f56d1fc8249)
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
(cherry picked from commit 06d67b6abfd4d5ed8ceecd998b08cd1103946f26)
Commit cda9579034b fixed a corner case when setting the initial workspace
state of transient windows, but it still missed a case:
should_be_on_all_workspaces() returns whether the window should be on all
workspaces according to its properties/placement, but it doesn't take
transient relations into account.
That means in case of nested transients, we can still fail the assert:
1. on-all-workspaces toplevel
2. should_be_on_all_workspaces() is TRUE for the first transient's parent,
as the window from (1) has on_all_workspaces_requested == TRUE
3. should_be_on_all_workspaces() is FALSE for the second transient's
parent, as the window from (2) is only on-all-workspace because
of its parent
We can fix this by either using the state from the root ancestor
instead of the direct transient parent, or by using the parent's
on_all_workspaces_state.
The latter is simpler, so go with that.
https://gitlab.gnome.org/GNOME/mutter/issues/1083
This error was just logged but not raised. Do as the code comment said
and raise a pipe error at that moment, and for subsequent operations
on the output stream (although none besides close() should be expected
after propagating the error properly).
Related: https://gitlab.gnome.org/GNOME/mutter/issues/1065
(cherry picked from commit 2ecbf6d74637508203290c0e324d736de10a9174)
Support for them appears to be way less common than e.g. png, which is
currently the preferred format from Firefox, Chromium, Libreoffice and others.
Adopt to that fact.
As a side effect, this works around a bug observed when copying images in
Firefox on Wayland.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1141
(cherry picked from commit 6aa546145fe614d15f23f2a022637fa72bb50149)
There is a race where an output can be used as a fullscreen target, but
it has already been removed due to a hotplug. Handle this gracefully by
ignoring said output in such situations.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1120
(cherry picked from commit 512bb7d1cd0836e6d110609a16fdbf9f9f5b30df)
It may happen that drmModeGetResources() starts returning NULL. Handle
this gracefully by removing all connectors, CRTCs and planes making the
device in practice defunct.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1121
(cherry picked from commit 5319949a45bb22f5c998b485e955c1ddd13810f3)
Listen for GPU hotplug events to initialize their cursor support.
This fixes one reason for why DisplayLink devices may not be using a hardware
cursor. Particularly, when a DisplayLink device is hotplugged for the first
time such that EVDI creates a new DRM device node after gnome-shell has already
started, we used to forget to initialize the cursor support.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1097
(cherry picked from commit 8abdf16a3992e3332f2378ea7c65e6e251e418e0)
Extract the code to initialize a single GPU cursor support into its own
function. The new function will be used by GPU hotplug in the future.
This is a pure refactoring without any behavioral changes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1097
Backported from 4cc29cfb619102a8e7cd32731205c8018d83544e.
If a data offer comes from an X11 client, the Wayland resource would be
NULL, causing a crash in `data_offer_choose_action()` trying to get the
resource version.
So instead of doing the version check in `data_offer_choose_action()`,
do it early when creating the data source.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1057https://gitlab.gnome.org/GNOME/mutter/merge_requests/1073
(cherry picked from commit f9326cfa3d5f0fd9f63f561d6dfbb92a8f6fb34a)
For clarity, check the resource version needs the "cancelled" message in
the actual vmethod rather than from the caller function.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1073
(cherry picked from commit 963108a9a6a0a3a811945da5354eafe0b86ffde2)
By default clutter will show an actor as it is added to a parent. This
means that after we create the window actor, when it's added to the
window group, we implicitly show it. What we really want is to not show
it until the window is supposed to be shown, which happens when
meta_window_actor_show() is called, as showing prior to that, could
cause issues.
Avoid the implicit show by setting the "show-on-set-parent" property on
the window actor to `FALSE` on window actor construction.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1066
When an X11 window requests an initial workspace, we currently trust
it that the workspace actually exists. However dynamic workspaces
make this easy to get wrong for applications: They make it likely
for the number of workspaces to change between application starts,
and if the app blindly applies its saved state on startup, it will
trigger an assertion.
Make sure that we pass valid parameters to set_workspace_state(),
and simply let the workspace assignment fall through to the default
handling otherwise.
https://gitlab.gnome.org/GNOME/mutter/issues/1029
The actors of Wayland subsurfaces are set to be reactive on creation,
when receiving the `wl_subcompositor.get_subsurface` request.
However, if a client creates several subsurfaces and then creates the
xdg_toplevel object after, the previous subsurface actors are reset.
As a result, Clutter picking will skip and ignore those actors in
`clutter_actor_should_pick_paint()` because they aren't marked as
reactive anymore.
An example of such a client being affected by this issue is SCTK, the
Rust library implementing client side decorations for Wayland used
internally by winit and alacritty.
Move the `set_reactive()` call from `get_subsurface()` to the subsurface
`sync_actor_subsurface_state()` vfunc to make sure those remain reactive
even after `xdg_surface.get_toplevel` is invoked.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1024https://gitlab.gnome.org/GNOME/mutter/merge_requests/1040
(cherry picked from commit 934a829a57d0b00c5eef8d405473e8a56923cd22)
And order those preferences in order of lossiness (jpeg < png < bmp). This
avoids us from prefering other formats that are not useful or widely
recognized.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/939
(cherry picked from commit 832c0fb0ea79d4cf904b1519b11ef0b11cbbfbdc)
Most usually, applications either expose clipboard content either as text
or as images, so the prioritization here is pointless. However there's some
outliers like LibreOffice Calc which exports content as both image and text
formats (besides other internal ones).
In that mixed case, we probably prefer to keep text formats, rather than
image based ones.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/919
(cherry picked from commit 2fbbf657d51f14bdcb75c045637e6ebf4df10063)
Some ClutterOffscreenEffect subclasses, such as ClutterBrightnessContrastEffect,
early-return FALSE in pre-paint before chaining up. It's an important optimization
that avoids creating or updating the offscreen framebuffer.
However, if an offscreen framebuffer already exists by the time pre-paint fails,
it will be used *without* repaint the actor over it. That causes an old picture
of the actor to be displayed.
Fix that by always clearing the offscreen framebuffer when pre-paint fails.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/810https://gitlab.gnome.org/GNOME/mutter/merge_requests/992
(cherry picked from commit 64685f4b20162b78964a5ab6fd57a93fb3860671)
When changing the 'enabled' property and disabling the offscreen effect,
it doesn't make sense to preserve the offscreen framebuffer. It's not
drawing, after all.
Furthermore, because ClutterOffscreenEffect only checks if the offscreen
framebuffer exists to decide whether or not to redraw, keeping the fbo
alive is a waste of resources.
Clear the offscreen framebuffer when the effect is disabled or enabled.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/810https://gitlab.gnome.org/GNOME/mutter/merge_requests/992
(cherry picked from commit bf594e9fb6d973259163f73881dd91c8910dd54f)
Interoperation between wl_data_device_manager v1 and v3 got broken
at some point. Ensure that we resort to the "copy" action if either
the drop site or the drag source are from a client that requested v1.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/965
(cherry picked from commit ffad55c66f5b131cdaa92ef61c44d99b7c7312b5)
Similar to our handling in set_primary(), ignore set_selection() requests
that come from unfocused clients.
https://gitlab.gnome.org/GNOME/mutter/issues/878
(cherry picked from commit e865fcc460d7666873475f7bb9efc7fd4b336ab8)
This function is already checking for the focus surface client
matching the requestor. The type check was slightly bogus though
as it'd be an screwup in our code, make it an assert instead.
Also, move the check for the client having the focus into the
upper call, so this and wl_data_device.set_selection code can
get more in line.
https://gitlab.gnome.org/GNOME/mutter/issues/878
(cherry picked from commit 16eb46105425a9a677c408f5a19e1bebae88a602)
We have an abstract MetaWaylandDataSource and 2 subclasses for
clipboard/primary data sources. Since the abstraction provided
by the additional sublevel is arguable, push the wl_resource
field up, and leave us with just 2 objects to think about, all
of them containing a wl_resource.
https://gitlab.gnome.org/GNOME/mutter/issues/878
(cherry picked from commit c11ef6ef079eeaa8024c8703bbe432356d06388a)
Say you're using intel gen3, you poor soul. Your big-GL maxes out at 1.5
unless you use dirty tricks, but you do have GLES2. We try to fall back
to GLES in this case, but we only ever say eglBindAPI(EGL_OPENGL_API).
So when we go to do CreateContext, even though we think we've requested
GLES 2.0, the driver will compare that "2.0" against the maximum big-GL
version, and things will fail.
Fix this by binding EGL_OPENGL_ES_API before trying a GLES context.
https://gitlab.gnome.org/GNOME/mutter/issues/635
(cherry picket from commit f4f7e31303d78b2a8a0881b61311b8d750301b8f)
This check was added on commit 48639ac5 as a means to disregard
DnD drops where the offer would disappear beforehand. However since
that commit was all about wl_data_device_manager version < 3,
forgetting about the selected mimetype seems a behavior more inline
with those versions.
Since no current drop is something expected on X11 drop sites, fixes
DnD over those, while keeping the original bug fixed.
Found by Robert Mader (https://gitlab.gnome.org/GNOME/mutter/issues/974#note_688144)
https://gitlab.gnome.org/GNOME/mutter/issues/974https://gitlab.gnome.org/GNOME/mutter/merge_requests/1005
(cherry picked from commit 30bf588a38c326897efb8637aad5dfeb0cafe5c9)
In XDND, we just get a hint on XdndPosition about what's the action
chosen by the user. Make the data source actions the full set on
XdndEnter (as we can't know better), and pass the hint in XdndPosition
as the user chosen action as it should be.
Makes Wayland drop sites aware of the user action as per XDND with X11
drag sources, and still makes modifiers during DnD work.
https://gitlab.gnome.org/GNOME/mutter/issues/974https://gitlab.gnome.org/GNOME/mutter/merge_requests/1005
(cherry picked from commit 090a6ad409ce0ea0bcf30b66cb1048dfdb86ab9e)
Leaking a texture object and a framebuffer object every time you update
the secondary GPU is perhaps not the best plan.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1011
(cherry picked from commit 545fcb3dbff00adf1899012524926730a8c23572)
It might be the case that handling an event induces the stream to
trigger completion, hence removing itself from the list. In that
case we would operate on the no longer valid list element to fetch
the next one.
Keep a pointer to the next element beforehand, so we can tiptoe
over streams that did remove themselves.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/869
(cherry picked from commit 45a8806e652346523cb66fb4777e15b63aa90c2a)
The streams were only detached from MetaX11Display (and its event handling)
on completion. This is too much to expect, and those might be in some
circumstances replaced while operating.
Make those streams detach themselves on dispose(), so we don't trip into
freed memory later on when trying to dispatch unrelated X11 selection events.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/869
(cherry picked from commit e1fa0734a9985c06b5a9cbd031d3563ad463904b)
If we end up trying to do a mode set on a DRM state that has already
changed behind our back without us yet having seen the hotplug event we
may fail with `EINVAL`. Since the renderer layer doesn't handle mode set
failure, it'll still try to page flip later on, which will then also
fail. When failing, it'll try to look up the cached mode set in order to
retry the mode set later on, as is needed to handle other error
conditions. However, if the mode set prior to the page flip failed, we
won't cache the mode set, and the page flip error handling code will get
confused.
Instead of asserting that a page flip always has a valid cached mode set
ready to look up, handle it being missing more gracefully by failing to
mode set. It is expected that things will correct themself as there
should be a hotplug event waiting around the the corner, to reconfigure
the monitor configuration setting new modes.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/917https://gitlab.gnome.org/GNOME/mutter/merge_requests/1007
(cherry picked from commit ce3409b2b7f887ca2e83c939ff73ba4d3bc8c4c0)
This avoids using bogus geometric values from an unmapped actor to
determine whether an actor is on a logical monitor or not. This would
happen when committing to a subsurface of a yet to be mapped toplevel.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
(cherry picked from commit 6d15231f10a22ee96f32dee9df8db8296c73376f)
As with most other state that ends up being pushed to the actor and the
associated shaped texture, also push the texture and the corresponding
metadata from the actor surface. This fixes an issue when a toplevel
surface was reset, where before the subsurface content was not properly
re-initialized, as content state synchronization only happened on
commit, not when asked to synchronize.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
(cherry picked from commit f0df07cba3ca308b47c9aefcc8112e8880fd9950)
