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
GObject recommends to break references to other objects on dispose
instead of finalize, also we want to release the pressed virtual buttons
as early as possible if we know the object is getting destroyed.
So release the pressed buttons and unref our virtual
MetaInputDeviceNative when the dispose vfunc is called, which also
allows us to release the buttons immediately from javascript instead of
waiting for the garbage collector by calling run_dispose() on the
object.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1157
This allows us to screencast any window continuously, even
without it being visible. Because it's still being painted,
clients continue to receive frame callbacks, and people
are happy again.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1129
Just like what's done for monitor screencasting. Unfortunately, there's
no mechanism to share fences with PipeWire clients yet, which forces
us to guarantee that a frame is completed after blitting.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1129
MetaScreenCastWindowStreamSrc connects to the "damaged" signal of
MetaWindowActor. This signal is not exactly tied to the paint cycle
of the stage, and a damage may take quite a while to arrive when
a client doesn't want to draw anything. For that reason, the window
screencast can start empty, waiting for a damage to arrive.
Ensure at least one frame is recorded when enabling the window stream.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/1097https://gitlab.gnome.org/GNOME/mutter/merge_requests/1129
cogl_framebuffer_push_rectangle_clip() acts on the current modelview
matrix. That means the result of clipping then translating will be
different of the result of translating then clipping.
What we want for window screencasting is the former, not the latter.
Move the translation code (and associated) to after clipping.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/1097https://gitlab.gnome.org/GNOME/mutter/merge_requests/1129
When calculating the transform we should apply to the cursor sprite
before uploading it to the cursor plane, we must also take into
account non upright mounted LCD panels.
Otherwise the cursor ends up 90 degrees rotated on devices where the
LCD panel is mounted 90 degrees rotated in its enclosure.
This commit fixes this by calling meta_monitor_logical_to_crtc_transform
in get_common_crtc_sprite_transform_for_logical_monitors to adjust the
transform for each Monitor in the LogicalMonitor.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1123https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1153
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
When resizing a window interactively, we'll set a grab operation and a
grab window, among other things. If we're resizing (including setting
initial size, i.e. mapping) another window, that didn't change position,
don't use the gravity of the grab operation when resizing our own
window.
This fixes an issue with jumpy popup position when moving a previously
mapped gtk popover.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/999
The transactional KMS API has been modelled after atomic KMS. Atomic KMS
currently doesn't support forwarding cursor hotspot metadata, thus it
was left out of the transactional KMS API having the user set the simply
create a plane assigment with the cursor sprite assigned to a cursor
plane using regular coordinates.
This, however, proved to be inadequate for virtual machines using
"seamless mouse mode" where they rely on the cursor position to
correspond to the actual cursor position of the virtual machine, not the
cursor plane. In effect, this caused cursor positions to look "shifted".
Fix this by adding back the hotspot metadata, right now as a optional
field to the plane assignment. In the legacy KMS implementation, this is
translated into drmModeSetCursor2() just as before, while still falling
back to drmModeSetCursor() with the plane coordinates, if either there
was no hotspot set, or if drmModeSetCursor2() failed.
Eventually, the atomic KMS API will learn about hotspots, but when
adding our own atomic KMS backend to the transacitonal KMS API, we must
until then still fall back to legacy KMS for virtual machines.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1136
When calculating the resource scale of a clone source, we might end up
in situations where we fail to do so, even though we're in a paint. A
real world example when this may happen if this happens:
* A client creates a toplevel window
* A client creates a modal dialog for said toplevel window
* Said client commits a buffer to the modal before the toplevel
If GNOME Shell is in overview mode, the window group is hidden, and the
toplevel window actor is hidden. When the clone tries to paint, it fails
to calculate the resource scale, as the parent of the parent (window
group) is not currently mapped. It would have succeeded if only the
clone source was unmapped, as it deals with the unmapped actor painting
by setting intermediate state while painting, but this does not work
when the *parent* of the source is unmapped as well.
Fix this by inheriting the unmapped clone paint even when calculating
the resource scale.
This also adds a test case that mimics the sequence of events otherwise
triggered by a client. We can't add a Wayland client to test this, where
we actually crash is in the offscreen redirect effect used by the window
dimming feature in GNOME Shell.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/808https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1147
For HiDPI pointer cursors backed by Wayland surfaces, the hotspot must
be placed using integers on the logical pixel grid. In practice what
this means is that if the client loads a cursor sprite with the buffer
scale 2, and it's hotspot is not dividable by 2, it will be rounded
down to an integer that can. E.g. a wl_surface with buffer scale 2 and a
cursor image with hotspot coordinate (7, 7) will have the coordinate
(3.5, 3.5) in surface coordinate space, and will in practice be rounded
down to (3, 3) as the hotspot position in wl_pointer only takes
integers.
To not potentially shift by 1 pixel on HiDPI monitors when switching
between wl_surface backend cursor sprites and built-in ones, make the
built in one emulate the restrictions put up by the Wayland protocol.
This also initializes the theme scale of the xcursor sprite instances to
1, as they may not have been set prior to being used, it'll only happen
in response to "prepare-at" signals being emitted prior to rendering.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/1092https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1107
We checked that the content size was appropriately painted in the stage,
but didn't take into account that the size of the sampled texture
region, meaning that when stage views were scaled, we'd think that we
would draw a texture scaled, as e.g. a 200x200 sized texture with buffer
scale 2 would have the size 100x100. When stage views were not scaled,
we'd apply a geometry scale meaning it'd end up as 200x200 anyway, thus
pass the check, but when stage views are scaled, it'd still be painted
as a 100x100 shaped texture on the stage, thus failing the
are-we-unscaled test.
Fix this by comparing the transformed paint size with the sampled size,
instead of the paint size again, when checking whether we are being
painted scaled or not. For example, when stage views are scaled, our
200x200 buffer with buffer scale 2, thus content size 100x100 will
transform to a 200x200 paint command, thus passing the test. For
non-scaled stage views, our 200x200 buffer with buffer scale 2 thus
content size 100x100 will also transform into a 200x200 paint command,
and will also pass the check, as the texture sample region is still
200x200.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/804https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1124
A user may have configured an output to be panning, e.g. using xrandr
--output <output> --mode <mode> --panning <size>. Respect this by making
the logical monitor use the panning size, instead of the mode. This
makes e.g. makes the background cover the whole panning size, and panels
etc will cover the whole top of the panned area, instead of just the top
left part covering the monitor if having panned to (0, 0).
No support is added to configuring panning, i.e. a panned monitor
configuration cannot be stored in monitors.xml.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1085
This is so that cogl-trace.h can start using things from cogl-macros.h,
and so that it doesn't leak cogl-config.h into the world, while exposing
it to e.g. gnome-shell so that it can make use of it as well. There is
no practical reason why we shouldn't just include cogl-trace.h via
cogl.h as we do with everything else.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1059
The upper layers (OSDs basically) want to know the monitor that a
tablet is currently assigned to, not the monitor just as configured
through settings.
This broke proper OSD positioning for display-attached tablets since
commit 87858a4e01, as the MetaInputMapper kicks in precisely when
there is no configured monitor for the given device.
Consulting both about the assigned output will make OSDs pop up
again in the right place.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/971
We used to inhibit all pad actions while the OSD is shown, but one we
would actually want to handle are mode switches while the OSD is open.
So it has an opportunity to catch up to the mode switch.
This lets MetaInputSettings reflect the mode switch (eg. when querying
action labels), so the OSD has an opportunity to update the current
actions.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/975
Commit cda9579034 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 class sits between ClutterInputDevice and the backend implementations,
it will be the despositary of features we need across both backends, but
don't need to offer through Clutter's API.
As a first thing to have there, add a getter for a WacomDevice. This is
something scattered across and somewhat inconsistent (eg. different places
of the code create wacom devices for different device types). Just make it
here for all devices, so users can pick.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1109
Most people just see a harmless warning when applying this setting to
all touchpads (which this patch fixes). But tap[-and-drag] is supposed
to remain enabled for display-less Wacom tablets, despite configuration
changes.
Fix this by using the mapping function, so the setting is forced on for
wacom devices. This happens on a per-device basis, so the warning is
gone too.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1145
This fixes a case that was overlooked in
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1036 - when we
have a geometry scale > 1 and Wayland subsurfaces that have an offset
to their parent surface (which is often the case when the toplevel surface
includes decoration/shadows etc.), we have to add extra offset to their
opaque regions so they match their 'visible' location.
This is necessary as `meta_cullable_cull_out_children` moves the coordinate
system during culling, but does not know about geometry scale.
Also, remove the redundant check for `window_actor` - we only hit this code
path if a `window_actor` culls out its children.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1108
Some tablets like the Cintiq 24HDT have several mode switch buttons
per group. Those are meant to jump straight to a given mode, however
we just handle cycling across modes (as most other tablets have a
single mode switch button per group).
So spice up the mode switch handling so we handle multiple mode
switch buttons, assigning each of them a mode. If the device only
has one mode switch button, we do the old-fashioned cycling.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/970
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
When a page flip fails with a certain error code, we've treated this as
a hint that page flipping is broken and we should try to use mode
setting instead.
On some drivers, it seems that this error is also reported when there
was no mode set, which means we'll have no cached mode set to use in the
fallback. The lack of prior mode set tends to happen when we hit a race
when the DRM objects change before we have the time to process a hotplug
event.
Handle the lack a missing mode set in the flip fallback path, with the
assumption that we'll get a hotplug event that'll fix things up for us
eventually.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/917
Both IBus and ClutterInputFocus work in character offsets for the cursor
position in the preedit string. However the zwp_text_input protocol does
define the preedit string cursor offset to be in bytes.
Fixes client bugs in representing the caret within the preedit string,
as we were clearly giving the wrong offset.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/2517https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1132
We send configure events for state changes e.g. for `appears-focused`,
etc. What we don't want to do is to do this for popup windows, as in
Wayland don't care about this state.
When the focus mode was configured to "sloppy focus" we'd get
`appears-focused` state changes for the popup window only by moving the
mouse cursor around, and while a popup may care about focus, it does not
care about related appearance, as there is no such state in xdg_popup.
What these state changes instead resulted in was absolute window
configuration events, intended for toplevel (xdg_toplevel) windows. In
the end this caused the popup to be positioned aginst at (0, 0) of the
parent window, as the assumptions when the configuration of the popup
was acknowledged is that it had received a relative position window
configuration.
Fix this by simply ignoring any state changes of the window if it is a
popup, meaning we won't send any configuration events intended for
toplevels for state changes. Currently we don't have any way to know
this other than checking whether it has a placement rule. Cleaning up
MetaWindow creation is left to be dealt with another day.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/1103https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1122
If the CRTCs the cursor is visible on do not share a common scale
and transform, we can't use the cursor hardware plane as we only have one.
We therefore fall back to software / gl cursor.
The check for that currently happens after we tried to upload the cursor image
to the hardware plane though.
This is made worse by the fact that in the scaling step, where we scale the
cursor image to the desired size, until now we expected a valid common scale -
otherwise scaling the image by an uninitialized float.
Make sure we bail out early during the scale/upload step if we don't have common
scales and transforms - to avoid that bug and save some unnecessary work.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1125
Make sure it is only the special modifier (hardcoded to 1 currently)
which is being pressed (not counting locked modifiers) before notifying
that the special modifier is pressed, as we are interested in it being
pressed alone and not in combination with other modifier keys.
This helps in two ways:
- Pressing alt, then ctrl, then releasing both won't trigger the locate
pointer action.
- Pressing alt, then ctrl, then down/up to switch workspace won't interpret
the last up/down keypress as an additional key on top of the special ctrl
modifier, thus won't be forwarded down to the focused client in the last
second.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/812https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1014
If you first press a key that triggers the "special modifier key" paths
(ctrl, super), and then press another key that doesn't match (yet?) any
keybindings (eg. ctrl+alt, super+x), the second key press goes twice
through process_event(), once in the processing of this so far special
combination and another while we let the event through.
In order to keep things consistent, handle it differently depending on
whether we are a wayland compositor or not. For X11, consider the event
handled after the call to process_event() in process_special_modifier_key().
For Wayland, as XIAllowEvents is not the mechanism that allows clients see
the key event, we can just fall through the regular paths, without this
special handling.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1014
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
To keep consistent and avoid confusion, rename the function:
`meta_window_x11_buffer_rect_to_frame_rect()`
to:
`meta_window_x11_surface_rect_to_frame_rect()`
As this function doesn't deal with the `window->buffer_rect` at all.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1091
The code in `build_and_scan_frame_mask` predates the introduction of the
`MetaShapedTexture` API to get the texture width hand height.
Use the new `meta_shaped_texture_get_width/height` API instead of using
the CoGL paint texture.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1091
For X11 clients running on Wayland, the actual texture is set by
Xwayland.
The shape, input and opaque regions, however are driven by X11
properties meaning that those may come at a different time than the
actual update of the content.
This results in black areas being visible at times on resize with
Xwayland clients.
To make sure we update all the regions at the same time the buffer is
updated, update the shape, input and opaque regions when the texture is
committed from when the Xwayland surface state is synchronized.
That fixes the remaining black areas being sometimes visible when
resizing client-side decorations windows on Xwayland.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1007https://gitlab.gnome.org/GNOME/mutter/merge_requests/1091
For X11 clients running on Xwayland, the opaque, input and shape regions
are processed from different properties and may occur at a different
time, before the actual buffer is eventually committed by Xwayland.
Add a new API `update_regions` to window actor to trigger the update of
those regions when needed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1091
Commit 7dbb4bc3 cached the client area when the client was frozen.
This is not sufficient though, because the buffer size might still be
lagging waiting for the buffer from Xwayland to be committed.
So instead of caching the client size from the expected size, deduce the
client area rectangle from the surface size, like we did for the frame
bounds in commit 1ce933e2.
This partly reverts commit 7dbb4bc3 - "window-actor/x11: Cache the
client area"
https://gitlab.gnome.org/GNOME/mutter/issues/1007https://gitlab.gnome.org/GNOME/mutter/merge_requests/1091
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
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
For every stream src, we created and attached a GSource. Upon stream
src destruction, we g_source_destroy():ed the GSource. What
g_source_destroy() does, hawever, is not really "destroy" it but only
detaches it from the main context removing the reference the context had
added for it via g_source_attach(). This caused the GSource to leak,
although in a detached state, as the reference taken on creation was
still held.
Fix this by also removing our own reference to it when finalizing.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1106
PipeWire will be unable to dequeue a buffer if all are already busy.
This can happen for valid reasons, e.g. the stream consumer not being
fast enough, so don't complain in the journal if it happens.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1115
While we will always have cursor planes, as we'll currently create fake
ones when real ones are missing (See #1058), eventually we will run into
situations where we can't create fake ones, for example for atomic KMS
drivers that don't advertise any cursor planes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1079
If we don't force the placement, we enter the constrain machinery with
the position (0, 0), meaning we always get the "current work area" setup
to correspond to whatever logical monitor was at that position.
Avoid this by doing the same as "meta_window_force_placement()" and set
"window->calc_placement" to TRUE while move-resizing, causing the
move-resize to first calculate the initial position.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/1098https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1110
This commit completes the implementation of `xdg_wm_base` version 3,
which introduces support for synchronized implicit and explicit popup
repositioning.
Explicit repositioning works by the client providing a new
`xdg_positioner` object via a new request `xdg_popup.reposition`. If the
repositioning is done in combination with the parent itself being
reconfigured, the to be committed state of the parent is provided by the
client via the `xdg_positioner` object, using
`xdg_positioner.set__parent_configure`.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
This sets the `is_reactive` flag on the window placement rules, causing
the popups to be reconfigured as they are affected by environmental
changes, such as the parent moving in a way making the popup partially
offscreen.
As with synchronization, the implementation is dormant, as the
version of the advertised global isn't bumped yet, as the new protocol
version is not yet fully implemented.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
This commits adds support on the MetaWindow and constraints engine side
for asynchronously repositioning a window with a placement rule, either
due to environmental changes (e.g. parent moved) or explicitly done so
via `meta_window_update_placement_rule()`.
This is so far unused, as placement rules where this functionality is
triggered are not yet constructed by the xdg-shell implementation, and
no users of `meta_window_update_placement_rule()` exists yet.
To summarize, it works by making it possible to produce placement rules
with the parent rectangle a window should be placed against, while
creating a pending configuration that is not applied until acknowledged
by the client using the xdg-shell configure/ack_configure mechanisms.
An "temporary" constrain result is added to deal with situations
where the client window *must* move immediately even though it has not yet
acknowledged a new configuration that was sent. This happens for example
when the parent window is moved, causing the popup window to change its
relative position e.g. because it ended up partially off-screen. In this
situation, the temporary position corresponds to the result of the
movement of the parent, while the pending (asynchronously configured)
position is the relative one given the new constraining result.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
MetaGravity is an enum, where the values match the X11 macros used for
gravity, with the exception that `ForgetGravity` was renamed
`META_GRAVITY_NONE` to have less of a obscure name.
The motivation for this is to rely less on libX11 data types and macros
in generic code.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
A placement rule placed window positions itself relative to its parent,
thus converting between relative coordinates to absolute coordinates,
then back to relative coordinates implies unwanted restrictions for
example when the absolute coordinate should not be calculated againts
the current parent window position.
Deal with this by keeping track of the relative position all the way
from the constraining engine to the move-resize window implementation.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
To organize things a bit better, put the fields related to the placement
rule state in its own anonymous struct inside MetaWindow. While at it,
rename the somewhat oddly named variable that in practice means the
current relative window position.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
After popup placement rules have gone through the constraints engine has
ended up resulting in an actual move, pass the window configuration down
the path using relative coordinates, as that is what the next layer
(xdg-shell implementation) actually cares about.
In the future, this will also be helpful when the configured position is
not against the current state of the parent.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
A placement rule is always about placing a window relative to its
parent. In order to eventually place it against predicted future parent
positions, make the placement rule processing output relative
coordinates, having the caller deal with turning them into absolute.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
meta_window_wayland_finish_move_resize() inhibited window moves to be
finished if there was a resize grab active at the time, in order to
handle window resizing. Change this to only affect the grabbed window
itself, so that e.g. a popup can be positioned according to a pending
configuration while there is an active resize grab.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
This is made a signal, so the upper layers (read: gnome-shell) may
decide what services to spawn. The signal argument contains a task
that will resume MetaX11Display startup after it is returned upon.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/945
This is used by GDK and the X11 bits, but may also be used for
other initialization services we might need to run along with
Xwayland initialization.
However, as the -initfd argument in Xwayland is a fairly new
feature, add some meson build-time checks so that the feature
is handled transparently while allowing to explicitly set/unset
it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/945
This shape region culling was wrongly implemented in f5a28aa9, as it
does not take frame offsets into account, and is also redundant, as
we already set the opaque region of the underlying surface accordingly.
The other parts were implemented in ac7aa114, the reason given in
the commit message:
```
Wayland clients do this through the opaque region in the surface
actor. However X11 clients were considered fully transparent for
culling purposes, which may result in mutter painting other bits
of the background or other windows that will be painted over in
reality.
```
is wrong though - culling on X11 actors works just fine and did only
not work in Wayland sessions because of a bug that got fixed in
19814497.
In conclusion the whole part appears to be redundand and some testing
done suggests the same. Drop it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1082
If a opaque region is explicitly set we should not consider the surface
opaque, as that implies e.g. a shape region is set.
If no opque region is set but the texture does not have an alpha channel,
we can savely cull it out.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1082
We want sysprof's exact datadir for compatability with
platforms where software is installed into their own
individual immutable prefix's. Such that, mutter's prefix will
never equate to sysprof's. This depends on a MR in sysprof [0]
which adds datadir to its pkgconfig files, as these files will always
have the proper path we want.
This adds version a constraint on sysprof_dep, as datadir was added to
the .pc in this version.
[0]: https://gitlab.gnome.org/GNOME/sysprof/merge_requests/19https://gitlab.gnome.org/GNOME/mutter/merge_requests/957
Given that on Wayland we are pretty much guaranteed to finish MetaX11Display
setup after the MetaCompositor is enabled, we may drop the
meta_compositor_manage() x11 initialization bits, and move them into the
MetaX11Compositor subclass where it's actually needed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/944
We artificially made Xwayland initialization synchronous, as we used
to rely on MetaX11Display and other bits during meta_display_open().
With support for Xwayland on demand and --no-x11, this is certainly
not the case.
So drop the main loop surrounding Xwayland initialization, and turn
it into an async operation called from meta_display_init_x11(). This
function is turned then into the high-level entry point that will
get you from no X server to having a MetaX11Display.
The role of meta_init() in Xwayland initialization is thus reduced
to setting up the sockets. Notably no processes are spawned from here,
deferring that till there is a MetaDisplay to poke.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/944
This ATM completes the task right away, but we will want to do
further things here that are asynchronous in nature, so prepare
for this operation being async.
Since the X11 backend doesn't really need this, make it go on
the fast lane and open the MetaX11Display right away, the case
of mandatory Xwayland on a wayland session is now handled
separately.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/944
With Xwayland initialization going async, these errors will seep
into the parts controlled by g_test*(), resulting in the harmless
errors about DBus names not acquired turned fatal.
Set an error log handler, and specifically ignore those.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/944
It might not be available right on initialization time if X11 is started
asynchronously. As this is a requirement for our tests, ensure it is there
before proceeding with the test.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/944
This used to be set on meta_compositor_manage(), but only if there is a
MetaX11Display. Given meta_display_init_x11() is Wayland only, and we can
always assume compositing to be enabled, just have it invariably set after
the X server is up.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/944
Even though cogl_framebuffer_flush() was supposed to be enough,
it ends up creating streams with odd visual glitches that look
very much like unfinished frames.
Switch back to cogl_framebuffer_finish(), which is admittedly
an overkill, but it's what works for now. There is anedoctal
evidence showing it doesn't incur in worse performance.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1086
Much like monitor streaming, implement window streaming by
making the window actor draw itself with a paint context
that used the passed framebuffer.
Now that all MetaScreenCastStreamSrc subclasses implement
blit_to_framebuffer, remove the conditional check from
meta_screen_cast_stream_src_blit_to_framebuffer().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1086
Implement PipeWire's add_buffer and remove buffer, try and export
a DMA buffer first and, on failure, fallback to memfd.
When DMA buffers are successfully created and shared, blit the
framebuffer contents when drawing instead of downloading the pixels.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1086
Create a new gbm_bo using the same given geometry, and export the new
bo's DMA buffer fd. The new bo lives as long as necessary to be used,
and reused, by PipeWire.
Unfortunately, PipeWire doesn't support modifiers properly, so use the
linear format for now. For now, a hardcoded format of DRM_FORMAT_XRGB8888
is set, so we don't need to negotiate the format with PipeWire early.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1086
If the cursor sprite does not match the scale factor or transformation
of the monintor, we currently fall back to a software cursor, causing
redraws of the shell. This commit implements scaling and transforming
of the cursor sprite, so we can use it with hardware planes, too.
This commit does the following steps:
1. Make sure we reupload the cursor image if the cursor is over
a logical monitor not matching the scale or transform from the previous
update.
2. Before upload to the hardware plane, scale and transform the cursor
image if possible and necessary.
3. Make sure we always use the hardware cursor if possible (only fall
back to software/OGL cursor if it is visible on multiple logical monitors
with differet scales/transforms).
4. Transform or scale the cursor coordinates if necessary.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/526
In Wayland clients can commit transformed surfaces, so the compositor
can directly use them on hardware planes. We already support that
for other surfaces, this is the first step to also support it on
cursor sprites.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/526
This may be used indirectly before creation as we dispatch libinput events
right after creation (to let input devices be known), so those device
additions would trigger the touch-mode checks.
Creating it in advance results in checks being correctly performed, although
redundantly.
Spotted by Bastien Nocera.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1067
When applying a configuration to XRANDR, we first disable CRTCs that
happen to extend outside of the to-be X11 screen size. While doing so,
we fail to actually check whether the CRTC is active or not, meaning
we'll try to query the content of the CRTC configuration even though it
has none, leading to a NULL pointer dereference.
Fix this by simply ignoring non-configured CRTCs.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1093
Instead of users fetching it via `clutter_stage_get_redraw_clip()`, pass
it via the paint context. This is helpful as it is only valid during a
paint, making it more obvious that it needs to be handled differently
when there is no redraw clip (i.e. we're painting off-screen).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
Prior to this commit the stage was drawn separately for each logical
monitor. This allowed to draw different parts of the stage with
different transformations, e.g. with a different viewport to implement
HiDPI support.
Go even further and have one view per CRTC. This causes the stage to
e.g. draw two mirrored monitors twice, instead of using the same
framebuffer on both. This enables us to do two things: one is to support
tiled monitors and monitor mirroring using the EGLStreams backend; the
other is that it'll enable us to tie rendering directly to the CRTC it
will render for. It is also a requirement for rendering being affected
by CRTC state, such as gamma.
It'll be possible to still inhibit re-drawing of the same content
twice, but it should be implemented differently, so that it will still
be possible to implement features requiring the CRTC split.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
To make it more reliable to distinguish between values that are read
from the backend implementation (which is likely to be irrelevant for
anything but the backend implementation), split out those values (e.g.
layout).
This changes the meaning of what was MetaCrtc::rect, to a
MetaCrtcConfig::layout which is the layout the CRTC has in the global
coordinate space.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
On x11 we emulate pointer events from touch events as long as there's
only one touchpoint on screen, this obviously leads to x11 sending us
crossing events triggered by the emulated pointer. Now if we get a leave
event and set the stage of the ClutterInputDevice to NULL, new touch
events will be discarded by clutters backend because the core pointer
doesn't have a stage associated. This means Mutter completely loses
state of a touchpoint as soon as it crosses a shell actor.
An easy reproducer for this issue is to start the four-finger-workspace
gesture above a window and to move the pointer emulating touch outside
of the window, this will freeze the gesture as the gesture no longer
receives touch events.
To fix this, stop tracking stage changes on crossing events and simply
leave the ClutterInputDevice stage as-is. In our case there is only one
stage anyway and that won't change in the future.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/423
Remove the rather useless callback function that's currently used for
handling the "visibility-changed" signal and instead connect to the
signal using `g_signal_connect_swapped()`.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1077
The check-alive feature is there for the user to be able to terminate
frozen applications more easily. However, sometimes applications are
implemented in a way where they fail to be reply to ping requests in a
timely manner, resulting in that, to the compositor, they are
indistinguishable from clients that have frozen indefinitely.
When using an application that has these issues, the GUI showed in
response to the failure to respond to ping requests can become annoying,
as it disrupts the visual presentation of the application.
To allow users to work-around these issues, add a setting allowing them
to configure the timeout waited until an application is considered
frozen, or disabling the check completely.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1080
`meta_xwayland_surface_get_relative_coordinates()` may cause a crash if
the Xwayland surface has no window associated.
That can be observed when using drag and drop from an X11 window to a
Wayland native window:
```
at src/core/window.c:4503
at src/wayland/meta-xwayland-surface.c:200
at src/wayland/meta-wayland-surface.c:1517
at src/wayland/meta-wayland-pointer.c:1048
at src/wayland/meta-wayland-pointer.c:840
at src/wayland/meta-wayland-pointer.c:865
at src/wayland/meta-wayland-pointer.c:954
at src/wayland/meta-wayland-pointer.c:456
at src/wayland/meta-wayland-pointer.c:993
at src/wayland/meta-wayland-data-device.c:1004
at src/wayland/meta-wayland-data-device.c:1278
at src/wayland/meta-xwayland-dnd.c:326
```
Check if the xwayland surface has an associated MetaWindow prior to get
its buffer rect.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1073
The cancellable of a request might already be cancelled by the time
the cancelled_cb is connected resulting in finish_cb being called via
ca_context_cancel before g_cancellable_connect returns. In this case
the request that is written to has already been freed.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/1060
On a Surface Pro 2017, touch-mode is currently only detected correctly
after detaching and attaching the Type Cover (detachable keyboard) once,
it seems that `has_external_keyboard` is only set to the correct value
after MetaSeatNative is initialized.
So fix that and call `update_touch_mode()` once again when the object is
initialized and the `has_external_keyboard` and `has_touchscreen`
properties have been finally updated.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1075
Which offscreens actor rendering only in cases where it hasn't changed for
2 frames or more. This avoids the performance penalty of offscreening an
actor whose content is trying to animate at full frame rate. It will
switch automatically.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1069
It is only useful for clients that do not set an opaque region but
still can be detected as being opaque. This is helpful for X11 clients
as opaque regions only got introduced around 2012 and only as part of EWMH
and are thus not used in many cases.
On Wayland however opaque regions have been part of the core protocol from the
beginnig and we can assume they are used more commonly.
As the current implementation in `MetaWindowActor` does not handle Wayland
subsurfaces well, instead of adding more complexity just move it to
`MetaWindowActorX11`.
While on it, take the shape region into account that is set when clients
use the X Nonrectangular Window Shape Extension Protocol, so we have exact
culling with those clients.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1058
Allow screen casters (e.g. VNC remote desktop services) to ask for
animations to be inhibited, in order to lower the number of frames sent
over the network.
Currently only sets a field on the screen cast session object. Later
it'll be exposed via the remote access handle and via D-Bus by
gnome-shell.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/838
There are two surface roles owning a MetaWindow: MetaWaylandShellSurface
(basis of MetaWaylandXdgToplevel, MetaWaylandXdgPopup,
MetaWaylandWlShellSurface, etc), and MetaXwaylandSurface.
With these two role types, the MetaWindow has two different types of
life times. With MetaWaylandShellSurface, the window is owned and
managed by the role itself, while with MetaXwaylandSurface, the
MetaWindow is tied to the X11 window, while the Wayland surface and its
role plays more the role of the backing rendering surface.
Before, for historical reasons, MetaWindow was part of
MetaWaylandSurface, even though just some roles used it, and before
'wayland: Untie MetaWindowXwayland lifetime from the wl_surface' had
equivalent life times as well. But since that commit, the management
changed. To not have the same fied in MetaWaylandSurface being managed
in such drastically different ways, rearrange it so that the roles that
has a MetaWindow themself manages it in the way it is meant to; meaning
MetaWaylandShellSurface practically owns it, while with Xwayland, the
existance of a MetaWindow is tracked via X11.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
The role determines how a relative coordinate is calculated. More
specifically, using clutters API to transform coordinates is only
accurate right after a clutter layout pass but this function is used
e.g. to deliver pointer motion events which can happen at any time. This
isn't a problem for Wayland clients since they don't control their
position, but X clients do and we'd be sending outdated coordinates if a
client is moving a window in response to motion events.
This was already done already, but now move the Xwayland specific logic
to the Xwayland surface role, keeping the generic transformation logic
in the generic actor surface role.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
The shell surface role is the one where subsurfaces may exist, and it
has direct relation to the MetaWindowActorWayland which currently has
the subsurface stacking logic.
Instead of directly finding the window actor when dealing with
subsurfaces, notify the parent surface that the subsurface state
changed, so that it can outsource the application of this information to
the role. For subsurface roles, this simply means forward upward to the
parent; for shell surface roles, this means regenerate the surface actor
layering.
This allows us to move away from accessing the window directly from the
surface, which in turn allows us to change the ownership structure of
windows.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
If a window already is being pinged, it doesn't make sense to send more
pings to the window, instead we should just wait for that answer or
timeout until we send a new one.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/891
Using a timestamp twice in a row (e.g. when activating two windows in
response to the same event or due to other bugs) will break the window
detection and show a close dialog on the wrong window. This is a grave
error that should never happen, so check every timestamp before sending
the ping for uniqueness and if the timestamp was already used and its
ping is still pending, log a warning message and don't send the ping.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/891
Increase the number of checks whether a window is still responsive and
ping windows on every call to `meta_window_focus()` instead of
`meta_window_activate_full()`. This ensures the window is also pinged in
case normal interaction like clicks on the window happen and a close
dialog will eventually get shown.
Related https://gitlab.gnome.org/GNOME/mutter/issues/395https://gitlab.gnome.org/GNOME/mutter/merge_requests/891
Currently when a window is requested to be unredirected, the
corresponding pixmap and texture can get cleared before the window has
been unredirected by the X server. This can result in the windows behind
showing through which causes a short flicker after showing an OSD or
notification when a fullscreen application is running.
Fix this by ensuring the texture is only cleared after the window has
been unredirected by the server.
Similarly when the window is being redirected again, the pixmap of the
window can only be requested after the redirection has been completed by
the server. This currently can happen in a different frame than the next
redraw of the actor resulting in an empty texture until the next redraw.
Fix this by queuing a redraw immediately after redirecting.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/997
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
We didn't log what we enabled, just g_info():ed what failed to be
enabled. Change this to g_warning() what failed to be enabled, and
g_message() on what was enabled, so that both will be visible in the
logs.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1061
We preserve the core one, which represents the union of all input
devices. It might make sense to make this per-seat in the future,
but certainly the per-device granularity is unused (at last!) and
useless.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1039
XWayland clients get their opaque region set from their window, not the
surface. Doing both resulted in the surface constantly overwriting the
opaque region - effectively disabling culling of XWayland clients.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1049
Devices have capabilities that other parts need to know about. Instead
of having them probe using drmMode* API, outsource this to
MetaKmsDevice. Currently the only capability tracked is HW cursor size.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
Turns the cursor setting and movement into cursor plane assignment
primitives. In the current simple implementation, this in turn
translates into legacy drmModeSetCursor() and drmModeMoveCursor() calls.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
A cursor plane can now be assigned, and for the simple KMS
implementation, it'll translate into drmModeSetCursor() and
drmModeMoveCursor() calls.
When assignments failed, the cursor planes that failed to be assigned
are communicated via the feedback object.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
The current API as all synchronous, so they can be made to return
feedback immediately. This will be needed for the cursor renderer which
needs to know whether it should fall back to OpenGL cursor rendering.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
meta_kms_update_process_..() makes it sound like it's a MetaKmsUpdate
function called update_..() but in fact it's a MetaKms function that
calls the corresponding process-update impl function. Clear up this
naming confusion.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
The frame bounds as returned by `meta_window_actor_get_frame_bounds()`
would be used as cropping values when streaming a window content.
But, as its name implies, it returns the actual frame bounds, whereas we
may want to include the whole buffer, to include client side shadows for
example.
Rename the `get_frame_bounds()` API to `get_buffer_bounds()` (which was
previously partly removed with commit 11bd84789) and return the actual
buffer bounds to use as the cropping area when streaming a window.
Fixes: 931934511 - "Implement MetaScreenCastWindow interface"
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1022
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1018
The clip bounds passed in `meta_window_actor_capture_into()` represent
the actual allocated buffer size where the window actor image will be
eventually copied.
As such, it is completely agnostic to the scaling factors that might
affect the different surface actors which compose the window actor.
So instead of trying to compute the scale factor by which the given
clipping bounds need to be adjusted, simply clip the resulting image
based on the given bounds to make sure we never overflow the destination
buffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1022
This taps on:
1) Touchscreen availability
2) Availability of external keyboards
3) Tablet mode switch, if existent
So we get this property enabled whenever it makes sense to show touch
focused features (eg. the OSK).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1044
During compilation, gen_default_modes.py shows two warnings that
say that a comparison is using 'is' instead of '=='.
This patch fixes this bug.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/985
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
Some cullable implementation may have extra information about their
expected size. The main example here are surface actors which can be scaled
by geometry scale.
Add an API to overwrite the default size / untransformed check for such cases.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1036
The local copy of the clip- and unobscured region are used to optimize
painting. To get correct results when the actor is scaled, thus "grows",
the corresponding regions have to "shrink", i.e. get scaled down.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1036
Modify create_for_builtin_display_rotation to lookup the
MetaLogicalMonitorConfig for the panel in the logical_monitor_configs
list instead of only working when there is only 1 monitor.
The goal of this change is to honor accelerometer value changes when there is
more than 1 monitor.
Note, since create_for_builtin_display_rotation is also used for handling the
"rotate-monitor" hotkey and this commit modifies the common path of
create_for_builtin_display_rotation this means that we will now also honor
"rotate-monitor" hotkey keypresses when there is more than 1 monitor and
update the builtin display rotation instead of ignoring "rotate-monitor"
hotkey keypresses when there is more than 1 monitor. If this is deemed
undesirable this is easy to fix, but I believe that doing things this way
is more consistent.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/959
Add a clone_logical_monitor_config_list helper function for making a deep
copy of MetaLogicalMonitorConfig lists.
This is a preparation patch for honoring accelerometer value changes when
there is more than 1 monitor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/959
When creating a new config because of a monitor being (un)plugged or
because of super+p being pressed, honor the orientation reported by
the accelerometer for the internal panel.
Before this commit we would always configure the internal panel with
a normal / upright transform when e.g. an external monitor gets plugged
in even if another transform was in use before plugging in the external
monitor. This is inconsistent and causes problems for several use-cases.
This commit fixes this by querying the accelerometer when creating a new
config for an internal panel.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/707
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/924https://gitlab.gnome.org/GNOME/mutter/merge_requests/959
Bail out of sync_state() immediately if the orientation is locked, before
calling read_iio_prox() which updates the curr_orientation value.
There are 2 reasons for this change:
1. Currently meta-monitor-config-manager.c always assumes normal / upright
orientation when generating a new config. This means that e.g. when an
external monitor gets plugged in the builtin panel's transform will be reset
to normal / upright even if the device is not in an upright orientation.
To fix this meta-monitor-config-manager.c needs to call
meta_orientation_manager_get_orientation() to get the current orientation
when generating a new config. Without this change locking the orientation
would stop the emitting of "orientation-changed" signals but we would
still update the curr_orientation value. So when a new config needs to
be generated the latest orientation would be used, effectively ignoring
the "orientation-lock" setting, not updating curr_orientation when
locked fixes this.
2. This ensures we properly emit an an "orientation-changed" signal when
the orientation has changed between when it was locked and it was
unlocked. Before this change if the user locked the orientation, changed it
and then unlocked it, no signal would be raised as we would already have
updated the curr_orientation value turning the sync_state() call in
orientation_lock_changed() into a no-op.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/959
Using `-Dnative_backend=false` caused build failure due to a missing
(implicit) definition of `META_IS_BACKEND_X11`. But if we define it
properly then that just leaves some of the function's locals uninitialized
and it will never work anyway. Just return unconditionally if there's no
native backend to initialize the variables.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1025
Scaling the `monitor_area` before texture creation was just wasting
megabytes of memory on resolution that the monitor can't display. This
was also hurting runtime performance.
Example:
Monitor is natively 1920x1080 and scale set to 3.
Before: The monitor texture allocated was 5760x3250x4 = 74.6 MB
After: The monitor texture allocated is 1920x1080x4 = 8.3 MB
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2118https://gitlab.gnome.org/GNOME/mutter/merge_requests/1004
When creating a virtual device for the native backend, no "device-added"
is emitted.
Similarly, no "device-removed" signal is emitted either when the virtual
device is disposed.
However, the backend plugs into the "device-added" signal to set the
monitor device. Without the "device-added" signal being emitted, the
monitor associated with a virtual device remains NULL.
That later will cause a crash in `meta_idle_monitor_reset_idlettime()`
called from `handle_idletime_for_event()` when processing events from a
virtual device because the device monitor is NULL.
Make sure to emit the "device-added" signal when creating a virtual
device, and the "device-removed" when the virtual device is disposed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1037
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
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
The devices_by_id hash table is responsible for managing the reference
to the devices. In remove_device however, for non-core devices there are
additional calls to dispose/unref, after the last reference has
already been dropped by the hash table.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1032
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
MetaX11SelectionOutputStream was storing copies of strings only to use
them in init and then free them in finalize. This was also causing a
small leak, because one of these strings was not freed. Instead of doing
that just don't create these unnecessary copies in the first place.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1001
e9fbbd5853 changed meta_backend_get_idle_monitor() to use
ClutterInputDevice pointers instead of device IDs, but did not adjust
the call in meta_backend_native_resume() which was still using 0 to get
the core idle monitor resulting in a NULL pointer dereference.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1029
The meta_seat_native_constrain_pointer() function receives the current
pointer position, and the new pointer position as in/out parameters.
We were however calculating the new coordinates based on the last pointer
position if there was no pointer constrain in place.
Fortunately to us, this didn't use to happen often/ever, as a pointer
constrain function is set on MetaBackend initialization. This behavior
did also exist previously in MetaDeviceManagerNative.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1028
The backend being initialized triggers a pointer warp (and motion event)
where we want to observe the callbacks put in place. So ensure we set
up the hooks before that could happen.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/852
Just go ATM through backend checks, and looking up directly the
native event data, pretty much like the rest of the places do that...
Eventually would be nice to have this information in ClutterEvent,
but let's not have it clutter the MetaBackend class.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/852
This is unlikely to happen, and unlikely to be right (eg. we don't translate
input event coordinates, since those are not in display coordinate space, we
don't offer any feedback for those either).
This can simply be dropped, we listen to XIAllMasterDevices, which suffices
for what we want to do.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/852
When a Wayland window is mapped or unmapped, the Wayland compositor is
expected to send the coorespoindign `wl_pointer` enter/leave events to
the affected clients.
To do so, mutter calls `meta_wayland_compositor_repick()` which
eventually calls `meta_wayland_pointer_repick()` and
`repick_for_event()`.
If pointer input device has not been updated yet, the old clutter actor
is picked and no enter/leave event is emitted.
Make sure we update the pointer input device prior to do the repick to
get the actual `ClutterActor` under the pointer.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1016https://gitlab.gnome.org/GNOME/mutter/merge_requests/1026
As we now call `meta_wayland_compositor_repick()` when the effects are
complete for Wayland surfaces, we can safely remove the Wayland specific
code to do the same from `meta_window_show()`.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1026
When mapping/unmapping windows, an animation may be played which can
change the actual actor size and location, hence defeating picking if
done too early.
Make sure we repick when the affects are completed, once the actor is
sized and placed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1026
When building the frame mask, the current reported frame size may not
match when is actually on screen if the buffer has not been updated
yet.
So instead of getting the frame size from the meta window, deduce it
from the texture size.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1009
Currently, `meta_frame_get_mask()` and `meta_ui_frame_get_mask()` will
return the frame mask applied to the current frame size, by querying the
frame themselves.
To be able to get the frame mask at an arbitrary size, change the API to
take a rectangle representing the size at which the frame mask should be
rendered.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1009
With Xwayland, the shape region is recomputed and reapplied even when
the actor is frozen to prevent the black shadows effect.
However, while recomputing the shape region, the current client size is
taken into account, rather than the size when the client was frozen,
which is ahead of the actual client size using the NET_WM_SYNC protocol.
Keep the current client area and to reuse them when the X11 window actor
is frozen for rebuilding the client mask texture.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1009
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
The gamma value pointers of the current_state are overwritten by the
calls to memdup causing a small leak. while the leak itself is small, it
can be triggered quite often from things like night light.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1020
The acked configuration is removed from the pending configuration list
by acquire_acked_configuration(), but finish_move_resize() does not free
the data after applying the configuration.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1020
Where possible, try to export the buffer rendered by the primary GPU as a
dmabuf and import it to the secondary GPU and turn it into a DRM FB for
scanout. If this works, we get a zero-copy path to secondary GPU outputs.
This is especially useful on virtual drivers like EVDI (used for DisplayLink
devices) which are not picky at all about what kind of FBs they can handle.
The zero-copy path is prioritised after the secondary GPU copy path, which
should avoid regressions for existing working systems. Attempting zero-copy
would have the risk of being less performant than doing the copy on the
secondary GPU. This does not affect the DisplayLink use case, because there is
no GPU in a DisplayLink device.
The zero-copy path is prioritised before the primary GPU and CPU copy paths. It
will be tried on the first frame of an output and the copy path is executed
too. If zero-copy fails, the result from the copy path will take over on that
frame. Furthermore, zero-copy will not be attemped again on that output. If
zero-copy succeeds, the copy path is de-initialized.
Zero-copy is assumed to be always preferable over the primary GPU and CPU copy
paths. Whether this is universally true remains to be seen.
This patch has one unhandled failure mode: if zero-copy path first succeeds and
then fails later, there is no fallback and the output is left frozen or black.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
With all the three paths this is quite a handful of code, and it was mostly
duplicated in two places. A follow-up patch would need to introduce a third
copy of it. Therefore move the code into a helper function.
There are two behavioral changes:
- The format error now prints the string code as well, because it is easy to
read.
- The g_debug() in init_dumb_fb() is removed. Did not seem useful.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
There will be another place where I need to release the dumb buffers but not
destroy the whole secondary_gpu_state, so extract this bit of code into a
helper.
The checks of fb_id are dropped as redundant with the check already in in
release_dumb_fb ().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
release_dumb_fb () checks 'map' to see if anything needs freeing. Other places
are checking fb_id instead. The checks maybe redundant, but let's reset all
fields here while at it, so that all the checks work as expected.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
Simplify the bo freeing functions by not checking what the copy mode is. This
matches what swap_secondary_drm_fb () already does. g_clear_object () is safe
to call even if the value is already NULL.
The copy mode does not change mid-operation. If it did, this change would
ensure we still clean up everything. So this is more future-proof too.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
To mirror what happens in meta_onscreen_native_swap_buffers_with_damage(), warn
here too if next_fb is not NULL. This makes it clear to the reader of what the
expectations are inside this function.
Ensuring next_fb is NULL as the first thing in the function will make all error
paths equal: no longer some failures reset next_fb while others don't. Removing
such special cases should reduce surprises.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
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
On Xwayland, freezing actor updates on sync requests means the
server-side frame and shadows repaint will be frozen as well, which
causes the shadow to show black at times when resizing X11 clients
which support NET_WM_SYNC.
Using freeze/thaw commits prevents the content from changing, yet the
shape window still needs to be updated when frozen otherwise the
difference in shape induced by the on-going resize operation will show
as well, even if the toplevel window has its commits frozen.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
Closes: https://bugzilla.gnome.org/show_bug.cgi?id=767212
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/858
To address the black shadows that sometimes show during resize with
Xwayland, we need to update the window shape regardless of the frozen
status of the window actor.
However, plain Xorg does not need this, as resized windows do not clear
to black, so add a new vfunc to window/x11 to indicate whether or not
the backing windowing system (either plain X11 or Xwayland) would
require the shape to be always updated.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
Currently, the window actor freeze/thaw implementation sets the frozen
state of the surface actor using `meta_surface_actor_set_frozen()`.
If we want to expand that behavior to also freeze/thaw commits for X11
windows running on Xwayland, we need to have a specific vfunc to abstract
that in the window actor specific implementation.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
To make sure the frame is painted before the commits are thawed, freeze
the commits when invalidating the GDK window, only to thaw to it after
the actual frame draw is performed or the frame is destroyed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
Make sure we freeze commits before resizing the window as this will
clear the frame to black.
Set the "thaw on paint" flag so that the post paint for window actor X11
can then thaw the freeze initiated prior to the resize and keep the
freeze/thaw balanced.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
To be able to thaw commits following a resize that might have frozen
commits, to keep freezes and thaws even, we need a way to tell whether
a repaint should also thaw commits.
Add a flag to `MetaWindowX11` and the appropriate functions to set and
query it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
Xwayland may post damages for an X11 window as soon as the frame
callback is triggered, while the X11 window manager/compositor has not
yet finished updating the windows.
If Xwayland becomes compliant enough to not permit updates after the
buffer has been committed (see [1]), then the partial redraw of the X11
window at the time it was posted will show on screen.
To avoid that issue, the X11 window manager can use the X11 property
`_XWAYLAND_ALLOW_COMMITS` to control when Xwayland should be allowed to
post the pending damages.
Add `freeze_commits()` and `thaw_commits()` methods to `MetaWindowX11`
which are a no-op on plain X11, but sets `_XWAYLAND_ALLOW_COMMITS` on
the toplevel X11 windows running on Xwayland.
[1] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/316
See-also: https://gitlab.gnome.org/GNOME/mutter/merge_requests/855https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
At the moment we only disarm the watchdog timer set up for SYNC counter
requests if we're in the middle of a resize operation.
It's possible that the resize operation finished prematurely by the user
letting go of the mouse before the client responded. If that happens, when the
client finally updates mutter will erroneously still have the watchdog timer
engaged from before until it times out, leading to resizes for the next second
or so to not get processed, and the client to get blacklisted from future sync
requests.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
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
Without 'wayland/surface-actor: Reset and sync subsurface state when
resetting' this test would fail.
This also adds a simple framework for testing lower level Wayland
semantics.
In contrast to the test-client and test-driver framework, which uses
gtk and tests mostly window management related things, this framework is
aimed to run Wayland clients made to test a particular protocol flow,
thus will likely consist of manual lower level Wayland mechanics.
A private protocol is added in order to help out clients do things they
cannot do by themself. The protocol currently only consists of a request
meant to be used for getting a callback when the actor of a given
surface is eventually destroyed. This is different from the wl_surface
being destroyed due to window destroy animations taking an arbitrary
amount of time. It'll be used by the first test added in the next
commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
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
A actor surface may be reset by an xdg_toplevel if a NULL buffer is
attached. This should reset the actor state of the toplevel to an empty
state, while unmapping the previous actor. Subsurfaces, however, should
stay intact, including their relationship to the toplevel. They should
also not be yanked away from the actor of the actor surface prior to it
resetting, so that a window-destroy animation can include the subsurface
actor.
This fixes a potential crash when a subsurface tries to commit to its
wl_surface after the destroy animation of the toplevel has finished, as
the actor would at that point have been destroyed and cleared from the
actor surface struct, causing a segmentation fault.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
Similar to wl_list_foreach(), add
META_WAYLAND_SURFACE_FOREACH_SUBSURFACE() that iterates over all the
subsurfaces of a surface, without the caller needing to care about
implementation details, such as leaf nodes vs non-leaf nodes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
While it's not very relevant now, as we would rarely create it anyway
since the buffer nor texture never changes for a surface, it will be in
the future, as the actor state (including its content,
MetaShapedTexture) will be synchronized by the MetaWaylandActorSurface
at a later point in time, and not by MetaWaylandSurface, at state
application time.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
The method `relative_motion_across_outputs` is used to adjust the
distance/delta of a mouse movement across multiple monitors to take the
different scale factors of those monitors into account. This works by
getting the adjacent monitors that the movement-line/vector intersects
with and adjusting the final position (or end point of the
movement-line) by multiplying the parts of the line spanning across
different monitors with the scale factors of those monitors.
In the end of this calculation, we always want to set the new end
coordinates of the relative motion to the new end coordinates of the
adjusted movement-line. We currently only do that if all adjacent
monitors the line is crossing actually exist, because only then we end
up inside the "We reached the dest logical monitor" else-block and set
`x` and `y` to the correct values. Fix that and make sure the returned
values are also correct in case an adjacent monitor doesn't exist by
adding separate `target_x` and `target_y` variables which we update during
each pass of the while loop so we're always prepared for the while loop
exiting before the destination monitor was found.
Thanks to Axel Kittenberger for reporting the initial bug and tracking
the issue down to `relative_motion_across_outputs`.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/774
Touch-wise, those are essentially giant touchpads, but have no buttons
associated to the "touchpad" device (There may be pad buttons, but
those are not mouse buttons).
Without tap-to-click/drag, touch in those devices is somewhat useless
out of the box. Have them always enable these features, despite the
setting.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/968
From `meta_cullable_cull_out`:
```
Actors that may have fully opaque parts should also subtract out a region
that is fully opaque from @unobscured_region and @clip_region.
```
As we do no check for the intersection of these two elsewhere in the code,
let's substract from the clip region, too.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/985
Using the same scale for the window as the
logical monitor only works correctly when having
the experimental 'scale-monitor-framebuffer'
feature enabled.
Without this experimental feature, the stream
will contain a black screen, where the actual
window only takes a small part of it.
Therefore, use a scale of 1 for the non-
experimental case.
Patch is based on commit 3fa6a92cc5.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/976
'xwayland: Do not queue frame callbacks unconditionally' changed the
frame callback behavior of Xwayland surfaces so that they behave the
same way as other actor surfaces (e.g. xdg-shell ones), except for the
case when they are initially assigned.
Remove this special casing as well including the now incorrect comment,
so that the Xwayland surfaces behave the same as the others in this
regard also when assigning.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/964
The vfunc is not called when a surface commits its state, but when the
state is applied. Make this clearer by changing the name to
"apply_state" (and "pre_apply_state").
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
This changes how asynchronous window configuration works. Prior to this
commit, it worked by MetaWindowWayland remembering the last
configuration it sent, then when the Wayland client got back to it, it
tried to figure out whether it was a acknowledgment of the configuration
or not, and finish the move. This failed if the client had acknowledged
a configuration older than the last one sent, and it had hacks to
somewhat deal with wl_shell's lack of configuration serial numbers.
This commits scraps that and makes the MetaWindowWayland take ownership
of sent configurations, including generating serial numbers. The
wl_shell implementation is changed to emulate serial numbers (assuming
each commit acknowledges the last sent configure event). Each
configuration sent to the client is kept around until the client one. At
this point, the position used for that particular configuration is used
when applying the acknowledged state, meaning cases where we have
already sent a new configuration when the client acknowledges a previous
one, we'll still use the correct position for the window.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
In Wayland, window configuration is asynchronous. Window geometry is
constrained, the constrained geometry is sent to the client, and the
client will adapt its surface and acknowledge the configuration. When
acknowledged, we shouldn't reconstrain again, as that may invalidate the
constraint calculated for the configured size.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
Historically, wl_shell clients used to pretend the input region was
equivalent to the window geometry, so for "correctness" lets do that
here too. This makes wl_shell clients with drop shadow behave marginally
better than before.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
This moves the cached subsurface surface state into the generic
MetaWaylandSurface namespace. Eventually it'll be used by other surface
roles which as well aim to implement synhcronization.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
The name didn't communicate it was about surface state, and it somewhat
confusingly had the name "pending" in it, which could be confused with
the fact that while it's used to collect pending state, it's also used
to cache previously committed pending state.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
With the eventual aim of exposing the internals of MetaWaylandSurface
outside of meta-wayland-surface.c, make users of the pending state use a
helper to fetch it. While at it, rename the struct field to something
more descriptive.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
The intention of meta_window_wayland_move_resize() is to finish a
move-resize requested previously, e.g. by a state change, or a
interactive resize. Make the function name carry this intention, by
renaming it to meta_window_wayland_finish_move_resize().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
Presumably this function is supposed to be like
meta_kms_impl_simple_handle_page_flip_callback() but the condition in the
if-statement is inverted. Fix the inversion to make these two functions look
alike.
This is part 2 of 2 fixing a complete desktop freeze when drmModePageFlip()
fails with EINVAL and the fallback to drmModeSetCrtc() succeeds but the success
is not registered correctly as completed "flip". The freeze occurs under
wait_for_pending_flips() which calls down into meta_kms_impl_device_dispatch()
which ends up poll()'ing the DRM fd even though drmModeSetCrtc() will not
produce a DRM event, hence the poll() never returns. The freeze was observed
when hotplugging a DisplayLink dock for the first time on Ubuntu 19.10.
This patch makes meta_set_fallback_feedback_idle() actually end up calling into
notify_view_crtc_presented() which decrements
secondary_gpu_state->pending_flips so that wait_for_pending_flips() can finish.
CC stable: gnome-3-34
https://gitlab.gnome.org/GNOME/mutter/merge_requests/953
mode_set_fallback() schedules a call to mode_set_fallback_feedback_idle(), but
it is possible for Mutter to repaint before the idle callbacks are dispatched.
If that happens, mode_set_fallback_feedback_idle() does not get called before
Mutter enters wait_for_pending_flips(), leading to a deadlock.
Add the needed interfaces so that meta_kms_device_dispatch_sync() can flush all
the implementation idle callbacks before it checks if any "events" are
available. This prevents the deadlock by ensuring
mode_set_fallback_feedback_idle() does get called before potentially waiting
for actual DRM events.
Presumably this call would not be needed if the implementation was running in
its own thread, since it would eventually dispatch its idle callbacks before
going to sleep polling on the DRM fd. This call might even be unnecessary
overhead in that case, synchronizing with the implementation thread needlessly.
But the thread does not exist yet, so this is needed for now.
This is part 1 of 2 fixing a complete desktop freeze when drmModePageFlip()
fails with EINVAL and the fallback to drmModeSetCrtc() succeeds but the success
is not registered correctly as completed "flip". The freeze occurs under
wait_for_pending_flips() which calls down into meta_kms_impl_device_dispatch()
which ends up poll()'ing the DRM fd even though drmModeSetCrtc() will not
produce a DRM event, hence the poll() never returns. The freeze was observed
when hotplugging a DisplayLink dock for the first time on Ubuntu 19.10.
CC stable: gnome-3-34
https://gitlab.gnome.org/GNOME/mutter/merge_requests/953
They have been deprecated for a long time, and all their uses in clutter
and mutter has been removed. This also removes some no longer needed
legacy state tracking, as they were only ever excercised in certain
circumstances when there was sources (pipelines or materials) on the now
removed source stack.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Instead of using cogl_polygon(), which uses deprecated API, implement
polygon drawing using the CoglPrimitive API family. While the test might
have been used to explicitly test cogl_polygon() it could still be
useful to test the non-deprecated way of rendering polygons.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Port tests to use API such as cogl_framebuffer_push_matrix() instead of
cogl_push_matrix() all over the Clutter tests, with one exception:
cogl_polygon(). It'll be ported over in a separate commit, as it is less
straight forward.
Implicitly set CoglMaterial properties are changed to explicitly created
and destructed CoglPipelines with the equivalent properties set.
cogl_push|pop_framebuffer() is replaced by explicitly passing the right
framebuffer, but tests still rely on cogl_get_draw_framebuffer() to get
the target framebuffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
clutter_paint_node_get_framebuffer() fell back on
cogl_get_draw_framebuffer() when the root node didn't have a custom
get_framebuffer vfunc. As this relies on deprecated implicit Cogl stack
API, it needs to go away, so handle this in the caller that knows more
about the context.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Just as with painting, add a pick context that carries pick related
temporary state when doing actor picking. It is currently unused, and
will at least at first still carry around a framebuffer to deal track
view transforms etc.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
When painting, actors rely on semi global state tracked by the state to
get various things needed for painting, such as the current draw
framebuffer. Having state hidden in such ways can be very deceiving as
it's hard to follow changes spread out, and adding more and more state
that should be tracked during a paint gets annoying as they will not
change in isolation but one by one in their own places. To do this
better, introduce a paint context that is passed along in paint calls
that contains the necessary state needed during painting.
The paint context implements a framebuffer stack just as Cogl works,
which is currently needed for offscreen rendering used by clutter.
The same context is passed around for paint nodes, contents and effects
as well.
In this commit, the context is only introduced, but not used. It aims to
replace the Cogl framebuffer stack, and will allow actors to know what
view it is currently painted on.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
It's not always clear how the dma-buf functions work (e.g. where memory
is allocated) without actually going in-depth in the code. This just
adds a few commments to more quickly gain understanding.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/871
Checking the leds is not really accurate, since some devices have mode
switch buttons without leds. Check in the button flags whether they are
mode switch buttons for any of ring/ring2/strip/strip2, and return the
appropriate group.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/952
While most of the code to compute a window's layer isn't explicitly
windowing backend specific, it is in practice: On wayland there are
no DESKTOP windows(*), docks(*) or groups.
Reflect that by introducing a calculate_layer() vfunc that computes
(and sets) a window's layer.
(*) they shall burn in hell, amen!
https://gitlab.gnome.org/GNOME/mutter/merge_requests/949
Most of the layer computation that the stack does actually depends
on the windowing backend, so we will move it to a vfunc.
However before we do that, split out the bit that will be shared.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/949
When a window that should be stacked above another one is placed in a lower
layer than the other window, we currently allow promoting it to the higher
layer when it has a "transient type". We should do the same when the window
is an actual transient of the other window.
This is particularly relevant for wayland windows, where types play a
much smaller role: Transient windows like non-modal dialogs (and since
commit 666bef7a, popup windows as well) currently end up underneath their
always-on-top parent.
https://gitlab.gnome.org/GNOME/mutter/issues/587
This was wrongly introduced in 75cffd0ec4. As the comment above explains, we
only want to queue redraws in response to surface/buffer damage.
This triggered a full redraw when using DMA buffers on Wayland as we currently
create a new texture on every buffer_attach(), breaking partial invalidation.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/947
There might be some inconsistent event for which we don't have a known
source device.
In the current state we don't handle them and we could crash when getting
the current device tool.
So, add an utility function that retrieves the source device for an event
that warns if no device is found, and use this for Motion, Key and Button
events.
In case we don't have a valid source in such case, just return early instead
of trying to generate invalid clutter events.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/823
Add an assert that we don't have a MetaWindow::monitor pointer that
points to an old MetaLogicalMonitor. After this, and the other
monitors-changed callbacks have been called, the old MetaLogicalMonitor
will be destoryed, thus if we didn't update the pointer here, we'll
point to freed memory, and will eventually crash later on.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/929
This is inspired by 98892391d7 where the usage of
`g_signal_handler_disconnect()` without resetting the corresponding
handler id later resulted in a bug. Using `g_clear_signal_handler()`
makes sure we avoid similar bugs and is almost always the better
alternative. We use it for new code, let's clean up the old code to
also use it.
A further benefit is that it can get called even if the passed id is
0, allowing us to remove a lot of now unnessecary checks, and the fact
that `g_clear_signal_handler()` checks for the right type size, forcing us
to clean up all places where we used `guint` instead of `gulong`.
No functional changes intended here and all changes should be trivial,
thus bundled in one big commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
On wl_data_source destruction we used to indirectly unset the DnD selection
owner via the wl_resource destructor triggering the destruction of the
MetaWaylandDataSource, which would be caught through the weak ref set by
the MetaWaylandDragGrab.
This works as long as the grab is held, however we have a window between
the button being released and the drop site replying with
wl_data_offer.finish that the MetaWaylandDataSource is alive, but its
destruction wouldn't result in the call chain above to unsetting the DnD
source.
In other selection sources, we let the MetaWaylandDataDevice hold the
"ownership" of the MetaWaylandDataSource, and its weak ref functions unset
the respective MetaSelection owners. Do the same here, so the
MetaWaylandDataSource destruction is listened for all its lifetime.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/591
This is wrong for both clipboard and DnD, as the selection source
will still be able to focus another surface, and churn another
wl_offer.
We should just detach the data offer from the data source in this
case, and let the source live on. However, we should still check
that there is a source and an offer to finish DnD, do that when
handling the drop operation instead.
https://gitlab.gnome.org/GNOME/mutter/issues/591
Those were used to signal clipboard ownership around, but that got
replaced by MetaSelection and friends. These signals are no longer
listened on, so can be safely removed.
https://gitlab.gnome.org/GNOME/mutter/issues/591
ClutterTexture is going to be removed, so remove interactive tests that
stand in the way for that. Some test texture features, while some makes
heavy use of ClutterTexture to implement their testing. Remove these
tests to prepare for the removal of ClutterTexture.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/932
ClutterTexture is deprecated, lets remove the trivial usage with a
simple gdk-pixbuf using constructor putting pixel contents into a
ClutterImage then putting said image in a plain ClutterActor.
Tested partially, as the interactive tests cannot be properly run at the
moment.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/932
As was with the tests run via meson test, for the interactive tests we
too need to configure the mutter backend and initialize things in order
to be able to run any tests.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/932
Properly take the panel_orientation_transform into account in
update_monitor_crtc_cursor. This fixes us sometimes drawing the cursor
on two monitors at the same time as we did not properly swap the crtc
width/height when a panel_orientation_transform is active.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/927
It seems that sometimes these functions are called by Javascript in
GNOME Shell during tear down. This causes segfaults and crash reports,
but without any backtraces other than the entry and exit points into
gjs.
In order to get more useful information about where these calls come
from, validate the input passed gracefully, by complaining in the log
and returning NULL values.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/926
Add missing clutter_x11_[un]trap_x_errors around the XIGetProperty call
in meta-input-settings-x11.c's get_property helper function.
This fixes mutter crashing with the following error if the XInput device
goes away at an unconvenient time:
X Error of failed request: XI_BadDevice (invalid Device parameter)
Major opcode of failed request: 131 (XInputExtension)
Minor opcode of failed request: 59 ()
Device id in failed request: 0x200011
Serial number of failed request: 454
Current serial number in output stream: 454
https://gitlab.gnome.org/GNOME/mutter/merge_requests/928
We currently assume that the actor_animate() helper function returns
a timeline. However Clutter may skip implicit animations and simple
set properties directly, for example when the actor is hidden.
The returned timeline will be NULL in that case, and we abort when
using it as instance parameter to g_signal_connect().
Fix this by only setting up a completed handler when we are actually
animating, and complete the effect directly otherwise.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/925
The actor is already in surface coordinate space, so we should not scale
with the buffer scale to transform surface coordinates to stage
coordinates.
This bug causes input method using wayland text-input protocol to
receive wrong cursor location. Reproduced in ibus (when candidate
window is open) with scaling factor other than 1.
This commit also fixes pointer confinement.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/915
Java applications might use override-redirect windows as parent windows for
top-level windows, although this is not following the standard [1].
In such case, the first non-override-redirect child window that is created
was marked as being on_all_workspaces since the call to
should_be_on_all_workspaces() returns TRUE for its parent, and this even
though the on_all_workspaces_requested bit is unset.
When a further child of this window was added, it was set as not having a
workspace and not being on_all_workspaces, since the call to
should_be_on_all_workspaces() for its parent would return FALSE (unless if
it is in a different monitor, and the multiple-monitors workspaces are
disabled).
Since per commit 09bab98b we don't recompute the workspace if the
on_all_workspaces bit is unset, we could end up in a case where a window can
be nor in all the workspaces or in a specific workspace.
So let's just ignore the transient_for bit for a window if that points to an
override-redirect, using the x11 root window instead.
Add a stacking test to verify this scenario (was failing before of this
commit).
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/885https://gitlab.gnome.org/GNOME/mutter/merge_requests/895
[1] https://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472512128
Once we set the transient_for, we look for parent MetaWindow, so instead
of overwriting this value for loops check, just use another function
and avoid to look for the xwindow again when setting the MetaWindow parent.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/895
Override-redirect windows have no workspace by default, and can't be parent
of a top-level window, so we must check that the parent window is not an
O-R one when setting the workspace state.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/895
We're expected by MetaWaylandSurface to always pick the frame callbacks
out from the pending state when committing (applying) so that no frame
callbacks are unaccounted for. We failed to do this if our actor for
some reason (e.g. associated window was unmanaged) was destroyed. To
handle this situation better, store away the frame callbacks until we
some later point in time need to pass them on forward.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/893
We ask XLib the next request serial number before performing other actions
triggered by meta_x11_display_set_input_focus_internal() that doesn't use
the request serial anyways. So, just request it before updating the focus
window as that's the operation that needs it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/909
When using DesktopIcons extension and clicking in an icon, gnome-shell
starts an infinite loop caused by the first focus change that may trigger
on X11 a focus in/out event that leads to stage activation/deactivation
which never ends.
This happens because as part of meta_x11_display_set_input_focus_xwindow()
to focus the X11 stage window, we unset the display focus, but this also
causes to request the X11 display to unset the focus since we convolute by
calling meta_x11_display_set_input_focus() with no window, that leads to
focusing the no_focus_window and then a focus-in / focus-out dance that the
shell amplifies in order to give back the focus to the stage.
In order to fix this, mimic what meta_display_set_input_focus() does, but
without updating the X11 display, and so without implicitly calling
meta_x11_display_set_input_focus(), stopping the said convolution and
properly focusing the requested xwindow.
Also ensure that we're not doing this when using an older timestamp, since
this check isn't performed anymore.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/896
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/899https://gitlab.gnome.org/GNOME/mutter/merge_requests/909
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
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
Otherwise we'll end up trying to access the out of date state later.
Fixes the following test failure backtrace:
#0 _g_log_abort ()
#1 g_logv ()
#2 g_log ()
#3 meta_monitor_manager_get_logical_monitor_from_number ()
#4 meta_window_get_work_area_for_monitor ()
#5 meta_window_get_tile_area ()
#6 constrain_maximization ()
#7 do_all_constraints ()
#8 meta_window_constrain ()
#9 meta_window_move_resize_internal ()
#10 meta_window_tile ()
https://gitlab.gnome.org/GNOME/mutter/merge_requests/912
`meta_surface_actor_is_obscured` implies that the actor got successfully culled
out and nothing of it will get painted. This includes that there are no clones,
no effects etc. In this cases we don't want to send frame callbacks, thus avoiding
unnecessary client work.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/918
Create the intermediate shadow framebuffer for use exclusively when a
shadowfb is required.
Keep the previous offscreen framebuffer is as an intermediate
framebuffer for transformations only.
This way, we can apply transformations between in-memory framebuffers
prior to blit the result to screen, and achieve acceptable performance
even with software rendering on discrete GPU.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/877
This is a workaround for X11 games which use randr to change the resolution
in combination with NET_WM_STATE_FULLSCREEN when going fullscreen.
Newer versions of Xwayland support the randr part of this by supporting randr
resolution change emulation in combination with using WPviewport to scale the
app's window (at the emulated resolution) to fill the entire monitor.
Apps using randr in combination with NET_WM_STATE_FULLSCREEN expect the
fullscreen window to have the size of the emulated randr resolution since
when running on regular Xorg the resolution will actually be changed and
after that going fullscreen through NET_WM_STATE_FULLSCREEN will size
the window to be equal to the new resolution.
We need to emulate this behavior for these games to work correctly.
Xwayland's emulated resolution is a per X11 client setting and Xwayland
will set a special _XWAYLAND_RANDR_EMU_MONITOR_RECTS property on the
toplevel windows of a client (and only those of that client), which has
changed the (emulated) resolution through a randr call.
This commit checks for that property and if it is set adjusts the fullscreen
monitor rect for this window to match the emulated resolution.
Here is a step-by-step of such an app going fullscreen:
1. App changes monitor resolution with randr.
2. Xwayland sets the _XWAYLAND_RANDR_EMU_MONITOR_RECTS property on all the
apps current and future windows. This property contains the origin of the
monitor for which the emulated resolution is set and the emulated
resolution.
3. App sets _NET_WM_FULLSCREEN.
4. We check the property and adjust the app's fullscreen size to match
the emulated resolution.
5. Xwayland sees a Window at monitor origin fully covering the emulated
monitor resolution. Xwayland sets a viewport making the emulated
resolution sized window cover the full actual monitor resolution.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/739
Add an adjust_fullscreen_monitor_rect virtual method to MetaWindowClass
and call this from setup_constraint_info() if the window is fullscreen.
This allows MetaWindowClass to adjust the monitor-rectangle used to size
the window when going fullscreen, which will be used in further commits
for a workaround related to fullscreen games under Xwayland.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/739
This allows xdg_popup.grab() to work with styli. Without this check
we would bail out and emit xdg_popup.popup_done, leaving stylus users
unable to interact with popup menus, comboboxes, etc...
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/886
When a touch sequence was rejected, the emulated pointer events would be
replayed with old timestamps. This caused issues with grabs as they
would be ignored due to being too old. This was mitigated by making sure
device event timestamps never travelled back in time by tampering with
any event that had a timestamp seemingly in the past.
This failed when the most recent timestamp that had been received were
much older than the timestamp of the new event. This could for example
happen when a session was left not interacted with for 40+ days or so;
when interacted with again, as any new timestamp would according to
XSERVER_TIME_IS_BEFORE() still be in the past compared to the "most
recent" one. The effect is that we'd always use the `latest_evtime` for
all new device events without ever updating it.
The end result of this was that passive grabs would become active when
interacted with, but would then newer be released, as the timestamps to
XIAllowEvents() would out of date, resulting in the desktop effectively
freezing, as the Shell would have an active pointer grab.
To avoid the situation where we get stuck with an old `latest_evtime`
timestamp, limit the tampering with device event timestamp to 1) only
pointer events, and 2) only during the replay sequence. The second part
is implemented by sending an asynchronous message via the X server after
rejecting a touch sequence, only potentially tampering with the device
event timestamps until the reply. This should avoid the stuck timestamp
as in those situations, we'll always have a relatively up to date
`latest_evtime` meaning XSERVER_TIME_IS_BEFORE() will not get confused.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/886
This way, we can simply pop up the Looking Glass and run:
>>> Meta.add_clutter_debug_flags(Clutter.DebugFlag.PICK, 0, 0)
And measure specific actions or events on GNOME Shell.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/862
In a similar vein to commit 8fd55fef85. This notably failed when setting
the focus on the stage (eg. to redirect key events to Clutter actors).
Deeper in MetaDisplay focus updating machinery, it would check
meta_stage_is_focused() which would still return FALSE at the time it's
called.
This would not typically have side effects, but our "App does not respond"
dialogs see the focus change under their feet, so they try to bring
themselves to focus again. This results in a feedback loop.
Changing the order results in later checks on the X11 POV of the focus
being correct, so focus is not mistakenly stolen from the close dialog,
and it actually succeeds in keeping the key focus.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1607https://gitlab.gnome.org/GNOME/mutter/merge_requests/876
Syncronized subsurfaces that call into `merge_pending_state` might
otherwise not create new destroy handlers, ending up with a invalid
handler ids, throwing errors and leaking.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/868
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
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
Instead of doing a roundtrip to the X server before setting it, rely on
the previous value fetched before the configuration was sent over DBus.
This matches the argument check we already do elsewhere, and will allow
us to more easily add an additional condition to determine if underscan
is supported.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/673
As the first step into removing Cogl types that are covered by
Graphene, remove CoglEuler and replace it by graphene_euler_t.
This is a mostly straightforward replacement, except that the
naming conventions changed a bit. Cogl uses "heading" for the
Y axis, "pitch" for the X axis, and "roll" for the Z axis, and
graphene uses the axis themselves. That means the 1st and 2nd
arguments need to be swapped.
Also adapt the matrix stack to store a graphene_euler_t in the
rotation node -- that simplifies the code a bit as well.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Graphene uses C99 and includes stdbool.h, which adds a
new 'bool' type. Clutter has an a11y test that names a
variable as 'bool' too, and they do not play well together.
Rename this variable to boolean.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Fog is explicitly deprecated in favour of CoglSnippet API,
and in nowhere we are using this deprecated feature, which
means we can simply drop it without any sort of replacement.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Move out updating of various shapes (input, opaque, shape) indirectly
from X11 to the corresponding X11 sub types of MetaWindowActor and
MetaSurfaceActor.
Also move fullscreen window unredirection code with it. We want to
effectively do something similar for MetaCompositorServer, but it will
work differently enough not to share too much logic.
While it would have been nice to move things piece by piece, things were
too intertwined to make it feasible.
This has the side effect fixing accidentally and arbitrarily adding
server side shadow to Wayland surfaces.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/727https://gitlab.gnome.org/GNOME/mutter/merge_requests/734
It is opaque if the texture has no alpha channel, or if the opaque
region covers the whole content.
Internally uses a function that checks whether there is an alpha
channel. This API will be exposed at a later time as well.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/734
As we will start adding support for more pixel formats, we will need to
define a notion of planes. This commit doesn't make any functional
change, but starts adding the idea of pixel formats and how they (at
this point only theoretically) can have multple planes.
Since a lot of code in Mutter assumes we only get to deal with single
plane pixel formats, this commit also adds assertions and if-checks to
make sure we don't accidentally try something that doesn't make sense.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/858
Clutter had support for internal children in its early revisions, but they
were deprecated for long time (commit f41061b8df, more than 7 years ago) and
no one is using them in both clutter and in gnome-shell.
So remove any alternative code path that uses internal children.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/816
Instead of passing around an X11 Display pointer that is retrieved from
the default Gdk backend, then finding the MetaX11Display from said X11
Display, pass the MetaX11Display directly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/854
The functionality core/core.c and core/core.h provides are helpers for
the window decorations. This was not possible to derive from the name
itself, thus rename it and put it in the right place.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/854
This is for all intents and purposes the same as
`cogl_object_ref/unref`, but still refers to handles rather than
objects (while we're trying to get rid of the former) so it's a bit of
unnecessary redundant API.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/451
We were just looking at DnD actions which might still be unset at that
point. Instead of doing these heuristics, store the selection type on
the data offer.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/845
Requesting a selection with a NULL data source means "unset the clipboard",
but internally we use an unset clipboard as the indication that the
clipboard manager should take over.
Moreover, this unset request may go unheard if the current owner is someone
else than the MetaWaylandDataDevice.
Instead, set a dummy data source with no mimetypes nor data, this both
prevents the clipboard manager from taking over and ensures the selection
is replaced with it.
The MetaSelectionSourceMemory was also added some checks to allow for this
dummy mode.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/793
Instead of taking resource and send/cancel funcs, take a
MetaWaylandDataSource, which exposes all the vfuncs to do the same on the
internal resource.
This has the added side effect that only MetaWaylandDataSource has a
pointer to the wl_resource, which may be unset untimely.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/842
If a data source is destroyed we first unset the resource, and then try to
unref the related selection source. At this point the only event that might
be emitted by the internal selection machinery is .cancelled, so make sure
we avoid it on destroyed sources.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/842
We are still poking the mimetypes from the previous selection when creating
the new offer. This may come out wrong between changes of the copied
mimetypes.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/789
Otherwise we'll get the warning
../src/core/main.c: In function 'meta_test_init':
../src/core/main.c:755:1: error: function might be candidate for attribute 'noreturn' [-Werror=suggest-attribute=noreturn]
755 | meta_test_init (void)
| ^~~~~~~~~~~~~~
when building without Wayland.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/837
If we did a mode set, the gamma may have been changed by the kernel, and
if we didn't also update the gamma in the same transaction, we have no
way to predict the current gamma ramp state. In this case, read the
gamma state directly from KMS.
This should be relatively harmless regarding the race conditions the
state prediction was meant to solve, as the worst case is we get none or
out of date gamma ramps; and since this is for when gamma ramps are not
updated at mode setting time, we'd get intermediate gamma state to begin
with, so it's not worse than what we currently do anyway.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/851https://gitlab.gnome.org/GNOME/mutter/merge_requests/840
Xkb events should be handled by clutter backend but they are not translated
into an actual clutter event. However we're now handling them and also trying
to push an empty event to clutter queue, causing a critical error.
So in such case, just handle the native event but don't push the non-populated
clutter-event to the queue.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/750https://gitlab.gnome.org/GNOME/mutter/merge_requests/764
A frame callback without damage is still expected to be responded to.
Implement this by simply queuing damage if there are any frame callbacks
requested and there is no damage yet. If there already is damage,
we'll be queued already, but with more correct damage. Without we simply
need to make sure we flush the callbacks if any area of surface is not
occluded.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/457https://gitlab.gnome.org/GNOME/mutter/merge_requests/839
The inhibited state of the monitor was after the initializiation never
updated. meta_idle_monitor_reset_idletime didn't respect the inhibited
state, so it set timeouts if it shouldn't have.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/573
For the most part, a MetaWindow is expected to live roughly as long as
the associated wl_surface, give or take asynchronous API discrepancies.
The exception to this rule is handling of reparenting when decorating or
undecorating a window, when a MetaWindow on X11 is made to survive the
unmap/map cycle. The fact that this didn't hold on Wayland caused
various issues, such as a feedback loop where the X11 window kept being
remapped. By making the MetaWindow lifetime for Xwayland windows being
the same as they are on plain X11, we remove the different semantics
here, which seem to lower the risk of hitting the race condition causing
the feedback loop mentioned above.
What this commit do is separate MetaWindow lifetime handling between
native Wayland windows and Xwayland windows. Wayland windows are handled
just as they were, i.e. unmanaged together as part of the wl_surface
destruction; while during the Xwayland wl_surface destruction, the
MetaWindow <-> MetaWaylandSurface association is simply broken.
Related: https://gitlab.freedesktop.org/xorg/xserver/issues/740
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/762https://gitlab.gnome.org/GNOME/mutter/merge_requests/774
We get implicit, thus auto-removed, transitions, then manage them
manually by stopping them and emitting "completed" signals. This doesn't
work since they are removed and freed when stopped. To be able to emit
the "completed" signal, hold a reference while stopping, so that we
still can emit the signal as before.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/828
Dropping the grab has the side effect that the pointer will be re-picked,
and it might find another surface with a pointer constraint. If that were
the case, the focus change would try to add the pointer constraint before
the now old focus surface released its own.
Just invert these operations, so the constraint is unset before the repick
that might enable another pointer constraint.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/779
Just like sync_focus_surface() does, we shouldn't set a focus surface while
the pointer is hidden, so the illusion that there is none remains.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/779
We can't just update the state of the connector and CRTC from KMS since
it might contain too new updates, e.g. from a from a future hot plug. In
order to not add ad-hoc hot plug detection everywhere, predict the state
changes by looking inside the MetaKmsUpdate object, and let the hot-plug
state changes happen after the actual hot-plug event.
This fixes issues where connectors were discovered as disconnected while
doing a mode-set, meaning assumptions about the connectedness of
monitors elsewhere were broken until the hot plug event was processed.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/782https://gitlab.gnome.org/GNOME/mutter/merge_requests/826
After commit 75cffd0e ("shaped-texture: Implement ClutterContent"), the
input to the meta_wayland_tablet_tool_get_relative_coordinates function
is already scaled correctly. By scaling it again, all stylus events are
getting mapped to the screen incorrectly (for anything != 100% scaling).
See also: d3f30d9ehttps://gitlab.gnome.org/GNOME/mutter/merge_requests/830
Correct silly mistake where the MetaWaylandSurface was passed as the
user_data of the surface actor destroy signal handler, instead of the
expected MetaWaylandActorSurface.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/844
Instead of storing the result of meta_prop_get_latin1_string() into
a temporary string value, g_strdup-ing that temp value storing the
g_strdup result into window->sm_client_id and then g_free-ing the
temporary string, we can pass window->sm_client_id as the place where
meta_prop_get_latin1_string() stores its result, since the result
from meta_prop_get_latin1_string() is itself a g_strdup-ed string,
so there is no need to g_strdup it again.
Note this drops the check to only issue the
"Window %s sets SM_CLIENT_ID on itself ..." warning once. This check is
not necessary as update_sm_hints() is only called once at window
creation time and is never called again.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
Use g_strdup instead of malloc + strcpy, this also gets rid of a bunch
of error checking which is no longer necessary, also adjust the free
path accordingly.
Note that there was a malloc + XFree mismatch in the removed error-handling.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
latin1_string_from_results and utf8_string_from_results use g_strndup,
so the returned string should be freed with g_free, rather then with
free or XFree. This fixes all free-s of buffers returned by these 2
functions to properly use g_free.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
Use g_new0 instead of calloc for motif_hints_from_results and adjust
its callers to use g_free.
Note that in the process_request_frame_extents function this replaces
the wrong original mismatch of calloc + XFree with a matching g_malloc +
g_free pair.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
Clutter actors might emit property changes in dispose, while unparenting.
However we assume that the ::destroy signal is the last one we emit for an
actor, and that starting from this moment the object is not valid anymore,
and so we don't expect any signal emission from it.
To avoid this, freeze the object notifications on an actor during its
disposition, just before the ::destroy signal emission.
Update the actor-destroy test to verify this behavior.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/769
Clutter actors unset their parent on dispose, after emitting the ::destroy
signal, however this could cause ::parent-set signal emission. Since we
assume that after the destruction has been completed the actor isn't valid
anymore, and that during the destroy phase we do all the signal / source
disconnections, this might create unwanted behaviors, as in the signal
callbacks we always assume that the actor isn't in disposed yet.
To avoid this, don't emit ::parent-set signal if the actor is being
destroyed.
Update the actor-destroy test to verify this behavior.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/769
Mutter issues a synchronous grab on the pointer for unfocused client
windows to be able to catch the button events first and raise/focus
client windows accordingly.
When there is a synchronous grab in effect, all events are queued until
the grabbing client releases the event queue as it processes the events.
Mutter does release the events in its event handler function but does so
only if it is able to find the window matching the event. If the window
is a shell widget, that matching may fail and therefore Mutter will not
release the events, hence causing a freeze in pointer events delivery.
To avoid the issue, make sure we sync the pointer events in case we
can't find a matching window.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/821
It was not the lack of forcing the shadow fb that caused slowness, but
rather due to the method the shadow fb content was copied onto the
scanout fb. With 'clutter: Use cogl_blit_framebuffer() for shadow FB'
we'll use a path that shouldn't be slow when copying onto the scanout
fb.
Also 437f6b3d59 accidentally enabled
shadow fb when using hw accelerated contexts, due to the cap being set
to 1 in majority of drivers. While the kernel documentation for the
related field says "hint to userspace to prefer shadow-fb rendering",
the name of the hint when exposed to userspace is
DRM_CAP_DUMB_PREFER_SHADOW, thus should only be taken into consideration
for dumb buffers, not rendering in general.
This reverts commit 437f6b3d59.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/818
The commit 'renderer/native: Use shadow fb on software GL if preferred'
attempted to force using a shadow fb when using llvmpipe in order to
speed up blending, but instead only did so when llvmpipe AND the drm
device explicityl asked for it.
Now instead always force it for llvmpipe and other software rendering
backends, and otherwise just query the drm device (i.e.
DRM_CAP_DUMB_PREFER_SHADOW).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/807
Since the recent clutter-content work, legacy scaling (in contrast
to the new stage-view-scaling) only applies to surfaces that belong
to a window. This broke scaling of DnD surfaces.
As a workaround, apply the same scaling on DnD-surface-actors until
we use stage-view-scaling by default and can remove this again.
Also: small corrections of geometry calculation
https://gitlab.gnome.org/GNOME/mutter/merge_requests/780
This allows us to implement more sophisticated logic for the different
cases. For DnD surfaces, use the geometry scale of the monitor where
the pointer is, instead of incorrectly assuming '1' as it was before.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/780
The meta_display_update_focus_window() call has indirect dependencies
on the X11 focus window, in order to determine the correct focus window
on the Wayland side (i.e. may turn out NULL with certain X windows).
In order to have the right x11_display->focus_xwindow there, we should
perform first the focus update on the X11 display.
Fixes focusing of Java applications, as those don't seem to go through
_NET_ACTIVE_WINDOW.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/819
With the addition of the locate-pointer special keybinding (defaults to
the [Control] key), we have now two separate special modifier keys which
can be triggered separately, one for the locate-pointer action and
another one for overlay.
When processing those special modifier keys, mutter must ensure that the
key was pressed alone, being a modifier, the key could otherwise be part
of another key combo.
As result, if both special modifiers keys are pressed simultaneously,
mutter will try to trigger the function for the second key being
pressed, and since those special modifier keys have no default handler
function set, that will crash mutter.
Check if the handler has a function associated and treat the keybinding
as not found if no handler function is set, as with the special modifier
keys.
https://gitlab.gnome.org/GNOME/mutter/issues/823
The `process_event()` would check for a existing keybinding handler and
abort if there is none, however the test is done after the handler had
been accessed, hence defeating the purpose of the check.
Move the check to verify there is an existing keybinding handler before
actually using it.
https://gitlab.gnome.org/GNOME/mutter/issues/823
There were multiple bugs present after the ClutterContent transition.
Refactor `get_image` to:
- always assume surface coordinates for the clip
- return a cairo_surface in buffer size
- make the offscreen path take size arguments, so we can
easily change the assumption in get_image
- fix some clipping bugs on the way
https://gitlab.gnome.org/GNOME/mutter/merge_requests/758
Some drivers expose EGL_EXT_image_dma_buf_import_modifiers so you can
query supported formats, but don't support any modifiers. Handle this by
treating it like DRM_FORMAT_MOD_INVALID.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/782
Instead of open coding the X11 focus management in display.c, expose
it as a single function with similar arguments to its MetaDisplay
counterpart. This just means less X11 specifics in display.c.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/751
MetaDisplay and MetaX11Display focus windows are slightly decoupled,
we cannot rely here on the MetaDisplay focus to be updated yet. We
however know the X Window that got focused, so lookup the corresponding
MetaWindow (and client X window) from it.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/751
We have a "setup" phase, used internally to initialize early the x11
side of things like the stack tracker, and an "opened" phase where
other upper parts may hook up to. This latter phase is delayed during
initialization so the upper parts have a change to connect to on
plugin creation.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/771
When starting standalone mutter and running using the native backend, we
always fall back on using the us pc105 keyboard layout. This can be very
frustrating if one is used to using some other keyboard layout, such as
dvorak, causing keyboard fumbling everytime when doing something with
standalone mutter.
Avoid this involuntary fumbling by having the default plugin query
localed what layout the user has actually configured the machine to
operate using. It doesn't add any keymap selection user interface, so
it'll always use the first one it encounters.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/787
The commit f2f4af0d50 missed one situation
where mutter does things differently, i.e. changes what surface actor is
associated with a given window actor: reparenting a Xwayland window when
changing whether it is decorated.
To summarize, there are three types of window actors:
X11 window actors - directly tied to the backing X11 window. The
corresponding surface actor is directly owned by the window actor and
will never change.
Wayland window actors - gets its surface actor from MetaWaylandSurface
at construction. A single MetaWaylandSurface may create and destroy
multiple window actors over time, but a single window actor will never
change surface actor.
Xwayland window actors - a mix between the above two types; the window
corresponds to the X11 window, and so does the window actor, but the
surface itself comes from the MetaWaylandSurface.
Normally when a X11 window is unmapped, the corresponding MetaWindow is
unmanaged. With Xwayland, this happens indirectly via the destruction of
the wl_surface. The exception to this is windows that are reparented
during changing their decoration state - in this case on plain X11, the
MetaWindow stays alive. With Xwayland however, there is a race
condition; since the MetaWindow is tied to the wl_surface, if we receive
the new surface ID atom before the destruction of the old wl_surface,
we'll try to associate the existing MetaWindow and MetaWindowActor with
the new wl_surface, hitting the assert. If the surface destruction
arrives first, the MetaWindow and MetaWindowActor will be disposed, and
the we wouldn't hit the assert.
To handle this race gracefully, reinstate handling of replacing the
surface actor of an existing window actor, to handle this race, as it
was handled before.
Eventually, it should be reconsidered whether the MetaWindow lifetime is
tied to the wl_surface or if it should be changed to be consistent with
plain X11, as this re-exposes another bug where the X11 client and
mutter will enter a feedback loop where the window is repeatedly
remapped. See https://gitlab.freedesktop.org/xorg/xserver/issues/740.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/709https://gitlab.gnome.org/GNOME/mutter/merge_requests/773
When using xdg-output v3 or later, the Wayland compositor does not send
xdg_output.done events which are deprecated.
Instead, it should send a wl_output.done event for the matching
wl_output.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/771
When suspending, the devices are removed and the virtual device
associated with the corresponding core pointer is disposed.
Add the pointer accessibility virtual device to the core pointer
on resume to restore pointer accessibility on resume if enabled.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/761
When starting a DnD operation, mutter would remove keyboard focus from
the client, only to restore it on the data offer destroy.
However, if the DnD fail, the keyboard focus is not restored, leaving
the user unable to type in the focused window, even after clicking in
the window.
That issue would show only on first attempt, as further DnD attempts
would destroy the previous data offer which would also restore the
keyboard focus.
Make sure we restore the keyboard focus on drag end as well.
https://gitlab.gnome.org/GNOME/mutter/issues/747
On drag start, `data_device_start_drag()` issues a keyboard grab, which
in turn will unset the current input focus.
There is not need to unset the input focus in `data_device_start_drag()`
as this is redone in `meta_wayland_keyboard_start_grab()`
https://gitlab.gnome.org/GNOME/mutter/issues/747
Currently, Clutter does picking by drawing with Cogl and reading
the pixel that's beneath the given point. Since Cogl has a journal
that records drawing operations, and has optimizations to read a
single pixel from a list of rectangle, it would be expected that
we would hit this fast path and not flush the journal while picking.
However, that's not the case: dithering, clipping with scissors, etc,
can all flush the journal, issuing commands to the GPU and making
picking slow. On NVidia-based systems, this glReadPixels() call is
extremely costly.
Introduce geometric picking, and avoid using the Cogl journal entirely.
Do this by introducing a stack of actors in ClutterStage. This stack
is cached, but for now, don't use the cache as much as possible.
The picking routines are still tied to painting.
When projecting the actor vertexes, do it manually and take the modelview
matrix of the framebuffer into account as well.
CPU usage on an Intel i7-7700, tested with two different GPUs/drivers:
| | Intel | Nvidia |
| ------: | --------: | -----: |
| Moving the mouse: |
| Before | 10% | 10% |
| After | 6% | 6% |
| Moving a window: |
| Before | 23% | 81% |
| After | 19% | 40% |
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/154,
https://gitlab.gnome.org/GNOME/mutter/issues/691
Helps significantly with: https://gitlab.gnome.org/GNOME/mutter/issues/283,
https://gitlab.gnome.org/GNOME/mutter/issues/590,
https://gitlab.gnome.org/GNOME/mutter/issues/700
v2: Fix code style issues
Simplify quadrilateral checks
Remove the 0.5f hack
Differentiate axis-aligned rectangles
https://gitlab.gnome.org/GNOME/mutter/merge_requests/189
Add a function to check whether a point is inside a quadrilateral
by checking the cross product of vectors with the quadrilateral
points, and the point being checked.
If the passed quadrilateral is zero-sized, no point is ever reported
to be inside it.
This will be used by the next commit when comparing the transformed
actor vertices.
[feaneron: add a commit message and remove unecessary code]
https://gitlab.gnome.org/GNOME/mutter/merge_requests/189
If window decoration is modified within a short period of time, mutter
sometimes starts processing the second request before the first
UnmapNotify event has been received. In this situation, it considers
that the window is not mapped and does not expect another UnmapNotify /
MapNotify event sequence to happen.
This adds a separate counter to keep track of the pending reparents. The
input focus is then restored when MapNotify event is received iff all
the expected pending ReparentNotify events have been received.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/657
Threaded swap wait was added for using together with the Nvidia GLX
driver due to the lack of anything equivalent to the INTEL_swap_event
GLX extension. The purpose was to avoid inhibiting the invocation of
idle callbacks when constantly rendering, as the combination of
throttling on swap-interval 1 and glxSwapBuffers() and the frame clock
source having higher priority than the default idle callback sources
meant they would never be invoked.
This was solved in gbz#779039 by introducing a thread that took care of
the vsync waiting, pushing frame completion events to the main thread
meaning the main thread could go idle while waiting to draw the next
frame instead of blocking on glxSwapBuffers().
As of https://gitlab.gnome.org/GNOME/mutter/merge_requests/363, the
main thread will instead use prediction to estimate when the next frame
should be drawn. A side effect of this is that even without
INTEL_swap_event, we would not block as much, or at all, on
glxSwapBuffers(), as at the time it is called, we have likely already
hit the vblank, or will hit it soon.
After having introduced the swap waiting thread, it was observed that
the Nvidia driver used a considerable amount of CPU waiting for the
vblank, effectively wasting CPU time. The need to call glFinish() was
also problematic as it would wait for the frame to finish, before
continuing. Due to this, remove the threaded swap wait, and rely only on
the frame clock not scheduling frames too early.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=781835
Related: https://gitlab.gnome.org/GNOME/mutter/issues/700
[jadahl: Rewrote commit message]
https://gitlab.gnome.org/GNOME/mutter/merge_requests/602
Since Clutter's backend relies on MetaBackend now, initialzation has
to go through meta_init(), both in mutter and in gnome-shell.
However the compositor enum and backend gtype used to enforce the
environment used for tests are private, so instead expose a test
initialization function that can be used from both mutter and
gnome-shell.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/750
If an application provides its window icon via wmhints, then mutter
loads the pixmap specified by the application into a cairo xlib surface. When
creating the surface it specifies the visual, indirectly, via an XRender
picture format.
This is suboptimal, since XRender picture formats don't have a way to specify
16bpp depth, which an application may be using.
In particular, applications are likely to use 16bpp depth pixmaps for their
icons, if the video card offers a 16bpp framebuffer/root window.
This commit drops the XRender middleman, and just tells cairo a visual to use
directly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/715
This currently uses a hack where it pushes a CoglFramebuffer backed by a
texture to the framebuffer stack, then calls clutter_actor_paint() on
the window actor causing it to render into the framebuffer. This has the
effect that all subsurfaces of a window will be drawn as part of the
window.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/752
We are really more interested in when a window is damaged, rather than
when it's painted, for screen casting windows. This also has the benefit
of not listening on the "paint" signal of the actor, meaning it'll open
doors for hacks currently necessary for taking a screenshot of a window
consisting of multiple surfaces.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/752
Make it possible to listen for damage on a window actor. For X11, the
signal is emitted when damage is reported; for Wayland, it is emitted
when any of the surfaces associated with the window is damaged.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/752
Since Clutter's backend relies on MetaBackend now, initialzation has
to go through meta_init(), both in mutter and in gnome-shell.
However the compositor enum and backend gtype used to enforce the
environment used for tests are private, so instead expose a test
initialization function that can be used from both mutter and
gnome-shell.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/750
Flatten the subsurface actor tree, making all surface actors children
of the window actor.
Save the subsurface state in a GNode tree in MetaWaylandSurface, where
each surface holds two nodes, one branch, which can be the tree root
or be attached to a parent surfaces branch, and a leaf, which is
used to save the position relative to child branch nodes.
Each time a surface is added or reordered in the tree, unparent all
surface actors from the window actor, traverse all leaves of the
tree and readd the corresponding surface actors back to the window
actor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/664
This object can be generally triggered without a X11 display, so make sure
this is alright. For guard window checks, use our internal
meta_stack_tracker_is_guard_window() call, which is already no-x11 aware.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/730
We indirectly were relying on the MetaX11Stack for this. We strictly
need the _NET_CLIENT_LIST* property updates there, so move our own
internal synchronization to common code.
Fixes stacking changes of windows while there's no MetaX11Display.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/730
The MetaShapedTexture created by MetaSurfaceActor used to
be a ClutterActor, which means destruction was taken care
by Clutter.
Now that it's a plain GObject, we need to manually clean it
up.
Cleanup the shaped texture on disposal.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/753
The surface offset allows an application to move itself in relative
coordinates to its previous position. It is rather ill defined and
partly incompatible with other functionality, which is why we ignore
it generally.
For dnd-surfaces though, it is the de-facto standard for applications
to properly position the dnd-icon below the cursor. Therefore apply
the offset on actor sync by setting the feedback actor anchor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/684
Commit b12c92e206 ("wayland: Add MetaWaylandSurface::geometry-changed signal")
Added a "geometry-changed" signal on MetaWaylandSurface, but the matching
changes to src/wayland/meta-pointer-confinement-wayland.c made it listen
for geometry-changed on the surface-actor instead of on the surface itself,
leading to errors like these:
gnome-shell[37805]: ../gobject/gsignal.c:2429: signal 'geometry-changed' is invalid for instance '0x5653aa7cfe50' of type 'MetaSurfaceActorWayland'
This commit fixes this.
Fixes: b12c92e206 ("wayland: Add MetaWaylandSurface::geometry-changed signal")
https://gitlab.gnome.org/GNOME/mutter/merge_requests/751
And add the necessary glue so those initialize a X11 clutter backend.
This should get Clutter tests that are dependent on windowing to work
again, thus they were enabled back again.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
The end goal is to have all clutter backend code in src/backends. Input
is the larger chunk of it, which is now part of our specific
MutterClutterBackendNative, this extends to device manager, input devices,
tools and keymap.
This was supposed to be nice and incremental, but there's no sane way
to cut this through. As a result of the refactor, a number of private
Clutter functions are now exported for external backends to be possible.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
The end goal is to have all clutter backend code in src/backends. Input
is the larger chunk of it, which is now part of our specific
MutterClutterBackendX11, this extends to device manager, input devices,
tools and keymap.
This was supposed to be nice and incremental, but there's no sane way
to cut this through. As a result of the refactor, a number of private
Clutter functions are now exported for external backends to be possible.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
After the introduction of locate-pointer (commit 851b7d063 -
“keybindings: Trigger locate-pointer on key modifier”), inhibiting
shortcuts would no longer forward the overlay key to the client.
Restore the code that was inadvertently removed so that inhibiting
shortcuts works on the overlay key again.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/734
Geometry scale is applied to each surface individually, using
Clutter scales, and not only this breaks subsurfaces, it also
pollutes the toolkit and makes the actor tree slightly too
fragile. If GNOME Shell mistakenly tries to set the actor scale
of any of these surfaces, for example, various artifacts might
happen.
Move geometry scale handling to MetaWindowActor. It is applied
as a child transform operation, so that the Clutter-managed
scale properties are left untouched.
In the future where the entirety of the window is managed by a
ClutterContent itself, the geometry scale will be applied
directly into the transform matrix of MetaWindowActor. However,
doing that now would break the various ClutterClones used by
GNOME Shell, so the child transform is an acceptable compromise
during this transition.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
meta_shaped_texture_update_area() is a private function that
is exposed in the public headers. It is not used anywhere
outside Mutter, and should really be in the private header.
Move it to the private header.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
Now that MetaShapedTexture is not a ClutterActor anymore, it does
not make sense to make it a MetaCullable semi-implementation. This
is, naturally, a responsibility of MetaSurfaceActor, since now
MetaShapedTexture is a ClutterContent and as such, it only cares
about what to draw.
Move the MetaCullable implementation of MetaShapedTexture to
MetaSurfaceActor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
By implementing ClutterContent, it is expected that
MetaShapedTexture can draw on any actor. However,
right now this is not possible, since it assumes
that the drawing coordinates and sizes of the actor
are synchronized with its own reported width and
height.
It mistakenly draws, for example, when setting an
actor's content to it. There is no way to trigger
this wrong behavior right now, but it will become
a problem in the future where we can collect the
paint nodes of MetaShapedTexture as part of other
ClutterContent implementations.
Use the allocation box passed by the actor to draw
the pipelines of MetaShapedTexture.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
Now that MetaShapedTexture is a ClutterContent implemetation that
is aware of its own buffer scale, it is possible to simplify the
event translation routines.
Set the geometry scale in MetaSurfaceActor, and stop adjusting the
surface scale when translating points. Also remove the now obsoleted
meta_wayland_actor_surface_calculate_scale() function.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
MetaWindowActor is the compositor-side representative of a
MetaWindow. Specifically it represents the geometry of the
window under Clutter scene graph. MetaWindowActors are backed
by MetaSurfaceActors, that represent the windowing system's
surfaces themselves. Naturally, these surfaces have textures
with the pixel content of the clients associated with them.
These textures are represented by MetaShapedTexture.
MetaShapedTextures are currently implemented as ClutterActor
subclasses that override the paint function to paint the
textures it holds.
Conceptually, however, Clutter has an abstraction layer for
contents of actors: ClutterContent. Which MetaShapedTexture
fits nicely, in fact.
Make MetaShapedTexture a ClutterContent implementation. This
forces a few changes in the stack:
* MetaShapedTexture now handles buffer scale.
* We now paint into ClutterPaintNode instead of the direct
framebuffer.
* Various pieces of Wayland code now use MetaSurfaceActor
instead of MetaShapedTexture.
* MetaSurfaceActorWayland doesn't override size negotiation
vfuncs anymore
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
With the addition of xauth support (commit a8984a81c), Xwayland would
rely only on the provided cookies for authentication.
As a result, running an Xclient from another VT (hence without the
XAUTHORITY environment variable set) would result in an access denied.
The same on X11 is granted because the local user is automatically
granted access to Xserver by the startup scripts.
Add the local user to xhost at startup on Xwayland so that the user can
still run a client by setting the DISPLAY as long as it's the same user
on the same host.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/735
A base type shouldn't know about sub types, so let MetaDisplay make
the correct choice of what type of MetaCompositor it should create. No
other semantical changes introduced.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
Introduce MetaCompositorX11, dealing with being a X11 compositor, and
MetaCompositorServer, being a compositor while also being the display
server itself, e.g. a Wayland display server.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
When double clicking to un-maximize an X11 window under Wayland, there
is a race between X11 and Wayland protocols and the X11 XConfigureWindow
may be processed by Xwayland before the button press event is forwarded
via the Wayland protocol.
As a result, the second click may reach another X11 window placed right
underneath in the X11 stack.
Make sure we do not forward the button press event to Wayland if it was
handled by the frame UI.
https://gitlab.gnome.org/GNOME/mutter/issues/88
Add meta-kms and meta-monitor-manager-kms listener for the udev
device-removed signal and on this signal update the device state /
re-enumerate the monitors, so that the monitors properly get updated
to disconnected state on GPU removal.
We really should also have meta-backend-native remove the GPU itself
from our list of GPU objects. But that is more involved, see:
https://gitlab.gnome.org/GNOME/mutter/issues/710
This commit at least gets us to a point where we properly update the
list of monitors when a GPU gets unplugged; and where we no longer
crash the first time the user changes the monitor configuration after
a GPU was unplugged.
Specifically before this commit we would hit the first g_error () in
meta_renderer_native_create_view () as soon as some monitor
(re)configuration is done after a GPU was unplugged.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/713
drmModeGetConnector may fail and return NULL, this may happen when
a connector is removed underneath us (which can happen with e.g.
DP MST or GPU hot unplug).
Deal with this by skipping the connector when enumerating and by
assuming it is disconnected when checking its connection state.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/713
drmModeGetCrtc may fail and return NULL. This will trigger when
meta_kms_crtc_update_state gets called from meta_kms_update_states_sync
after a GPU has been unplugged leading to a NULL pointer deref causing
a crash.
This commit fixes this by checking for NULL and clearing the current_state
when NULL is returned.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/713
Before this commit meta_kms_crtc_read_state was overwriting the
entire MetaKmsCrtcState struct stored in crtc->current_state including
the gamma (sub)struct.
This effectively zero-s the gamma struct each time before calling
read_gamma_state, setting the pointers where the previous gamma values
were stored to NULL without freeing the memory. Luckily this zero-ing
also sets gamma.size to 0, causing read_gamma_state to re-alloc the
arrays on each meta_kms_crtc_update_state call. But this does mean that
were leaking the old gamma arrays on each meta_kms_crtc_update_state call.
This commit fixes this by making meta_kms_crtc_read_state only overwrite
the other values in the MetaKmsCrtcState struct and leaving the gamma
sub-struct alone, this will make read_gamma_state correctly re-use the
gamma tables if the gamma table size is unchanged; or re-alloc them
(freeing the old ones) if the size has changed, fixing the memory leak.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/713
The "device-added" signal should use g_cclosure_marshal_VOID__OBJECT not
g_cclosure_marshal_VOID__VOID.
Instead of fixing this manually, simply replace the closure function for
both signals with NULL, glib will then automatically set the correct
va_marshaller.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/713
Some meta_later operations may happen across XWayland being shutdown,
that trigger MetaStackTracker queries for X11 XIDs. This crashes as
the MetaX11Display is already NULL.
Return a NULL window in that case, as in "unknown stack ID".
https://gitlab.gnome.org/GNOME/mutter/merge_requests/728
There may be cases where a X11 client does not spawn any X11 windows (eg.
simple clients like xinput --list, or xlsclients), in this case the Xwayland
server would remain running until X11 windows happen to come and go in the
future.
Firing the shutdown timeout on restart caters for this, and would be undone
if the client maps X11 windows.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/728
Where the prepare_auth_file() call is, it does create a new one on every
respawn of Xwayland. This is not benefitial, as the XAUTHORITY envvar is
already fixed in the session.
Only create the XAuthority file once, and reuse it on future Xwayland
respawns.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/728
When primary_offer_receive checks if the requested mime_type is supported,
it should check against the list of mime-types supported by the
primary-selection, instead of the list for the clipboard.
This fixes primary selection copy paste from X11 apps to Wayland apps
not working.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/702
Explicitly checking the dimensions of a mode to determine whether it
should be advertised or not fails for portrait style modes. Avoid this
by checking the area instead.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/722
We only listen for those so we know there's no more X11 clients that we
should keep the Xwayland server alive for. Check first that we really did
request Xwayland to be handled on demand for this, otherwise the check is
superfluous, even harmful.
https://gitlab.gnome.org/GNOME/mutter/issues/719
The Xwayland manager now has 4 distinct phases:
- Init and shutdown (Happening together with the compositor itself)
- Start and stop
In these last 2 phases, handle orderly initialization and shutdown
of Xwayland. On initialization We will simply find out what is a
proper display name, and set up the envvar and socket so that clients
think there is a X server.
Whenever we detect data on this socket, we enter the start phase
that will launch Xwayland, and plunge the socket directly to it.
In this phase we now also set up the MetaX11Display.
The stop phase is pretty much the opposite, we will shutdown the
MetaX11Display and all related data, terminate the Xwayland
process, and restore the listening sockets. This phase happens
on a timeout whenever the last known X11 MetaWindow is gone. If no
new X clients come back in this timeout, the X server will be
eventually terminated.
The shutdown phase happens on compositor shutdown and is completely
uninteresting. Some bits there moved into the stop phase as might
happen over and over.
This is all controlled by META_DISPLAY_POLICY_ON_DEMAND and
the "autostart-xwayland" experimental setting.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
When rushing to unmanage X11 windows after the X11 connection is closed/ing,
this would succeed at creating a stack operation for no longer known windows.
Simply avoid to queue a stack operation if we know it's meaningless.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
Unmanaging the windows may trigger stack operations that we later try
to synchronize despite being in dispose() stage. This may trigger
MetaStackTracker warnings when trying to apply those operations.
Switching destruction order (First dispose the X11 stack representation,
then unmanage windows) won't trigger further stack changes on X11 windows
after having signaled MetaDisplay::x11-display-closing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
What "restart" means is somewhat different between x11 and wayland
sessions. A X11 compositor may restart itself, thus having to manage
again all the client windows that were running. A wayland compositor
cannot restart itself, but might restart X11, in which case there's
possibly a number of wayland clients, plus some x11 app that is
being started.
For the latter case, the assert will break, so just make it
conditional. Also rename the function so it's more clear that it
only affects X11 windows.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
In the case mutter is a x11 compositor, it doesn't matter much
since the stack tracker will go away soon. In the case this is a
wayland compositor with mandatory Xwayland, it matters even less
since the session would be shutting down in those paths.
But if this a wayland compositor that can start Xwayland on demand,
this is even harmful, as the MetaStackTracker should be cleared of
x11 windows at this moment, and we actually did right before dispose
on ::x11-display-closing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
If the display is closed prematurely, go through all windows that
look X11-y and remove them for future calculations. This is not
strictly needed as Xwayland should shut down orderly (thus no client
windows be there), but doesn't hurt to prepare in advance for the
cases where it might not be the case.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
We don't strictly need it for wayland compositors, yet there are
paths where we try to trigger those passive grabs there. Just
skip those on the high level code (where "is it x11" decisions
are taken) like we do with passive button grabs.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
Commit 09bab98b1e tried to avoid several workspace changes while in
window construction, but it missed a case:
If we have a window on a secondary monitor with no workspaces enabled
(so it implicitly gets on_all_workspaces = TRUE without requesting it)
and trigger the creation of a second window that has the first as
transient-for, it would first try to set the first workspace than the
transient-for window and then fallback to all/current workspace.
After that commit we only try to set the same workspace than the
transient-for window, but it gets none as neither is on a single workspace,
nor did really request to be on all workspaces.
Fixes crashes when opening transient X11 dialogs in the secondary monitor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/714
Similar to gtk commit f507a790, this ensures that the valist variant of
the marshaller is used. From that commit's message:
```
If we set c_marshaller manually, then g_signal_newv() will not setup a
va_marshaller for us. However, if we provide c_marshaller as NULL, it will
setup both the c_marshaller (to g_cclosure_marshal_VOID__VOID) and
va_marshaller (to g_cclosure_marshal_VOID__VOIDv) for us.
```
https://gitlab.gnome.org/GNOME/mutter/merge_requests/697
By putting `NULL` as the C marshaller in `g_signal_new`, you
automatically get `g_cclosure_marshaller_generic`, which will try to
process its arguments and return value with the help of libffi and
GValue.
Using `glib-genmarshal` and valist_marshallers, we can prevent this so
that we need less instructions for each signal emission.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/697
Double negations are the spawn of the devil, and is_non_opaque() is
used like that to find out if it's opaque most often, change the
function name to see the glass half full.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/698
The MetaBackgroundActor was ignoring the unobscured area altogether,
and just painted according to the clip area. Check the unobscured
area too, as it might well be covered by client windows.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/698
Wayland clients do this through the opaque region in the surface
actor. However X11 clients were considered fully transparent for
culling purposes, which may result in mutter painting other bits
of the background or other windows that will be painted over in
reality.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/698
We want to clip it away if 1) The window is fully opaque or
2) If it's translucent but has a frame (as explained in the comment
above). The code didn't quite match and we were only applying it on
case #2.
Case #1 is far more common, and saves us from pushing some drawing
that we know will be covered in the end.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/698
We first set the workspace to the transient-for parent's, and then
try to set on the current workspace. If both happen, we double the
work on adding/removing it from the workspace, and everything that
happens in result.
Should reduce some activity while typing on the Epiphany address
bar, as the animation results in a number of xdg_popup being created
and destroyed to handle the animation.
https://gitlab.gnome.org/GNOME/mutter/issues/556
The default configuration of libinput-gestures utility invokes wmctrl to
switch between desktops. It uses wmctrl because this works on both Xorg
and Wayland (via XWayland). Unfortunately, this generates the following
warning message every time, in both Xorg and Wayland desktops:
"Received a NET_CURRENT_DESKTOP message from a broken (outdated) client
who sent a 0 timestamp"
The desktop switch still works fine. The tiny code change here removes
this specific warning because, as the prefacing code comment originally
said and still says, older clients can validly pass a 0 time value so
why complain about that?
I also refactored the "if (workspace)" code slightly to avoid the double
test of the workspace value.
This is submitted for MR
https://gitlab.gnome.org/GNOME/mutter/merge_requests/671.
On X11, mutter needs to keep a grab on the locate-pointer key to be able
to trigger the functionality time the corresponding key combo is
pressed.
However, doing so may have side effects on other X11 clients that would
want to have a grab on the same key.
Make sure we only actually grab the key combo for "locate-pointer" only
when the feature is actually enabled, so that having the locate pointer
feature turned off (the default) would not cause side effects on other
X11 clients that might want to use the same key for their own use.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/647
Some special modifiers (typically "Control_L" used for locate-pointer in
mutter/gnome-shell or "Super_L" for overlay) must be handled separately
from the rest of the key bindings.
Add a new flag `META_KEY_BINDING_NO_AUTO_GRAB` so we can tell when
dealing with that special keybinding which should not be grabbed
automatically like the rest of the keybindings, and skip those when
changing the grabs of all keybindings.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/685
Glib stopped providing any fallback implementations on systems without
memmove() all the way back in 2013. Since then, the symbol is a simple
macro around memmove(); use that function directly now that glib added
a deprecation warning.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/689
Starting with commit 2db94e2e we try to focus a fallback default focus window
if no take-focus window candidate gets the input focus when we request it and
we limit the focus candidates to the current window's workspace.
However, if the window is unmanaging, the workspace might be unset, and we could
end up in deferencing a NULL pointer causing a crash.
So, in case the window's workspace is unset, just use the currently active
workspace for the display.
Closes https://gitlab.gnome.org/GNOME/mutter/issues/687https://gitlab.gnome.org/GNOME/mutter/merge_requests/688
Make it so it returns the closest ancestry MetaWindowActor if it
is a MetaSurfaceActor.
We need this for Wayland subsurfaces, so we can support actions like
Meta+Drag on them.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/604
Saves us from using MetaCompositor API, at a point where it might not
be initialized yet. Use the same window directly, since we already
have it handy.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/672
This is important when using a touchscreen or stylus instead of a mouse
or touchpad. If the cursor only gets hidden and the focus stays the
same, the window will still send hover events to the UI element under
the cursor causing unexpected distractions while interacting with the
touchscreen.
Fix this by emitting a visibility-changed signal from the cursor tracker
which then triggers a focus surface sync and always set the focus
surface to NULL when it's synced while the cursor is hidden.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/448
Allow checking whether the pointer is visible without accessing the
trackers internal is_showing property. While we don't need this just yet
for reading the visibility inside meta-wayland-pointer, it's useful when
implementing the logic to remove Clutter's focus when the cursor goes
hidden later.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/448
COPY_MODE_PRIMARY has two paths, automatically chosen. For debugging purposes,
e.g. why is my DisplayLink screen slowing down the whole desktop, it will be
useful to know which copy path is taken. Debug prints are added to both when
the primary GPU copy succeeds the first time and when it fails the first time.
This is not the full truth, because theoretically the success/failure could
change every frame, but we don't want to spam the logs (even in debug mode)
every frame. In practise, it should be rare for the success or failure to ever
change. Hence, saying what happened on the first time is enough. This does
indicate if it ever changes even once, too, so we know if that unexpected thing
happens.
The debug prints are per secondary GPU since there could be several.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/615
When the preferred path META_SHARED_FRAMEBUFFER_COPY_MODE_SECONDARY_GPU cannot
be used, as is the case for e.g. DisplayLink devices which do not actually have
a GPU, try to use the primary GPU for the copying before falling back to
read-pixels which is a CPU copy.
When the primary GPU copy works, it should be a significant performance win
over the CPU copy by avoiding stalling libmutter for the duration.
This also renames META_SHARED_FRAMEBUFFER_COPY_MODE_* because the new names are
more accurate. While the secondary GPU copy is always a GPU copy, the primary
copy might be either a CPU or a GPU copy.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/615
This bit of code was more or less duplicated in meta-renderer-native-gles3.c
and meta-wayland-dma-buf.c. Start consolidating the two implementations by
moving the *-gles3.c function into meta-egl.c and generalizing it so it could
also accommodate the meta-wayland-dma-buf.c usage.
The workaround in the *-gles3.c implementation is moved to the caller. It is
the caller's responsibility to check for the existence of the appropriate EGL
extensions.
Commit 6f59e4858e worked around the lack of
EGL_EXT_image_dma_buf_import_modifiers with the assumption that if the modifier
is linear, there is no need to pass it into EGL. The problem is that not
passing a modifier explicitly to EGL invokes implementation-defined behaviour,
so we should not have that workaround in meta-egl.c.
This patch intends to be pure refactoring, no behavioral changes. The one
change is the addition of g_assert to catch overwriting arbitrary memory.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/615
Using the master device, as we did, won't yield the expected result when
looking up the device node (it comes NULL as this is a virtual device).
Use the slave device, as the g-s-d machinery essentially expects.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/678
The device ID is kind of pointless on Wayland, so it might be better to
stick to something that works for both backends. Passing the device here
allows the higher layers to pick.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/676
As per commit f71151a5 we focus an input window if no take-focus-window accepts
it. This might lead to an infinite loop if there are various focusable but
non-input windows in the stack.
When the current focus window is unmanaging and we're trying to focus a
WM_TAKE_FOCUS window, we intent to give the focus to the first focusable input
window in the stack.
However, if an application (such as the Java ones) only uses non-input
WM_TAKE_FOCUS windows, are not requesting these ones to get the focus. This
might lead to a state where no window is focused, or a wrong one is.
So, instead of only focus the first eventually input window available, try to
request to all the take-focus windows that are in the stack between the
destroyed one and the first input one to acquire the input focus.
Use a queue to keep track of those windows, that is passed around stealing
ownership, while we protect for unmanaged queued windows.
Also, reduce the default timeout value, as the previous one might lead to an
excessive long wait.
Added metatests verifying these situations.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/660https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
When used it setups an X11 event monitor that replies to WM_TAKE_FOCUS
ClientMessage's with a XSetInputFocus request.
It can only be used by x11 clients on windows that have WM_TAKE_FOCUS atom set
and that does not accept input.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
When using gtk under X11 some WM related events are always filtered and not
delivered when using the gdk Window filters.
So, add a new one with higher priority than the GTK events one so that we can
pick those events before than Gtk itself.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
As per commit f71151a5 we were ignoring WM_TAKE_FOCUS-only windows as focus
targets, however this might end-up in an infinite loop if there are multiple
non-input windows stacked.
So, accept any focusable window as fallback focus target even if it's a
take-focus one (that might not reply to the request).
Added a stacking test to verify this.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/660https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
When looking for the best fallback focus window, we ignore it if it is in the
unmanaging state, but meta_stack_get_default_focus_window() does this is check
for us already.
So, ignore the redundant test.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
Since 4cae9b5b11, and indirectly before that as well, the
MetaMonitorManager::power-save-mode-changed is emitted even
when the power save mode didn't actually change.
On Wayland, this causes a mode set and therefore a stuttering.
It became more proeminent with the transactional KMS code.
Only emit 'power-save-mode-changed' when the power save mode
actually changed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/674
We need to set XdndAware and XdndProxy on the stage window if running
a X11 compositor, this is not necessary on wayland.
Takes over gnome-shell code doing this initialization.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/667
As per commit 040de396b, we don't try to grab when shortcuts are inhibited,
However, this uses the focus window assuming that it is always set, while this
might not be the case in some scenarios (like when unsetting the focus before
requesting take-focus-window to acquire the input).
So allow the button grab even if the focus window is not set for the display
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/663https://gitlab.gnome.org/GNOME/mutter/merge_requests/668
On Wayland, if a client issues a inhibit-shortcut request, the Wayland
compositor will disable its own shortcuts.
We should also disable the default handler for the button grab modifier
so that button events with the window grab modifiers pressed are not
caught by the compositor but are forwarded to the client surface.
That also fixes the same issue with Xwayland applications issuing grabs,
as those end up being emulated like shortcut inhibition.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/642
gnome-shell hardcodes a vertical one-column workspace layout, and
while not supporting arbitrary grids is very much by design, it
currently doesn't have a choice: We simply don't expose the workspace
layout we use.
Change that to allow gnome-shell to be a bit more flexible with the
workspace layouts it supports.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/618
Waking up gnome-shell and triggering JavaScript listeners of
`size-changed` every time a window was only moved was wasting a lot
of CPU.
This cuts the CPU requirement for dragging windows by around 22%.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/568
We currently don't handle the lack of DRM_CLIENT_CAP_UNIVERSAL_PLANES
KMS capability. Fail constructing a device that can't handle this up
front, so later made assumptions, such as presence of a primary plane,
are actually valid.
If we want to support lack of said capability, the required planes need
to be emulated by a dummy MetaKmsPlane object.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/665
The way code was structured made it easy to misunderstand things as the
surface actor of a window actor could change over time. So is not the
case, however, the intention of the corresponding "update" function was
so that a surface actor could be assigned to a window actor as soon as
the X11 window was associated with its corresponding wl_surface, if the
window in question came from Xwayland.
Restructure the code and internal API a bit to make it clear that a
window actor only once gets a surface actor assigned to it, and that it
after that point never changes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/659
X11 actors need to release the server data (pixmap and damage) before the
display is closed.
During the close phase all the windows are unmanaged and this causes the window
actors to be removed from the compositor, unsetting their actor surface.
However, in case a window is animating the surface might not be destroyed until
the animation is completed and a reference to it kept around by gjs in the shell
case. By the way, per commit 7718e67f all window actors (even the animating
ones) are destroyed before the display is closed, but this is not true for the
child surface, because the parent window will just unref it, leaving it around
if reffed somewhere else. This is fine for wayland surfaces, but not for X11
ones which are bound to server-side pixmaps.
So, connect to the parent MetaWindowActor "destroy" signal, releasing the x11
resources that implies detaching the pixmap (unsetting the texture) and removing
the damages.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/629https://gitlab.gnome.org/GNOME/mutter/merge_requests/660
free_damage and detach_pixmap functions are called inside dispose and an object
can be disposed multiple times, even when the display is already closed.
So, don't try to deference a possibly null-pointer, assigning the xdisplay too
early, as if the X11 related resources have been unset, the server might not be
open anymore. In fact, we assume that if we have a damage or a pixmap set,
the display is still open.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/660
In MetaWindowActor creation we're setting the compositor private (i.e. the
window actor itself) of a window before creating the surface actor, and so
passing to the it a window without its compositor side set.
Since the surface actor might use the parent actor, set this before updating
the surface.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/660
As per commit 80e3c1d set_surface_actor has been added, meant to do different
things depending on the backend, like connecting to signals under X11.
However, the vfunc isn't ever used, making the X11 surfaces not to react to
repaint-scheduled signal.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/660
Everytime the top window changes we connect/disconnect to the actor's destroy
signal, although as explained in commit ba8f5a11 this might be slower in case
the window actor has many other signal connections.
So, just track this using an ID.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/660
There were fallbacks in place in case IN_FORMATS didn't yield any usable
formats: the formats in the drmModePlane struct, and a hard coded array.
The lack of these fallbacks in place could result in a segfault as code
using the supported plane formats assumed there were at least something
in there.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/662
The display name is being used by the monitor manager to expose to name
to the DBUS API.
It is being rebuilt each time, so instead build the displa yname once
for the monitor and keep it around, with an API to retrieve it, so that
we can reuse it in preparation of xdg-output v2 support.
https://gitlab.gnome.org/GNOME/mutter/issues/645
