When malformed modes are provided and no valid mode spec is found, mutter
will eventually try to access the last element of an empty list. Warn about
this and exit properly.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1481
We will use a dedicated variable when transitioning to/from fullscreen state
and leave the previously used 'saved_rect' exclusively for transitioning
between floating and maximized state.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/801
Implements the "prior window window geometry dimensions" as described in
the documentation of 'xdg_toplevel' request 'unset_maximized':
"If available and applicable, the compositor will include the window
geometry dimensions the window had prior to being maximized in the
configure event."
and 'unset_fullscreen':
"The compositor may include the previous window geometry dimensions in
the configure event, if applicable."
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/792.
If this call is available, we can turn libX11 IO errors (fatal by definition)
into something we can recover from. Try to dispose all X11 resources and close
the display instead, so the compositor can survive the event.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1447
If the MetaX11Display abruptly closed when X11 windows were present,
we would still try to deal with them while freezing/thawing for the
"fade out" animation.
At the bottom of that, the X server may be gone, just try to cope
with it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1447
We're going to enforce some invariants a bit stricter and will only
allow allocating if an actor is mapped, not only visible.
Since actors are only mapped if their parent is mapped and stages are
hidden by default, we need to show the stage to ensure the actors are
mapped before we allocate them. So do that and call clutter_actor_show()
on the stage before fake-allocating the test actors.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
Bug 448183 fixed an issue with _NET_WM_MOVERESIZE_WINDOW not moving a
window by basing the resize on the current (new) rectangle instead of
the original rectangle.
While this fixes the issue with _NET_WM_MOVERESIZE_WINDOW, this also
causes windows with a size increment to move when the resize also
implies a move, such windows might drift while resizing.
Make sure to use the current rectangle for non-interactive resizes only.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/543
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
On interactive resize, mutter calculates the difference in size based on
the pointer location and relies on window constraints to ensure the
minimum size is honored.
Wayland however does asynchronous window configuration, meaning that not
checking for size hints early enough may lead to the window moving as
the locations was initially computed on a size which will be invalidate
by the client eventually.
Make sure to respect the client size hint on update_resize() so that we
don't end up with a window moving unexpectedly when the client
eventually acked the configuration.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1495
Many tablets have a native portrait mode panel, yet come with a keyboard dock,
where the device gets docked in landscape mode. To avoid the display being
on its side when mutter starts while the tablet is docked, we need to take
the accelerometer reported orientation into account even if there is a
tablet-mode-switch which indicates that the device is NOT in tablet-mode
(because it is docked).
Add special handling for the first time the "orientation-changed"
signal gets signalled by the orientation-manager, which happens after it
has successfully claimed the accelerometer with iio-sensor-proxy.
The added special handling of the initial "orientation-changed" signal
does a number of checks:
1. panel_orientation_managed is false because of the tablet-mode-switch and not
because of other reasons.
2. The device has a native portrait mode panel (and thus likely needs rotation
to display the image the right way up when docked).
If all these checks succeed then it continues with creating a new
monitors-config based on the orientation ignoring the panel_orientation_managed
value (for the initial/first "orientation-changed" signal only).
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
The orientation reported by the orientation_manager may have changed while
panel_orientation_managed was false. So when panel_orientation_managed
changes to true we should re-check the orientation.
This fixes the orientation not being correct when e.g. taking a 360 degree
hinges 2-in-1 in clamshell mode (so landscape orientation) and then folding
it into tablet mode while holding it in portrait orientation.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
Add support for the (mostly theoretical) case of an input-device
offering tablet-mode-switch functionality being unplugged.
This makes the has_tablet_switch handling identical to the has_touchscreen
handling, leading to more consistent code.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
Detect if a tablet-mode-switch device is already present when mutter
starts by checking for this from meta_seat_native_constructed. This
mirrors how we also set has_touchscreen from meta_seat_native_constructed.
This fixes tablet-mode-switches only being recognized when they are added
at runtime.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
Unconditionally setting has_touchscreen to check_touch_mode
when a new device gets added leads to has_touchscreen becoming
false when during runtime e.g. an USB keyboard gets plugged in.
Fix this by setting has_touchscreen to TRUE when check_touch_mode
is TRUE and leaving it alone otherwise.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
A first step towards abandoning the CoglObject type system: convert
CoglFramebuffer, CoglOffscreen and CoglOnscreen into GObjects.
CoglFramebuffer is turned into an abstract GObject, while the two others
are currently final. The "winsys" and "platform" are still sprinkled
'void *' in the the non-abstract type instances however.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1496
The spec states:
```
A sub-surface becomes mapped, when a non-NULL wl_buffer is applied
and the parent surface is mapped. The order of which one happens
first is irrelevant. A sub-surface is hidden if the parent becomes hidden,
or if a NULL wl_buffer is applied. These rules apply recursively
through the tree of surfaces.
```
In the past we relied on Clutter actor behaviour to realize the recursive
part - which then broke in
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/664
when we changed the actor hierachy in regards to subsurfaces.
Explicitly encode the desired behaviour in `MetaWaylandSubsurface`, fixing
the issue and making it future proof.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1384
Aligning windows manually with other windows has become less important
since the advent of tiling. This decreases the usefulness of edge
resistance, which in fact many users perceive as lag nowadays.
Account for that by limiting resistance to screen and monitor edges by
default, and only include windows when the control key is pressed.
https://bugzilla.gnome.org/show_bug.cgi?id=679609
Commit 033f0d11bf added a fallback in case the tile monitor wasn't
set before, but didn't actually check for a previously set value.
As a result, the "fallback" is not set unconditionally, which may
differ from the expected monitor: The tile monitor is determined
by the pointer position, while the window's monitor is the one
where the biggest part of the window resides on.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1389
It's pointless to call into functions that produce information that will
end up nowhere, so lets not. This will generate less angst when doing
more intense data gathering and string generation in debug log calls.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1467
The timestamp sent with _NET_WM_FRAME_DRAWN should be in "high
resolution X server timestamps", meaning they should have the same scope
as the built in X11 32 bit unsigned integer timestamps, i.e. overflow at
the same time.
This was not done correctly when mutter had determined the X server used
the monotonic clock, where it'd just forward the monotonic clock,
confusing any client using _NET_WM_FRAME_DRAWN and friends.
Fix this by 1) splitting the timestamp conversiot into an X11 case and a
display server case, where the display server case simply clamps the
monotonic clock, as it is assumed Xwayland is always usign the monotonic
clock, and 2) if we're a X11 compositing manager, if the X server is
using the monotonic clock, apply the same semantics as the display
server case and always just clamp, or if not, calculate the offset every
10 seconds, and offset the monotonic clock timestamp with the calculated
X server timestamp offset.
This fixes an issue that would occur if mutter (or rather GNOME Shell)
would have been started before a X11 timestamp overflow, after the
overflow happened. In this case, GTK3 clients would get unclamped
timestamps, and get very confused, resulting in frames queued several
weeks into the future.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1494
Mutter sends a proximity-in event before the required tablet tool
resource is properly allocated on the client. This is violating the
Wayland protocol. Because libwayland ignores events for objects it
doesn't know yet, this is not noticeable in most applications. However,
if https://gitlab.freedesktop.org/wayland/wayland/-/issues/176 gets
fixed, these applications would likely crash immediately. Therefore this
PR removes the responsible code which, again, shouldn't have any effect
on client applications as they ignore this event anyway.
Relevant part of the spec:
This event can be received when the tool has moved from one surface to
another, or when the tool has come back into proximity above the
surface.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1427
When we resize a window we send it configure requests with size
suggestion. Some clients, e.g. gnome-terminal will limit its size to a
discrete set given the font size resulting in the size often not being
respected completely, but used as a hint to find a size as large as
possible but not larger than the configured size.
When doing an interactive resize dragging the right or top side of a
window, this caused issues with the configured window size not matching
the one used by the client, as the configured position wouldn't be
correct for the actual size. Fix this by offsetting the position given
the size mismatch offset, making the position again in sync with the
size.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1447https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1477
