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>
Except meta_window_x11_get_group, which is still used by GNOME Shell
and we can't make it a private API for now.
Will need further investigation and could be done as a future
step
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3555>
We might end up with a NULL opaque_region here in some circumstances
(client deleted _NET_WM_OPAQUE_REGION, or passed invalid data or a
region with 0 rectangles), account for that when freeing the variable.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2758>
These frames client will use a visual with alpha information, and
report the opaque frame shapes through the _NET_WM_OPAQUE_REGION
window property. We can use this information in the Mutter side
for accurate opaque shapes, despite X11 windows with frames now
being seen as possibly transparent.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2758>
Things like meta_compositor_destroy() and meta_compositor_add_window()
isn't intended to be used externally, and if they was, things would
probably fall apart rather quickly.
MetaCompositor also isn't introspected, meaning things that technically
belong to the compositing parts isn't easily available via some object,
but much take detours via other objects like MetaDisplay.
So move the API intended for internal usage to compositor-private.h, and
leave API that is meant to be expose in the public compositor.h.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
There's two meanings of "frame" there! Since SSD frames are now
rendered by an external client, and there are no actual mechanism
that ensures the frame did already get painted when the client did
respond to its NET_WM_FRAME_SYNC_REQUEST request, there may be
artifacts when resizing windows.
In order to get always the best visual result, we should actually
synchronize rendering with both the client window and the window
frame window.
This commit adds these mechanisms, so a sync alarm update is
expected on both windows until further resizes are allowed, this
ensures window and frame stay in sync, even after moving rendering
elsewhere.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
Replace the in-process implementation of frames with the external
frames client.
When a client window is created and managed by Mutter, Mutter will
determine whether it is a window that requires decorations and
hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME
property on the client window.
After the frames client created a window that has the _MUTTER_FRAME_FOR
property, Mutter will proceed to reparent the client window on the
frame window, and show them as a single unit.
Rendering and event handling on the frame window will be performed by
the external client, Mutter is still responsible for everything else,
namely resizing client and frame window in synchronization, and
managing updates on the MetaWindowActor.
In order to let the frame be managed by the external client, Mutter
needs to change the way some properties are forwarded to the client
and/or frame windows. Some properties are necessary to keep propagating
to the client window only, some others need to happen on the frame
window now, and some others needs to be propagated on both so they
are synchronized about the behavior.
Also, some events that were previously totally unexpected in frame
windows are now susceptible to happen, so must be allowed now.
MetaFrame in src/core/frame.c now acts as the wrapper of foreign
windows created by the frames client, from the Mutter side. Location,
size, and lifetime are still largely in control of Mutter, some
details like visible/invisible borders are obtained from the client
instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS
properties, respectively).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
Put the helper to use, in order to lift MetaWindow itself from this
accounting. As a bonus, the data itself now moved to the MetaWindowX11
private struct, since this may only happen with X11 windows (or its
Xwayland subclass).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
It's still used by e.g. GNOME Shell to produce fallback icons for X11
applications that doesn't come with a .desktop file. Geometry stays in
the generic class because it's used for minimize animations and is
configured by the panel (e.g. the one in gnome-shell-extensions).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2264>
Commit e28c1ab4 added a hints_have_changed() function to only
recalculate windows features when the WM_NORMAL_HINTS change.
That function hints_have_changed() however was merely checking whether
the various XSizeHints flags where flipped, which is not sufficient
because the hints may remain the same while the actual values are
changed.
Not checking for the actual value differences would prevent some windows
from being able to switch fullscreen.
Improve the helper function hints_have_changed() to check not only for
flags being flipped, but also for the values being changed for each
relevant XSizeHints flags being set currently.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1534
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1566>
The XSizeHints set by X11 clients give a hint to the window manager
about size increment, aspect ratio, base, minimum and maximum size, etc.
When an X11 client changes those values, there is a good chance that it
will affect the actual window size in some way, and mutter rightfully
queue a window resize in that case.
However, mutter does not check if any of the hints have actually changed
and unconditionally queue a window resize whenever a client changes its
WM_NORMAL_HINTS property.
That can be a problem when a zealous client such as xterm decides to
update its WM_NORMAL_HINTS property on resize, because in return mutter
will queue a non-user driven resize in the middle of user-driven events,
hence defeating the purpose of the META_MOVE_RESIZE_USER_ACTION flag.
To avoid that issue, make mutter a bit smarter and avoid queuing a
window resize if the XSizeHints haven't actually changed.
https://gitlab.gnome.org/GNOME/mutter/-/issues/543
Better to have the relevant object figure out whether it is a good
position to be unredirectable other than the actor, which should be
responsible for being composited.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
This removes the MetaWindowX11::priv pointer. It is replaced with a
meta_window_x11_get_private() helper function, and another method to get
the client rect without going through MetaWindowX11Private.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
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
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
On FreeBSD, gethostname is guarded by '__POSIX_VISIBLE >= 200112', which
requires either '_POSIX_C_SOURCE >= 200112' or '_XOPEN_SOURCE >= 600'.
Defining _XOPEN_SOURCE to 500 does not break the build because of
implicit declaration, but it defeats the purpose of defining the macro.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/638
It's a UI pattern that has been superseded by client-side decorations,
apps that used to set the hint have generally moved on to headerbars.
Given that and the limitation to server-side decorated X11 windows,
GTK4 removed the client-side API for setting the hint, it's time to
follow suite and retire the feature.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/221
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
