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>
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>
X11 server side focus changes, such as when a focus change was requested
by mutter for a globally active window, did not go through
meta_display_set_input_focus(), which is responsible for emitting the
`focus-window` signal. Since this signal is what triggers the display
server specific code to handle focus changes, this was leading to a
problem on Wayland where the focus remained on the last active Wayland
window when the focus got changed to a globally active XWayland window.
This commit now changes handling X11 server side focus changes to also
go through the code path that emits the signal while making sure to not
trigger another focus change and keeping the same serials as the
previous code to not interfere with future focus changes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3328
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3651>
If we happen to be changing focus to a window *while* taking focus
away from Clutter widgetry, we would unintendedly trigger reentrance
in a way that the old focused window remained in focus, by asking
to focus the default focus window in an untimely manner.
To handle this reentrancy, delay dropping the Clutter key focus
until the window focus changed, so that the focus change will look
up the default focused window in the workspace, and find the up to
date one.
Fixes: ae102ee301 ("x11: Refactor ClutterStage key focus management")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3467>
Trying to get the xwindow of a wayland only window would fail when
casting to a x11 window. Which happens as
meta_x11_display_set_input_focus is called whenever the focused
window changes, whether it is a wayland or x11 one
Fixes: bc9cd123e ("window: Move xwindow to WindowX11")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3506>
Integrate it into the code, instead of depending on MetaDisplay
notify::focus-window for it. Now, instead of focusing explicitly the
stage window, we focus a NULL window, and let the MetaX11Display
determine whether focus should go to the stage window if there's
a focused actor, or the no_focus_window if nothing has focus.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3269>
We currently offer the mechanism for GNOME Shell to implement, and
while this is not exercised often (our entries are typically surrounded
by a ClutterGrab ensuring key events, so this is reserved to grab-less
entries, probably there are some in extensions), this is arguably
something Mutter should cover by itself without GNOME Shell guidance.
This is only necessary on the X11 backend, although it is conceptually
more tied to the MetaX11Display connection, so perform the focus
tracking there only if not running as a Wayland compositor (i.e. --x11).
This avoids the only case where the low-level
meta_x11_display_set_input_focus_xwindow() function is used, or rather
makes it completely a MetaX11Display implementation detail, leaving
only the MetaDisplay API as the high-level entry points to handle
window key focus.
The public API that allowed GNOME Shell to implement these mechanisms
is also gone in this commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3269>
This is similar, but reserved for the crossing events induced by the
input shape changes on our overlay window. The mechanism in the previous
commit does again protect against this, so this mechanism may go away.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3267>
Focus follows mouse is meant to avoid focusing windows that happened
to pop up under the pointer, e.g. due to mapping, workspace changes,
etc... On X11, this has been done since ancient times through a
moderately complex synchronization mechanism, so mutter would know
to ignore crossing events caused on those situations.
This mechanism is much prior to XInput 2 though, where we may know
this in a more straightforward way: If the sourceid of the crossing
event is a logical pointer (i.e. equals deviceid), the crossing event
was triggered logically, and not through user input.
Perform this simpler check, and drop the existing mechanism to
ignore logically induced crossing events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3267>
Commit 9c3b130f67 changed slightly destruction order to handle use-after-free
situations, but missed a small new one introduced by the order change: The
MetaX11Display may schedule callbacks through MetaLaters, which depend on the
MetaCompositor, which is now freed before the MetaX11Display.
Since there is no winning move here, make the MetaX11Display aware of this
by avoiding to remove the callback if the MetaCompositor is already gone.
The MetaLaters infrastructure is already fully freed at this point (incl. the
data it contained), so this shouldn't be a leak.
Fixes: 9c3b130f67 ("display: Fix destruction order")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3247>
Keep a per-display list of error traps, so we don't mix them
together, and possibly deem unintended error traps outdated.
This means init/deinit calls are now stackable, and need to
happen evenly. In order to honor this, move the MetaX11Display
error trap destrution to finalize.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3230>
When the X11 display is actually XWayland there's no point to delay the
compositor selection, given that mutter itself is the compositor and
doing this may cause the first X11 client that starts not to receive the
right information (and in some cases misbehave).
Since some toolkits are not handling the compositor selection changes
properly at later times, let's make their life easier by just
initializing the selection as early as the other X11 properties, given
that in this case there's nothing to replace.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2472
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2970>
When a client (either Wayland or X11) is started, the window activation
will update the cursor to the "busy" cursor.
Mutter will then set the X11 cursor on the X11 root window to match that
so that X11 applications which do not explicitly set a cursor inherit
from that default (busy) cursor.
Updating the X11 cursor too often can hammer the X11 connection and
cause a deadlock with Xwayland.
Reload the X11 cursor in a later handler to avoid that issue.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2849>
Do the few remaining things that GDK is doing for us:
- Open and close the X11 Display
- Set up a GSource on the Display FD to handle events
- Allocate and free the content of XGenericEventCookie,
to "unroll" the few XInput2 events that Mutter still
does handle.
And remove the GdkDisplay we've so long relied on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2864>
From reading the comment in the top of the file, not for the first
time. Keep our own error handler and maintain our own list of
failable x11 sequences in MetaX11Display, so we can move away from
GTK's.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2864>
This API will be used by GNOME Shell to handle X11 events
in the relevant places, as a substitute to gdk_window_add_filter().
It is ATM still a bit ironic, since the Mutter X11 event handler
is itself a GdkFilterFunc, but it may move away from that eventually.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2779>
On X11, the stage itself is backed by an XWindow, and moving the
input focus elsewhere will bypass any Clutter-level grabs.
This effectively allows newly opened windows to steal the focus
from gnome-shell itself, which is clearly undesirable. To prevent
that, only allow moving the X11 focus to a Window when no grab is
in place, just like commit 50e89e376 did for the stage focus.
But particularly the updating of x11_display->focus_xwindow is not
prevented. Since it's more consistent to the MetaDisplay/MetaX11Display
dual focus tracking and across Wayland/X11 backends, ensure the X11
input focus is actually set on the last focus Window after the
grabs are gone and windows became interactable again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2832>
