Since commit 8df2a1452c (As pointed out by Robert Mader) we just happened
do this check when doing the first lookup for a Wayland surface for a
XWayland window, when we are later notifying upon surface creation we just
set the relation with no further checks.
The cases pointed out in the comment (eg. window changing decoration) might
presumably happen in a quick enough sequence that we have two scheduled
associations on the fly, so move this check to the more generic
meta_xwayland_associate_window_with_surface() which is called on both
immediate and delayed paths.
https://gitlab.gnome.org/GNOME/mutter/issues/361
XWayland creates buffers of the combined size of all connected displays.
This can, especially on older but still in use hardware, exceed the limits
of the GPU.
If that is the case, use `CoglTexture2DSliced` instead of `CoglTexture2D`
https://gitlab.gnome.org/GNOME/mutter/merge_requests/447
Prior to this commit, MetaWaylandSurface held a reference to
MetaWaylandBuffer, who owned the texture drawn by the surface. When
switching buffer, the texture change with it.
This is problematic when dealing with SHM buffer damage management, as
when having one texture per buffer, damaged regions uploaded to one,
will not follow along to the next one attached. It also wasted GPU
memory as there would be one texture per buffer, instead of one one
texture per surface.
Instead, move the texture ownership to MetaWaylandSurface, and have the
SHM buffer damage management update the surface texture. This ensures
damage is processed properly, and that we won't end up with stale
texture content when doing partial texture uploads. If the same SHM
buffer is attached to multiple surfaces, each surface will get their own
copy, and damage is tracked and uploaded separately.
Non-SHM types of buffers still has their own texture reference, as the
texture is just a representation of the GPU memory associated with the
buffer. When such a buffer is attached to a surface, instead the surface
just gets a reference to that texture, instead of a separately allocated
one.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/199
What was actually done when calling meta_wayland_buffer_attach() was
that the texture was realized, so just call the function
`meta_wayland_dma_buf_realize_texture()` and call that.
This is in preparation to change how meta_wayland_buffer_attach() work.
https://gitlab.gnome.org/GNOME/mutter/issues/199
On X11, if a window cannot be maximized because its minimum size is
already larger than the output size, a request to maximize will be
ignored.
On Wayland, however, we would still honor the maximize request and
switch the window state to maximized, without actually moving the window
which leads to weird visual effects, as the window end up being
maximized in-place.
To avoid this, make sure the window has the maximize functionality
available prior to change its state in xdg-shell `set_maximized`
request.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/463
This was wrongly done just before enable, which is not right as
per the protocol. A side effect was that input purpose/hints were
eagerly reset before being applied, thus not properly honored,
noticed in the doing of emoji/numeric OSK panels.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/410
This adds the required bits to wayland surfaces and ties them up
to the compositor parts.
It is based on and very similar in nature to buffer transforms.
From the specification:
> The global interface exposing surface cropping and scaling
> capabilities is used to instantiate an interface extension for a
> wl_surface object. This extended interface will then allow cropping
> and scaling the surface contents, effectively disconnecting the
> direct relationship between the buffer and the surface size.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/323
This is done through gtk-shell ATM. If a window requests focus with
an invalid startup ID, just the demands-attention flag will be set.
The "did user interaction happen in between" checks are left to
meta_window_activate_full/meta_window_focus, by passing the timestamp
of the original launch request.
This version has 2 new requests:
- gtk_shell1.notify_launch notifies the compositor that the requesting
client shall launch another application. The given ID is expected to
be unique.
- gtk_surface1.request_focus notifies the compositor that a surface
requests focus due to it being activated. The given ID is passed to
this process through undetermined means, if it corresponds with a
current startup ID and there was no user interaction in between the
surface will be focused, otherwise it will demand attention.
Commit 25f416c13d added additional compilation warnings, including
-Werror=return-type. There are several places where this results
in build failures if `g_assert_not_reached()` is disabled at compile
time and the compiler misses a return value.
https://gitlab.gnome.org/GNOME/mutter/issues/447
Make meson link libmutter using -fvisibility=hidden, and introduce META_EXPORT
and META_EXPORT_TEST defines to mark a symbols as visible.
The TEST version is meant to be used to flag symbols that are only used
internally by mutter tests, but that should not be considered public API.
This allows us to be more precise in selecting what is exported and what is
not, without the need of a version-script file that would be more complicated
to maintain.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
As with the commits earlier, this also adds const qualifiers where
expected. However, the const variables are casted to non-const variants
so they can be passed to glib functions that take non-const variants but
expect const-like input.
A NULL argument is expected here in order to unset the selection,
meta_wayland_data_device_set_primary() accepts a NULL source, but
gtk_primary_selection_device.set_selection was not handling a
NULL wl_resource.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/335
When destructing a xdg_toplevel, we'll disassociate the actor from the
MetaWaylandSurface, to allow it to animate out. After having done this,
avoid trying to set it as unreactive when unsetting the window.
This fixes the runtime warning:
clutter_actor_set_reactive: assertion 'CLUTTER_IS_ACTOR (actor)' failed
Before processing the buffer damage region, intersect it with the buffer
rectangle to avoid trying to damage content outside the surface.
This fixes the runtime warning "GL error (1281): Invalid value"
happening when a client posts too large buffer damage larger.
This adds the required bits to wayland surfaces and ties them up
to the compositor parts.
The central part here is to recalculate the surface size accordingly
and to translate surface damage into buffer damage.
The choosen approach additionally lays groundwork for wp_viewporter
support, which is closely related in its nature.
A further explanation of buffer transforms from the specification:
> The purpose of this request is to allow clients to render content
> according to the output transform, thus permitting the compositor
> to use certain optimizations even if the display is rotated.
> Using hardware overlays and scanning out a client buffer for
> fullscreen surfaces are examples of such optimizations.
Commit 70036429bd mixed drag_origin and drag_surface, leading to warnings
and invisible drag icon. Fix this up so we correctly set up the feedback
actor. This will correctly display the DnD icon alongside the pointer.
It is meant to hold surfaces that require a ClutterActor, just like wl/xdg
shell surfaces and subsurfaces. Make it inherit from MetaWaylandActorSurface
so it gets that for free.
The type declaration is also made completely private, in order to avoid
cyclic dependency between meta-wayland-surface.h and
meta-wayland-actor-surface.h. We just require the GType fro assign_role()
anyway.
As with the Wayland display name, to avoid clashes with already an
running Xwayland or Xorg instance, override the X11 display name to
something less likely to cause a clash.
https://gitlab.gnome.org/GNOME/mutter/issues/193
For Wayland outputs, we do not expose the actual transformation because
mutter does not support wl_surface.set_buffer_transform yet, instead we
swap the logical width and height when the output is rotated.
However, a client wishing to use the physical size would get confused,
so if the output is rotated, rotate the physical dimensions as well for
consistency.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/369
It relied on indices in arrays determining tile direction and
non-obvious bitmask logic to translate to _GTK_EDGE_CONSTRAINTS. Change
this to explicitly named edge constraints, and clear translation methods
that converts between mutters and GTK+s edge constraint formats.
The touch handling code uses evdev API, thus will not work on other
backends. Thus, put touch handling code behind runtime backend checks
and only include the code when native backend support is enabled.
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.
We might unset focus, or already be out of focus (e.g. an X11 client or
clutter text entry is focused) when a text-input state is committed by
the client. We handled this before, except when text input was
explicitly disabled by the client, the Wayland text-input was in focus
by the input method, and it focused itself out.
Simplify the logic a bit by just dropping the state on the floor in all
cases where after any potential focus changes were done, we are not
focused.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/353
When repicking after a surface was destroyed, if the destroyed surface
was the drag focus, we'd try to focus-out from it after it was
destroyed, causing a NULL pointer dereference.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/336
To avoid a known race condition in the wl_output protocol documented in
https://phabricator.freedesktop.org/T7722, mutter delays the `wl_output`
destruction but nullify the `logical_monitor` associated with the
`wl_output` and the binding routine `bind_output()` makes sure not to
send wl_output events if the `logical_monitor` is `NULL` (see commit
1923db97).
The binding routine for `xdg_output` however does not check for such a
condition, hence if the output configuration changes while a client is
binding to xdg-output (typically Xwayland at startup), mutter would
crash while trying to access the `logical_monitor` which was nullified
by the change in configuration.
Just like `bind_output()` does for wl_output, do not send xdg-output
events if there is no `logical_monitor` yet.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/194
