The value returned from clutter_frame_get_target_presentation_time()
is always same as the value returned from
clutter_frame_get_min_render_time_allowed() when they are called
consecutively because both functions effectively return the value of
frame->has_target_presentation_time. This is with the assumption
that this variable is only ever modified by the same thread that
also executes on_after_update().
As such, a case where the former returns FALSE after the latter
returned TRUE is not possible, which means the line that sets
"target_presentation_time_us = 0;" is effectively unreachable.
Acknowledging this fact allows the call to
clutter_frame_get_target_presentation_time() to be moved outside the
"else" case and into the "if" condition itself. This is done in
preparation for the next commits.
No change in behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3521>
It adds the following clarification:
```
Starting from version 5, the invalid_format protocol error is sent if
all planes don't use the same modifier.
```
We already send an error, just the wrong one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3450>
This is the unified focus (key, IM, pads, ...) for the focus window.
Just like MetaWaylandPointer and others keep track of the "current"
surface, this is the "current" surface for those (not necessarily
the focused surface, e.g. in the case of compositor grabs).
Since this unified focus will exist regardless of keyboard
capabilities (e.g. even if just for "logical" focus like IM/clipboard
that does not depend on input devices), it does not make sense
to trigger a focus sync on keyboard capability changes, the focus
is staying the same, we however need to focus the keyboard interface
to the already existing focus when the capability is enabled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3511>
Instead of letting the MetaDisplay be aware of the Wayland compositor,
and take care of updating its focus. This makes the MetaWaylandCompositor
able to track focus changes by itself, using MetaDisplay as the source
of truth.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3511>
Finding the shm offset and shm stride for each plane is the main issue.
The rest is just creating multiple textures for each plane.
One assumption is that shm planes are always contiguous in memory so the
next plane comes directly after the size of the current plane.
The size of a plane is determined by the height and stride. There is
only a single stride parameter for shm buffers but we assume that the
first plane is always non-subsampled which gives us a number of "logical
elements" on one line (stride / bpp of the first plane). The stride of
the other planes is then the number of logical elements devided by the
subsampling factor and multiplied by the bpp of the plane.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3371>
ClutterInputFocus/GtkIMContext uses char based offset for
delete_surrounding, however, text_input_v3 uses byte based offset for
it. Currently only GTK with mutter can work correctly via text_input_v3
because they both forget to convert between char based offset and byte
based offset.
This commit fixes it in mutter by saving committed surrounding text in
MetaWaylandTextInput and converting char based offset to byte based
offset with the UTF-8 encoded surrounding text.
Fixes <https://gitlab.gnome.org/GNOME/mutter/-/issues/2146>.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2712>
A surface commit may change the buffer scale but not attach a new
buffer. In that case, the size of the previously attached buffer needs
to be consistent with the new buffer scale.
Fixes: 7649e2f3ab ("wayland/surface: Move buffer size check to meta_wayland_surface_commit")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3466>
meta_wayland_surface_get_buffer_width/height uses the currently applied
buffer, which may have a different size.
Fixes: 7649e2f3ab ("wayland/surface: Move buffer size check to meta_wayland_surface_commit")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3466>
Multiple reasons:
* More consistent with the protocol spec language.
* Ensures the size is checked and the protocol error sent from a
protocol processing context, instead of whatever context
meta_wayland_surface_commit might get called from.
* The latter implies that surface->resource is guaranteed to be valid.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3211
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3463>
The include is currently satisfied by
window-x11-private → iconcache → x11-display-private
The icon cache is about to be removed, so add the missing include
directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3452>
Split the struct into mutable and immutable parts. Access the mutable
parts via getters and the immutable parts via a single struct. This
avoids copying around the immutable parts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3280>
In profilers with a timeline or flame graph views it is a very common
scenario that a span name must be displayed in an area too short to fit
it. In this case, profilers may implement automatic shortening to show
the most important part of the span name in the available area. This
makes it easier to tell what's going on without having to zoom all the
way in.
The current trace span names in Mutter don't really follow any system
and cannot really be shortened automatically.
The Tracy profiler shortens with C++ in mind. Consider an example C++
name:
SomeNamespace::SomeClass::some_method(args)
The method name is the most important part, and the arguments with the
class name will be cut if necessary in the order of importance.
This logic makes sence for other languages too, like Rust. I can see it
being implemented in other profilers like Sysprof, since it's generally
useful.
Hence, this commit adjusts our trace names to look like C++ and arrange
the parts of the name in the respective order of importance.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3402>
When the desktop is focused instead of a window we want to tell the core
about this to handle focus-mode mouse. This is handled by looking for
CLUTTER_LEAVE events where the newly focused window is NULL.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
The following commits will make it possible to pass a NULL window to
display_handle_window_enter/leave to represent the cursor entering the
desktop. This means it can't be a method of the window class anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
To make sure a new wl_subsurface created for the same wl_surface won't
inherit the position from the wl_subsurface being destroyed.
v2:
* Move into permanently_unmap_subsurface
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
Instead of duplicating the code in both.
v2:
* Rename helper to make it clear(er) that it permanently unmaps the
sub-surface
* Move transaction allocation & commit into the helper
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
wl_subsurface_place_above/below need to hook it up to the parent
surface's pending state, so that it gets picked up next time the parent
is committed.
v2:
* Adapt to wl_subsurface_destructor not resetting sub-surface position
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
This is simpler, and makes sure it's called only once for each surface
in the transaction as committed.
v2:
* Use array for surface states with placement ops (Jonas Ådahl)
v3:
* Use GPtrArray instead of GArray (Robert Mader)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
This is necessary to make sure the unmapped sub-surface is no longer
visible.
v2:
* Use META_IS_WAYLAND_SUBSURFACE (Jonas Ådahl)
* Use same sequence of assignments in both cases
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
- Make Texture a parent GObject class and move the vtable funcs as vfuncs
instead of an interface as we would like to have dispose free the TextureLoader.
- Make the various texture sub-types inherit from it.
- Make all the sub-types constructors return a CoglTexture instead of their respective
specific type. As most of the times, the used functions accept a CoglTexture,
like all the GTK widgets constructors returning GtkWidget.
- Fix up the basics of gi-docgen for all these types.
- Remove CoglPrimitiveTexture as it is useless: It is just a texture underhood.
- Remove CoglMetaTexture: for the exact same reason as above.
- Switch various memory management functions to use g_ variant instead of the cogl_ one
Note we would still want to get rid of the _cogl_texture_init which is something
for the next commit
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3193>
There are existing extensions that implement desktop icons as
a combination of a GTK program and a small extension to make
the wayland window behave as if it was of type DESKTOP on X11.
That's quite painful, as it requires reimplementing WM behavior
that is already implemented in mutter itself (stacking, stickiness,
skip-taskbar, ...), as well as modifying gnome-shell to consider
the window in addition to "real" DESKTOP windows (workspace-switch
animations, ctrl-alt-tab, ...).
In addition to that, other extensions may also have special handling
of DESKTOP windows, and their code cannot easily be monkey-patched
to handle "alternative" desktop icons.
This whole game of whack-a-mole can easily be avoided by allowing
desktop-icons extensions to mark their desktop windows as DESKTOP,
so do just that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3305>
Change the order of events to adhere to the Wayland specification for
wl_keyboard.enter, which mandates:
> The compositor must send the wl_keyboard.modifiers event after
> this event.
Mutter currently sends the modifiers event before the enter event,
which may break applications that require information about the focused
surface in order to properly handle the modifiers.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2231
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3341>
With EI support wired to XTEST, and oeffis being enabled in Xwayland
means that XTEST will always go through the XDG portal.
While this the intended behavior for the general use case of Xwayland
running rootless on a desktop compositor, that breaks when Xwayland is
running on a nested compositor, because the portal is for the entire
session and not limited to the nested Wayland compositor.
Enable XDG portal support in Xwayland only when we managed to connect
to the GNOME session manager, which means we are running in a full
desktop session, and not in any form of nested mode.
This is determined by simply using the status returned by set_gnome_env()
which will fail if not connected to a GNOME Session manager.
See-also: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1586
See-also: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1170
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3047
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3303>
The function set_gnome_env() is used to pass environment variables
though DBus using the "org.gnome.SessionManager".
If that fails, it means we are not running in a full environment, which
might be useful to determine whether Xwayland should enable the portal
support.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3303>
The cursor surface is decided by the "current" surface; if that alone
changed (e.g. current surface was destroyed), we didn't update the
cursor, meaning it either got stuck, or got hidden if the client exited
completely.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3262>
When we call get_grab_info() to get the sequence, device and coordinates for
a touch window drag, as the device we use the device from the
MetaWaylandPointer, assuming that it's set to the core pointer.
In the case where there is no pointer device present on the seat (so no
mouse nor touchpad), the wayland pointer remains disabled though, and
pointer->device is NULL.
This means touch window dragging on hardware without pointer devices
present is broken (because MetaWindowDrag assumes that there's a valid
device passed in meta_window_drag_begin()). Fix it by taking the core
pointer directly from ClutterSeat instead of going the extra detour through
MetaWaylandPointer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3238>
Dropped obsolete Free Software Foundation address pointing
to the FSF website instead as suggested by
https://www.gnu.org/licenses/gpl-howto.html
keeping intact the important part of the historical notice
as requested by the license.
Resolving rpmlint reported issue E: incorrect-fsf-address.
Signed-off-by: Sandro Bonazzola <sbonazzo@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3155>
This changes how state is tracked by introducing an explicit state. We
need this since we use asynchronous calls to the out of process
component that handles actual inhibitation, including idleness.
This means if inhibitations changes rapidly, we might end up with an
incorrect state if we e.g. try to uninhibit while we're currently trying
to inhibit.
This is done by adding a state variable that accounts for the pending
state, as well as the active state, with a function that looks at the
current conditions to derive what state we should be in, and what state
we are in, to decide what the next action should be.
For example, if we're trying to inhibit, but now wants to uninhibit,
we'll wait for the inhibit call to complete, recheck what we want, which
would result in an async uninhibit call being made.
Fixes: 388b534062 ("wayland: Implement idle inhibit protocol")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3219>
Add methods, and change the API of some rarely used methods, in order
to make all event info currently held/necessary accessible through
ClutterEvent getters, instead of direct field access.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Stop taking a ClutterEvent and pass the essentials here (x/y/evtime),
we don't have a ClutterEvent handy in all places that we call this
API, and it feels awkward to create one just for calling this vmethod.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
