Make the Wayland objects push the state relevant to their role to the
MetaSurfaceActor instead of MetaSurfaceActorWayland pulling the state
from the associated surface.
This makes the relationship between the actor and the objects that
constructs it more clear; the actor is a drawable that the protocol
objects control, not the other way around.
This will make it easier to "detach" a surface actor from a surface,
which is necessary when unmapping a window while the underlying surface
is yet to be destroyed and potentially reused.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/5https://bugzilla.gnome.org/show_bug.cgi?id=791938
This commit moves out non-core wl_surface related code into separate
code units, while renaming types to fit a common scheme. The changes
done are:
* ClutterActor based surface roles built upon
MetaWalyandSurfaceRoleActorSurface. This object has been renamed to
MetaWaylandActorSurface and related functionality has moved into
meta-wayland-actor-surface.c.
* The code related to roles backed by a MetaWindow (i.e. built upon
MetaWaylandShellSurface) was moved into meta-wayland-shell-surface.c
* The majority of subsurface related code was moved into into
meta-wayland-subsurface.c and the object was renamed
MetaWaylandSubsurface.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/5https://bugzilla.gnome.org/show_bug.cgi?id=791938
mutter would discard the shape region set by the client if its matches
the entire client area in meta_window_x11_update_shape_region().
However, if the window is later resized (maximized or other), the
compositor will fail to update the shape region properly for undecorated
windows because the shape region was discarded, which causes black areas
to appear in place of the updated areas.
If the client window is undecorated, keep the shape region even if when
it matches the client area.
https://gitlab.gnome.org/GNOME/mutter/issues/27Closes: #27
When the buffer modifier is DRM_FORMAT_MOD_LINEAR, we can use the
old code path. That means not specifying any modifier parameter.
It was an issue when the primary GPU was creating a linear GBM surface
and that a secondary GPU (not supporting modifiers) was trying to
import it. It was failing because the driver could not use the
import_modifiers extension even though it could in theory easily
import the buffer.
https://gitlab.gnome.org/GNOME/mutter/issues/18
We were retrieving the supported KMS modifiers for all GPUs even
though what we really need to intersect between these sets of
modifiers:
1) KMS supported modifiers for primary GPU if the GPU is used for
scanout;
2) EGL supported modifiers for secondary GPUs (different than the
primary GPU used for rendering);
3) GBM supported modifiers when creating the surface (already
taken care of by gbm_surface_create_with_modifiers());
https://gitlab.gnome.org/GNOME/mutter/issues/18
So the changes can be instantly applied while the tool is in proximity.
Before we would just do it on proximity-in, which doesn't provide a
good look&feel while modifying the tool settings in g-c-c.
https://gitlab.gnome.org/GNOME/mutter/issues/38Closes: #38
Checking correct state is responsibility of the ClutterInputFocus user, and
it is indeed possible to get a focused ClutterText while its
ClutterInputFocus didn't get itself focused (eg. lack of IM).
https://gitlab.gnome.org/GNOME/mutter/issues/36Closes: #36
If text_input_enable() is called when there no active IM (eg. running plain
mutter), some ClutterInputFocus method calls that are not allowed while
unfocused will end up called, triggering critical warnings.
If there is no IM return early here, all other calls are superfluous then.
We currently don't handle NULLs on these correctly, yet they can be
so when running nested. Just refrain from sending those wp_tablet(_pad)
events in that case.
The property has been 32 bits since around 2011 and has not changed, mutter
expects it to be 8 bits. The mismatch causes change_property to never
actually change the property.
https://gitlab.gnome.org/GNOME/mutter/issues/26Closes: #26
The window checks in the XPropertyEvent handler were wrong both
ways, so transfers would be left stale after the first chunk was
dealt with.
https://gitlab.gnome.org/GNOME/mutter/issues/1Closes: #1
Plain input stream read() calls don't provide hard guarantees about
the number of bytes read, but the async method callback sort of
relies on bytes being less than requested only when reaching the
end of the transmitted data. If that happens mid transfer, that
doesn't bode well.
This is actually the behavior of g_input_stream_read_all(), so
switch to using it.
This was done by the clutter X11 backend before prior to introducing
MetaRenderer, but during that work, enabling of said extension was lost.
Let's turn it on again.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
This is in order to force running as a X11 window manager/compositing
manager. Useful for debugging and other cases where the automatic
detection does not work as expected.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/15
If for whatever reason, there are stalled files in /tmp/.X11-unix/ the
bind() to the abstract socket will succeed but not the bind() to the
to the UNIX socket.
This causes gnome-shell/mutter to fail because it cannot start Xwayland
(while it could actually, by using a different display).
In case of failure to bind to the UNIX socket, try the next display
instead of failing, to avoid stalled entries in /tmp/.X11-unix.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/13
On drivers that do not support glGetTexImage2D (i.e. on GLES),
cogl_texture_get_data() has a "feature" that allows it to download
texture data by rendering the texture on an intermediate framebuffer
object and then reading back the data from there. However, this
feature requires the user to have previously set an "active"
framebuffer object in the context, which makes this very tricky
because it is not clear to the developer that he needs to do that
in order for some code to work on GLES (of course it works on
desktop GL, so nobody notices...) and additionally the code actually
crashes if an active fbo is not set!
This patch basically removes this feature in order to prevent
the crash and is in line with how this code has evolved in cogl-2.0:
https://git.gnome.org/browse/cogl/commit/?id=6d6a277b8e9a63a8268046e5258877ba94a1da5bhttps://bugzilla.gnome.org/show_bug.cgi?id=789961
The shortcut inhibitor protocol states that the “active” event should be
sent every time compositor shortcuts are inhibited on behalf of the
surface.
However, mutter would send that event only if the surface is focused,
which might not be the case if focus is on a shell surface.
Send the “active” event unconditionally to match the protocol
definition.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/10
There seems to be a kernel race when one disconnects an external
monitor connected to a DisplayPort via a USB-C adapter. The race
results in a connector being reported as connected, but without any
modes supported.
This had the side effect that we tried to set a preferred mode to
the first listed mode, but as no modes were available, we instead tried
to dereference the first element of a NULL array, causing a
segmentation fault.
Mitigate this by skipping adding output if no supported modes are
advertised and the output doesn't support scaling, while moving the
fallback path for calculating a preferred output mode to after possibly
adding the common modes, to avoid the unvolentary NULL dereference.
https://bugzilla.gnome.org/show_bug.cgi?id=789501
Opening and closing the device may result into XI2 grabs being cut short,
resulting into pad buttons being rendered ineffective, and other possible
misbehaviors. This is an XInput flaw that fell in the gap between XI1 and
XI2, and has no easy fix. It pays us for mixing both versions, I guess...
Work this around by keeping the XI1 XDevice attached to the
ClutterInputDevice, this way it will live long enough that this is not
a concern.
Investigation of this bug was mostly carried by Peter Hutterer, I'm just
the executing hand.
https://gitlab.gnome.org/GNOME/mutter/issues/7Closes: #7
