To avoid mostly going through struct fields in macros as we might soon
move those first to a WindowConfiguration & maybe even make the window
struct private with time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4111>
XPending() will do a recvmsg() syscall if there are no items in the queue.
In most cases, this is unnecessary because we know that there is data to be
read of the connection or there are items already read which simply need
to be processed.
Discovering both of those conditions can be done without recvmsg() in the
hot paths.
Before this path, every iteration of the main loop had the potential to
submit a recvmsg() syscall. This reduces that overhead drastically.
XFlush() on the other-hand knows if it needs to write data or not and will
do no IO in the case the buffer is empty.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3653
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4006>
The wrong type resulted in a crash when returning from the function,
because g_slist_free was called instead of g_free for the old_struts
list data pointers.
Fixes: e005d035c0c1 ("boxes: Define cleanup function for MetaStrut and use auto-pointers")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4028>
As with Xsettings, we want to use the X11 UI scaling factor to set the
cursor size, so that clients use a larger theme, both when using
`native-xwayland-scaling` and a physical layout mode.
Fixes: 6e8c7c5f84 ("Add experimental mode to use native scaling of Xwayland clients")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3992>
This makes Xsettings tell clients to be HiDPI again, when using the
physical layout mode.
Fixes: 6e8c7c5f84 ("Add experimental mode to use native scaling of Xwayland clients")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3992>
Allow scale-aware Xwayland clients to scale by an integer scale
themselves, instead of letting them render them at 1x scale and then
scaling up the texture, making it look blurry.
When monitor framebuffers are scaled, this special cases Xwayland and
sends output regions in a way that Xwayland think everything is N times
as large as the logical region, where N is the ceil of the max monitor
scale.
This is done by introducing a "stage" vs "protocol" coordinate space for
X11, where the "protocol" coordinate space is "stage" multiplied by a
scaling factor.
Xwayland thus will have its own "effective scale", sent via
wl_output.scale. The effective Xwayland scale is also used for the
internal MetaWaylandSurface scale internally, unless there is a viewport
dst size set on the same surface, in which case the scale is still set
to 1, to not interfere with wp_viewport semantics.
We're guarding this behind a new experimental feature
"xwayland-native-scaling", which can only come into effect when enabled
together with "scale-monitor-framebuffer".
[v2]:
Move stage_to_protocol/protocol_to_stage to generic window class.
This means parts that aren't aware of any windowing system specific
logic, only that coordinates originate from there for a given window,
can still get their coordinates properly handled.
In particular, this means coordinates from IBus that originates from the
client, can be scaled properly when that client is using X11.
Also make them properly introspected.
[v3]:
Split up coordinate transform API.
Make it one that takes a MtkRectangle, and another that takes a point.
This means the rounding strategy becames explicit when transforming a
point, while when it's a rectangle, it's still always "grow".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567>
This replaces the `legacy-ui-scaling-factor` entry in
`org.gnome.Mutter.DisplayConfig`, with the motivation being to no longer
expose X11 specific state via the monitor configuration API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567>
This means that for X11 sessions we'll do it before any windows are
mapped, and before any plugin implementation is started. Doing it before
a plugin is started is important, because things that the plugin does
during startup can have consequences on how compositing on Xorg works.
For the Xwayland case, we'll do it relatively in the setup phase. It
appears to have been harmless to do it later in the post-opened signal,
but there is no harm in doing it as one of the earlier steps.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3089
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3329>
Replace a boolean argument and a temporary MetaWindow struct field with
a `MetaPlaceFlag` passed where relevant. This includes
`meta_window_move_resize_internal()` and `meta_window_constrain()`, as
placement may happen during constraining, and also
`meta_window_force_placement()`.
The struct field (denied_focus_and_not_transient) was only ever set in
meta_window_show(), before meta_window_force_placement(), and
immediately unset as a side effect of that. In .._show() we'll always
force placement if the window wasn't already placed, and in
meta_window_constrain(), we'd only ever call meta_window_place() if the
window wasn't already placed, meaning the variable would only ever be
relevant during `meta_window_show()`. Having it as a flag makes that
relationship and temporary state clearer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3879>
This unbreaks building here. The compilation error was due to
MetaX11Display having an incorrect typedef in a now preprocessed out
part, which will be fixed in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3851>
In some cases, reparenting a window with its frame may fail; this seems
to happen especially during initialization of a window that may be
unmapped and re-mapped quickly and multiple times.
If this happens, we're never going to receive a remove event on the
stack tracker and so we may end up adding it twice to the list of the
windows to synchronize with the compositor, breaking its assumption that
the stack list is unique, and eventually leading to a crash because we
do not end up removing all the instances of a window on its destruction.
In particular we may end up in this situation:
Syncing Window 10485927: 0x555558863540 (actual xid is 10485927),
user time is 10485928 frame is 0x5555588715c0, frame xid 6291591
Syncing Window 14680081: 0x5555588664b0 (actual xid is 14680081),
user time is 14680082 frame is 0x555558871d80, frame xid 6291595
Syncing Window 6291460: 0x55555796dc80 (actual xid is 10485763),
user time is 10485764 frame is 0x555557a6f630, frame xid 6291460
Syncing Window 6291465: 0x555557a68af0 (actual xid is 14680067),
user time is 14680068 frame is 0x555557a73e80, frame xid 6291465
Syncing Window 6291509: 0x555557f9d830 (actual xid is 8388623),
user time is 0 frame is 0x555557fac780, frame xid 6291509
Syncing Window 6291586: 0x5555586e1690 (actual xid is 4194363),
user time is 0 frame is 0x55555886e550, frame xid 6291586
Syncing Window 6291591: 0x555558863540 (actual xid is 10485927),
user time is 10485928 frame is 0x5555588715c0, frame xid 6291591
Where the same meta window 0x555558863540 is added twice because that's
both mapped by the window itself (10485927) and by its frame (6291591).
This happens because for historical reasons the xids hash table managed
by the x11-display maps both the X11 windows, their frames and their
user time windows as the meta-window, and so if we don't filter out them
properly we end up duplicating the entries in the compositor list.
Such duplicates finally end up making mutter to crash in
meta_compositor_sync_stack() because we could end up trying to access
to an invalid window, given its actor has been destroyed but not all the
instances have been removed from the compositor windows list:
0x00007ffff71059 in meta_compositor_sync_stack (compositor=0x555555b8,
stack=0x555558701b80) at ../../mutter/src/compositor/compositor.c:773
773 if ((old_window->hidden || old_window->unmanaging) &&
(gdb) print old_window
$1 = (MetaWindow *) 0x0
So, in order to prevent this, check that XReparentWindow does not fail,
and in case of failure, reset the window state to the one it had before
we failed and more importantly, remove the association between the frame
X11 window and the MetaWindow, since this is not true anymore and so
that at the next stack synchronization there won't be any meta window
associated to that frame XID (unless there aren't further stack changes
impacting on that). Without this we would have instead waited for the
remove event that we predicted, but that could never happen because no
ReparentNotify is emitted in such case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3732>
Since we listen the X events in the same thread, and they are delivered
through the main loop, there's not any need to set the frame details on
windows before the reparent operation, because such action could fail.
So move the code order, as preparation for handling the error.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3732>
That was only there to force updating MetaFrame's bounds
but that is something that is already updated in
MetaWindowX11.move_resize_internal. So just drop all of that
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3254>
When a window with an input shape on its decoration window becomes
undecorated and meta_window_x11_update_input_region() gets called via
notify::decorated, the buffer_rect of the window has not been updated
yet while the decorated property has. This would lead to us comparing
the input shape of the client window to the buffer_rect which still
includes the decoration window. This would fail to detect the common
case when the client window has no input shape set, leading to the input
region being set to the size of the client window rather than NULL. If
the window is then resized later, the input shape would remain at the
previous size.
This was not a problem before 6bd920b35, because then we were (wrongly)
always comparing to the client_rect.
Fix this by choosing the correct rect for comparison depending on
whether the window is decorated.
Fixes: 6bd920b35 ("x11/window: Use correct bounding rect to determine NULL input region")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3451
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3720>
These functions are specific for X11 windows only so we should check
if the passed window is an X11 one, not just a MetaWindow since we're
casting to the actual type at later point.
Fixes changes part of commit e1e6534eb
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3727>
If a window sends a configure stacking request, we were comparing the
active window with the event window even though they were different
client types (e.g. wayland and x11).
This was leading to a critical error, so let's handle this by ensuring
that the active window is of the same kind of the event window before
doing x11-specific checks. Behaving as different applications in case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3727>
d991961ae changed this code from client rect to buffer rect to account
for the fact that for SSD windows the decorations are now included in
the bounding region, but it kept the variable name as client_area and
the comment was also still referring to the client rect.
Fixes: d991961ae ("x11: Use input region from frame window for decorated windows")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3697>
When updating the input region we check whether the input shape reported
by XShape matches the bounding region of a window to determine when it
was not set by the client. We would then use a NULL input region instead
which always matches the full size of the window. The code however was
using the client rect for this comparison, which does not include the
window frame. Since d991961a the frame is considered part of the input
region.
This meant that for SSD windows where the input region would match the
bounding region, we would not detect that and fail to set the input
region to NULL, but instead set it to the reported input shape.
Usually this would not be the case due to the GTK frame window having
shadows and a resize region, but in the presence of an issue that causes
GTK to wrongly detect _GTK_FRAME_EXTENTS as not supported, GTK would not
draw shadows or set an input shape. And due to GTK not updating its
input shape, there would be no further calls to
meta_window_x11_update_input_region() after the initial one.
The input region would therefore remain at the fixed size from the
initial call. This was causing windows to become click-through outside
of the region corresponding to their initial size after being resized.
Fixes: d991961ae ("x11: Use input region from frame window for decorated windows")
Related: https://gitlab.gnome.org/GNOME/gtk/-/issues/6558
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3404
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3697>
