The current code assumes that the actor will always have the same
size and position of the background texture, but part of the implicit
contract of being a ClutterContent is being able to render itself
at any given actor, at any given size.
For example, if the current code is given an actor with 0x0+100+100
as geometry, and no clipped region, it'll render not the whole
background, but the 0x0+100+100 rectangle of the background. In
practice, the actor geometry acts like a "clip mask" over the
background texture, due to the assumption that the actor will
always have the same size of the monitor.
Make the calculation of the texture slices relative to the actor
box.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1302
MetaBackgroundActor is still necessary for culling purposes,
but now the actual rendering of the background is delegated
to MetaBackgroundContent, as well as the sizing information.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1302
MetaBackgroundContent is a ClutterContent implementation
that can render a background to any attached actor. Right
now, it preserves all the properties and the rendering
model of MetaBackgroundActor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1302
X11 window stacking operations are by nature prone to race conditions.
For example, we might queue a "raise above" operation, but before it
actually takes place, the sibling the window was to be rased above, is
withdrawn.
In these cases we'd log warnings even though they are expected to
happen. Downgrade these warnings to debug messages, only printed when
MUTTER_VERBOSE is set.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1300
Test that the stage-views list of ClutterActor is correct when moving an
actor, reparenting it, or hiding an actor up the hierarchy. Also test
that the "stage-views-changed" signal works as expected.
Don't test actor transforms for now because those aren't supported yet.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1196
We currently go through the whole tree of mapped actors on every paint
cycle to update the stage views actors are on. Even if no actors need
updating of their stage views, traversing the actor tree is still quite
expensive and shows up when using a profiler.
So tone down the amounts of full-tree traversals we have to do on every
paint cycle and only traverse a subtree if it includes an actor which
actually needs updating of its stage views.
We do that by setting the `needs_update_stage_views` flag to TRUE
recursively for all parents up to the stage when the stage-views list of
an actor gets invalidated. This way we end up updating a few more actors
than necessary, but can avoid searching the whole actor tree for actors
which have `needs_update_stage_views` set to TRUE.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1196
Add a new signal that's emitted when the stage views an actor being
painted on have changed, "stage-views-changed". For example this signal
can be helpful when tracking whether an actor is painted on multiple
stage views or only one.
Since we must clear the stage-views list when an actor leaves the stage
(actors that aren't attached to a stage don't get notified about the
stage views being changed/replaced), we also emit the new signal when an
actor gets detached from the stage (otherwise there would be an edge
case where no signal is emitted but it really should: An actor is
visible on a stage view, then detached from the stage, and then attached
again and immeditely moved outside the view).
Also skip the comparison of the old stage-views list and the new one if
nobody is listening to the signal to save some resources.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1196
There are certain rendering techniques and optimizations, for example
the unredirection of non-fullscreen windows, where information about the
output/stage-view an actor is on is needed to determine whether the
optimization can be enabled.
So add a new method to ClutterActor that allows listing the stage-views
the actor is being painted on: clutter_actor_peek_stage_views()
With the way Clutter works, the only point where we can reliably get
this information is during or right before the paint phase, when the
layout phase of the stage has been completed and no more changes to the
actors transformation matrices happen. So to get the stage views the
actor is on, introduce a new step that's done on every master clock tick
between layout and paint cycle: Traversing through the actor tree and
updating the stage-views the mapped actors are going to be painted on.
We're doing this in a separate step instead of inside
clutter_actor_paint() itself for a few reasons: It keeps the code
separate from the painting code, making profiling easier and issues
easier to track down (hopefully), it allows for a new
"stage-views-changed" signal that doesn't interfere with painting, and
finally, it will make it very easy to update the resource scales in the
same step in the future.
Currently, this list is only invalidated on allocation changes of
actors, but not on changes to the transformation matrices. That's
because there's no proper API to invalidate the transformation matrices
ClutterActor implementations can apply through the apply_transform()
vfunc.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1196
When the stage views the stage is shown on are changed, ClutterStage
currently provides a clutter_stage_update_resource_scales() method
that allows invalidating the resource scales of all actors. With the new
stage-views API that's going to be added to ClutterActor, we also need a
method to invalidate the stage-views lists of actors in case the stage
views are rebuilt and fortunately we can re-use the infrastructure for
invalidating resource scales for that.
So since resource scales depend on the stage views an actor is on,
rename clutter_stage_update_resource_scales() and related methods to
clutter_stage_clear_stage_views(), which also covers resource scales.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1196
While the layout manager of a ClutterActor does get properly unset when
destroying an actor, we currently forget to disconnect the
"layout-changed" signal from it.
So do that, and while at it, also switch to using the signal id for
disconnecting from the signal instead of
g_signal_handlers_disconnect_by_func(), which caused problems before
because it might traverse the signal handler list.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1281
We currently are confusing g_param_spec_enum and g_param_spec_flags for
the offscreen-redirect property of ClutterActor. Since it's actually a
flag, make it a flag everywhere.
Fun fact: This was already partly done with
d7814cf63e, but that commit missed the
setter.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1292
Just like the ClutterBindConstraint, the ClutterAlignConstraint should
listen to "queue-relayout" of its source actor, not
"notify::allocation". That's because the latter will queue a relayout
during an allocation cycle and might cause relayout loops.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1296
When an app disappears after some data from it has been copied to the
clipboard, the owner of the clipboard selection becomes a new memory
selection source. The initial reference this new selection source is
never unref'ed, which leads to this being leaked on the next clipboard
selection owner change.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1293
Using XDG_CONFIG_HOME allows users to place their keyboard configuration into
their home directory and have them loaded automatically.
libxkbcommon now defaults to XDG_CONFIG_HOME/xkb/ first, see
https://github.com/xkbcommon/libxkbcommon/pull/117
However - libxkbcommon uses secure_getenv() to obtain XDG_CONFIG_HOME and thus
fails to load this for the mutter context which has cap_sys_nice.
We need to manually add that search path as lookup path.
As we can only append paths to libxkbcommon's context, we need to start with
an empty search path set, add our custom path, then append the default search
paths.
The net effect is nil where a user doesn't have XDG_CONFIG_HOME/xkb/.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/936
Hiding a compositor stage is not something that's really supported, but
will still be used by tests, to get closer to a "fresh" stage for each
test case, when the tests eventually start using the mutter provided
stage.
It'll use that stage simply because creating standalone stages isn't
supported.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1289
The script parser only included G_PARAM_CONSTRUCT_ONLY parameters when
constructing objects. This causes issues if an object requires a
parameter to be set during construction, but may also change after. Fix
this by including G_PARAM_CONSTRUCT parameters when constructing script
objects as well.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1289
We would get the MetaDisplay from the backend singleton before creating
the MetaCompositor, then in MetaCompositor, get the backend singleton
again to get the stage. To get rid of the extra singleton fetching, just
pass the backend the MetaCompositor constructors, and fetch the stage
directly from the backend everytime it's needed.
This also makes it available earlier than before, as we didn't set our
instance private stage pointer until the manage() call.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1289
Start follow the convention used in ClutterFrameClock by including the
meaning as well as time granularity in the variable name. The
constructor takes the intended duration of the constructed timeline in
milli seconds, so call the constructor argument `duration_ms`. This is
done in preparation for adding more constuctors.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1289
Also fix a test that dependends on a specific element order in a list
that wasn't defined to have any particular order.
The frames per second is decreased from 30 to 10, to make the test less
flaky when running in CI.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1289
The shadow was disabled for the X11 client as it was far to unreliable
when comparing sizes.
It seems that the Wayland backend has been somewhat unreliable as well,
where some race condition causing incorrect sizes thus a flaky test.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1288
A "show" command calls gtk_window_show() and gdk_display_sync(), then
returns. This means that the X11 window objects are guaranteed to have
been created in the X11 server.
After that, the test runner will look up the window's associated
MetaWindow and wait for it to be shown.
What this doesn't account for is if mutter didn't get enough CPU time to
see the new window. When this happens, the 'default-size' stacking test
sometimes failed after hiding and showing the X11 window.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1288
If a test is not expected to succeed, then running it could be considered
to be a waste of resources, particularly if the failure might manifest
as an indefinite hang (see cogl!11), or if the test is likely to dump core
and trigger "expensive" crash-reporting mechanisms like systemd-coredump,
corekeeper, abrt or apport.
Skip the tests that are expected to fail. They can still be requested via
an environment variable, which can be set after fixing a bug to check which
tests are now passing.
Originally cogl!15, adapted for mutter's fork of cogl to use gboolean
instead of CoglBool.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1272
Signed-off-by: Simon McVittie <smcv@debian.org>
For actors which don't have needs_allocation set to TRUE and where the
new allocation wouldn't be different from the old one, the allocate()
vfunc doesn't have to be called. We still did this in case a parent
actor was moved though (so the absolute origin changed), because we
needed to propagate the ABSOLUTE_ORIGIN_CHANGED allocation flag down to
all actors.
Since that flag is now removed and got replaced with a private property,
we can simply notify the children about the absolute allocation change
using the existing infrastructure and safely stop allocating children at
this point.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1247
With commit 0eab73dc2e we introduced an optimization of not doing
allocations for actors which are hidden. This broke the propagation of
absolute origin changes to hidden actors, so if an actor is moved while
its child is hidden, the child will not get
priv->needs_compute_resource_scale set to TRUE, which means the resource
scale won't be updated when the child gets mapped and shown again.
Since we now have priv->absolute_origin_changed, we can simply check
whether that is TRUE for our parent before bailing out of
clutter_actor_allocate() and if it is, notify the whole hidden sub-tree
about the absolute origin change.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1247
Since clutter_stage_set_viewport() is only used inside clutter-stage.c
anyway, we can make it a static method. Also we can remove the x and y
arguments from it since they're always set to 0 anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1247
When getting the last allocation using
clutter_actor_get_allocation_box(), Clutter will do an immediate
relayout of the stage in case an actor has an invalid allocation. Since
the allocation is always invalid when the allocate() vfunc is called,
clutter_stage_allocate() always forces another allocation cycle.
To fix that, stop comparing the old allocation to the new one to find
out whether the viewport changed, but instead use the existing check in
_clutter_stage_set_viewport() and implement the behavior of rounding the
viewport to the nearest int using roundf() (which should behave just as
CLUTTER_NEARBYINT()) since we're passing around floats anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1247
When manipulating the allocation of a ClutterActor from an allocate()
vfunc override, clutter_actor_set_allocation() is used to let Clutter
know about the changes.
If the actors allocation or its absolute origin did not change before
that, this can also affect the actors absolute_origin_changed property
used by the children to detect changes to their absolute position.
So fix this bug (which luckily didn't seem to affect us so far) and set
priv->absolute_origin_changed to TRUE in case the origin changes inside
clutter_actor_set_allocation_internal(). Since this function is always
called when our allocation changes, we no longer need to update
absolute_origin_changed in clutter_actor_allocate() now.
Since a change to the absolute origin always affects the resource scale,
too, we also need to move that check from clutter_actor_allocate() here
to make sure we update the resource scale.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1247
Since the introduction of the shallow relayout functionality it's
possible to start an allocation cycle at any point in the tree, not only
at the stage. Now when starting an allocation at an actor that's not the
stage, we'd still look at the absolute_origin_changed property of this
actors parent, which might still be set to TRUE from the parents last
allocation.
So avoid using the parents absolute_origin_changed property from the
last allocation in case a shallow relayout is being done and always
reset the absolute_origin_changed property to FALSE after the allocation
cycle.
This broke with the removal of the ABSOLUTE_ORIGIN_CHANGED
ClutterAllocationFlag that was done in commit dc8e5c7f.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1247
When we created the DMA buffer backed CoglFramebuffer, we handed it over
to CoglDmaBufHandle which took its own reference. What we failed to do
was to release our own reference to it, effectively leaking it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1283
The stream will clean up the buffers, so let it do that before we
destroy them under its feet. Note that it'll only do this after the
following PipeWire commit:
commit fbaa4ddedd84afdffca16f090dcc4b0db8ccfc29
Author: Wim Taymans <wtaymans@redhat.com>
Date: Mon Jun 1 15:36:09 2020 +0200
stream: allow NULL param and 0 buffers in disconnect
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1283
wait_reconfigure ensures that the whole configure back and forth
completes before continuing. Doing this after every state change ensures
that we always end up with the expected state, thus fixes flakyness of
the restore-position stacking test.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1279
This cannot be made to work reliably. Some factoids:
- Internal devices may be connected via USB.
- The ACPI spec provides the _PLD (Physical location of device) hook to
determine how is an USB device connected, with an anecdotal success
rate. Internal devices may be seen as external and vice-versa, there is
also an "unknown" value that is widely used.
- There may be non-USB keyboards, the old "AT Translated Set 2 Keyboard"
interface does not change on hotplugging.
- Libinput has an internal series of quirks to classify keyboards as
internal of external, also with an "unknown" value.
These heuristics are kinda hopeless to get right by our own hand. Drop
this external keyboard detection in the hope that there will be something
more deterministic to rely on in the future (e.g. the libinput quirks
made available to us directly or indirectly).
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2378
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2353https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1277
When r is 128 or more, running tests compiled with the undefined behaviour
sanitizer (ubsan) reports:
test-utils.c:312:45: runtime error: left shift of 128 by 24 places cannot be represented in type 'int'
which indeed it cannot. Force the type to be unsigned 32-bit so that we
get defined behaviour.
Similarly, in test-atlas-migration, the left-shifted guint8 is promoted
to int, which again does not have enough non-sign bits available to
left-shift a value >= 128 by 24 bits. Again, force the shift to be done
in unsigned 32-bit space.
This was originally cogl!22, but applies equally to mutter's fork of cogl.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1271
Signed-off-by: Simon McVittie <smcv@debian.org>
According to the cogl_bitmap_new_for_data documentation, the data is not
copied, so the application must keep the buffer alive for the lifetime
of the CoglBitmap. Freeing it too early led to a use-after-free in the
cogl unit tests. With that fixed, the test passes, so remove the known
failure annotation.
This AddressSanitizer trace is from the original cogl, but the bug and
fix apply equally to mutter's fork of cogl:
==6223==ERROR: AddressSanitizer: heap-use-after-free on address 0x62100001a500 at pc 0x7f3e2d4e7f4e bp 0x7ffcd9c41f30 sp 0x7ffcd9c416e0
READ of size 4096 at 0x62100001a500 thread T0
#0 0x7f3e2d4e7f4d (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x96f4d)
#1 0x7f3e260c7f6b in util_copy_box ../src/gallium/auxiliary/util/u_surface.c:131
#2 0x7f3e268c6c10 in u_default_texture_subdata ../src/gallium/auxiliary/util/u_transfer.c:67
#3 0x7f3e26486459 in st_TexSubImage ../src/mesa/state_tracker/st_cb_texture.c:1480
#4 0x7f3e26487029 in st_TexImage ../src/mesa/state_tracker/st_cb_texture.c:1709
#5 0x7f3e26487029 in st_TexImage ../src/mesa/state_tracker/st_cb_texture.c:1691
#6 0x7f3e2644bdba in teximage ../src/mesa/main/teximage.c:3105
#7 0x7f3e2644bdba in teximage_err ../src/mesa/main/teximage.c:3132
#8 0x7f3e2644d84f in _mesa_TexImage2D ../src/mesa/main/teximage.c:3170
#9 0x7f3e2cd1f7df in _cogl_texture_driver_upload_to_gl driver/gl/gl/cogl-texture-driver-gl.c:347
#10 0x7f3e2ccd441b in allocate_from_bitmap driver/gl/cogl-texture-2d-gl.c:255
#11 0x7f3e2ccd441b in _cogl_texture_2d_gl_allocate driver/gl/cogl-texture-2d-gl.c:462
#12 0x7f3e2ce3a6c0 in cogl_texture_allocate cogl/cogl-texture.c:1398
#13 0x7f3e2ce3e116 in _cogl_texture_pre_paint cogl/cogl-texture.c:359
#14 0x7f3e2cdee177 in _cogl_pipeline_layer_pre_paint cogl/cogl-pipeline-layer.c:864
#15 0x7f3e2cd574af in _cogl_rectangles_validate_layer_cb cogl/cogl-primitives.c:542
#16 0x7f3e2cdd742f in cogl_pipeline_foreach_layer cogl/cogl-pipeline.c:735
#17 0x7f3e2cd5c8b0 in _cogl_framebuffer_draw_multitextured_rectangles cogl/cogl-primitives.c:658
#18 0x7f3e2cd60152 in cogl_rectangle cogl/cogl-primitives.c:858
#19 0x5570a71ed6a0 in check_texture tests/conform/test-premult.c:103
#20 0x5570a71ed946 in test_premult tests/conform/test-premult.c:159
#21 0x5570a71df0d6 in main tests/conform/test-conform-main.c:58
#22 0x7f3e2bcd809a in __libc_start_main ../csu/libc-start.c:308
#23 0x5570a71e0869 in _start (/home/smcv/src/debian/cogl/tests/conform/.libs/test-conformance+0x33869)
0x62100001a500 is located 0 bytes inside of 4096-byte region [0x62100001a500,0x62100001b500)
freed by thread T0 here:
#0 0x7f3e2d5581d7 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x1071d7)
#1 0x5570a71ed58b in make_texture tests/conform/test-premult.c:69
previously allocated by thread T0 here:
#0 0x7f3e2d558588 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107588)
#1 0x7f3e2d384500 in g_malloc ../../../glib/gmem.c:99
This was originally cogl!12.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1274
Signed-off-by: Simon McVittie <smcv@debian.org>
In clutter_text_queue_redraw_or_relayout() we check whether the size
of the layout has changed and queue a relayout if it did, otherwise we
only queue a redraw and save some resources.
The current check for this also queues a redraw if the actor has no
valid allocation. That seems right on the first glance since the actor
will be allocated anyway, but we actually want to call
clutter_actor_queue_relayout() again here because that also invalidates
the size cache of the actor which might have been updated and marked
valid in the meantime.
So make sure the size cache is always properly invalidated after the
size of the layout changed and also call clutter_actor_queue_relayout()
in case the actor has no allocation.
This fixes a bug where getting the preferred width of a non-allocated
ClutterText, then changing the string of the ClutterText, and then
getting the preferred width again would return the old cached width (the
width before we changed the string).
The only place where this bug is currently happening is in the overview,
where we call get_preferred_width() on the unallocated ClutterText of
the window clone title: When the window title changes while the
ClutterText is unallocated the size of the title is going to be wrong
and the text might end up ellipsized or too large.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1150
Move Wayland support (i.e. the MetaWaylandCompositor object) made to be
part of the backend. This is due to the fact that it is needed by the
backend initialization, e.g. the Wayland EGLDisplay server support.
The backend is changed to be more involved in Wayland and clutter
initialization, so that the parts needed for clutter initialization
happens before clutter itself initialization happens, and the rest
happens after. This simplifies the setup a bit, as clutter and Wayland
init now happens as part of the backend initialization.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
On X11 we don't update the texture in certain circumstances, such as if
the surface is a fullscreen unredirect, or doesn't have a Pixmap. On
Wayland we only want to avoid updating the texture if there is no
texture, but as this is handled implicitly by MetashapedTexture, we
don't need to try to emulate the X11-y conditions in the generic layer
and instead just have the implementations handle update processing
themself.
This doesn't have any functional changes, but removes a vfunc from
MetaSurfaceActorClass.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
It's effectively used by mutter by abusing a ClutterTimeline to scedule
updates. Timelines are not really suited in places that is done, as it
is really just about getting a single new update scheduled whenever
suitable, so expose the API so we can use it directly.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
We could call clutter_stage_schedule_update() and it wouldn't actually
schedule anything, as the master frame clock only tries to reschedule if
1) there is an active timeline, 2) there are pending relayouts, 3) there
are pending redraws, or 4) there are pending events. Thus, a call to
clutter_stage_schedule_update() didn't have any effect if it was called
at the wrong time.
Fix this by adding a boolean state "needs_update" to the stage, set on
clutter_stage_schedule_update() and cleared on
_clutter_stage_do_update(), that will make the master clock reschedule
an update if it is TRUE.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
We need to use the framebuffer of the view instead of the onscreen
framebuffer when painting the damage region, otherwise the redraw clips
on rotated monitors won't be shown correctly.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
Compare, tile by tile, whether actual damage actually changed any
pixels. While this requires mmap():ing DMA buffers and comparing their
content, we should only ever use shadow buffers when we're using the
software renderer, meaning mmap() is cheap as it doesn't involve any
downloading.
This works by making the shadow framebuffer double buffered, while
keeping track of damage history. When we're about to swap the onscreen
buffer, we compare what part of the posted damage actually changed,
records that into a damage history, then given the onscreen buffer age,
collect all actual damage for that age. The intersection of these tiles,
and the actual damage, is then used when blitting the shadow buffer to
the onscreen framebuffer.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1157https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
Move the damage history tracking to a new ClutterDamageHistory helper
type. The aim is to be able to track damage history elsewhere without
reimplementing the data structure and tracking logic.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
This fixes the last "copy everything" paths when clutter doesn't
directly paint onto the onscreen framebuffer. It adds a new hook into
the stage view called before the swap buffer, as at this point, we have
the swap buffer damag regions ready, which corresponds to the regions we
must blit according to the damage reported to clutter.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
The rest didn't change, so only actually paint the part of the offscreen
that was composited as part of the stage painting. In practice, this
means that, unless a shadow buffer is used, we now only paint the
damaged part of the stage, and copy the damage part of the offscreen to
the onscreen.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
We failed to use the buffer age when monitors were rotated, as when they
are, we first composite to an offscreen framebuffer, then later again to
the onscreen. The buffer age checking happened on the offscreen, and an
offscreen being single buffered, they can't possible support buffer
ages.
Instead, move the buffer age check to check the actual onscreen
framebuffer. The offscreen to onscreen painting is still always full
frame, but that will be fixed in a later commit.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
The manual "cleaning" of the viewport and projection state is removed,
and we only ever try to invalidate the state so that it'll be updated
next time. Change the API used to reflect this.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
The stage would fetch the front framebuffer and set the viewport and
projection matrix, but if we are going to more than one front buffer,
that won't work, so let the stage just pass the viewport and projection
matrix to the view and have the view deal with the framebuffer(s).
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
Will be used for logging to identify what view a log entry concerns. For
the native and nested backend this is the name of the output the CRTC is
assigned to drive; for X11 it's just "X11 screen", and for the legacy
"X11 screen" emulation mode of the nested backend it's called "legacy
nested".
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
There's no reason to notify the surface that its geometry changed when
the visibility of the actor changes. This is only needed to update the
outputs of the surface, so do that directly instead.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1235
We started listening to notify::mapped with commit
5eb5f72434 in order to emit
wl_surface.leave events consistently when a surface gets hidden. This
caused a problem with the ClutterClones used in the overview, since
those temporarily map and unmap the windows for painting, spamming
wl_surface.leave and enter events to all surfaces.
We can easily fix that by also treating mapped clones as mapped, which
means the surface should also be on a wl_output when the overview is
shown.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1141https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1235
All existing users of clutter_actor_has_mapped_clones() actually want to
know whether the actor is being cloned by a visible clone, it doesn't
matter to them if that clone is attached to an actor somewhere else in
the tree or to the actor itself.
So make clutter_actor_has_mapped_clones() a bit more convenient to use
and also check the clones of the parent-actors in that function.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1235
We started listening to "notify::position" on surface actors with commit
08e4cb54. This commit was done to fix a regression from commit cf1edff9,
which forgot to handle some cases like the actual WindowActor and not
the SurfaceActor (which is a child of the WindowActor) moving (that was
fixed by listening to MetaWindows "position-changed" signal). Also that
commit introduced meta_wayland_surface_update_outputs_recursively(),
which updates the outputs of all (sub-)surfaces in case any position
changed and made sure subsurfaces also get their outputs updated in case
the parent actor moved.
Connecting to the "notify::position" signal, which the above commit also
did is now superflous though because position changes will queue a
relayout and the actors allocation will change during the next
allocation cycle, notifying the "allocation" property which we also
listen to.
So save some resources and stop listening to that signal.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1235
The comment in _clutter_actor_get_allocation_clip() explicitely notices
that it doesn't need the behavior of doing an immediate relayout as
clutter_actor_get_allocation_box() does. The comment is also still valid
since the code calling _clutter_actor_get_allocation_clip() checks for
priv->needs_allocation just before.
So let's just use the allocation directly here instead of going through
that function.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1264
We don't have enough Xlib code in mutter ...
Joking aside, it can be useful to make the cursor invisible
without hiding it, for example for replacing the actual cursor
with an actor in gnome-shell; the real cursor should still
update the focus surface in that case, and not sneak into
screenshots or -casts.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1244
We're iterating inside the PipeWire loop when detecting PipeWire errors,
and shouldn't destroy the PipeWire objects mid-iteration. Avoid this by
first disabling the stream src (effectively stopping the recording),
then notifying about it being closed in an idle callback. The
notification eventually makes the rest of the screen cast code clean up
the objects, including the src and the associated PipeWire objects, but
will do so outside the PipeWire loop iteration.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1251https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1251
In the native backend, the MetaRenderer manages the view by creating one
per CRTC, but until now the MetaStageX11 managed the view for the X11
backend. This caused some issues as it meant meta_renderer_get_views()
not returning anything, and that the view of the X11 screen not being a
MetaRendererView, while in the other backends, all views are.
Fix this by moving the view management responsibility to
MetaRendererX11Cm, and have MetaStageX11 only operate on it via
meta_renderer_x11_cm_*() API. The MetaRendererX11Cm takes care of making
sure the view is always added to the list in the renderer, and turning
X11 screen sizes into "layouts" etc.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1251
"Legacy" is a misleading name, it's just how the native backend and the
X11 backend behaves differently. Instead rename it to 'add_view()' and
add the sanity check to the caller.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1251
A DMA buffer might not be able to scanout, and in that case the import
with GBM_BO_USE_SCANOUT will fail. Handle that by failing to scanout,
effectively falling back to compositing.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1261
Since PIDs are inherently insecure because they are reused after a
certain amount of processes was started, it's possible the client PID
was spoofed by the client.
So make sure users of the meta_window_get_pid() API are aware of those
issues and add a note to the documentation that the PID can not be
totally trusted.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1180
Since the PID of a window can't change as long as the window exists, we
can safely cache it after we got a valid PID once, so do that by adding
a new `window->client_pid` private property.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1180
The shell uses the PID of windows to map them to apps or to find out
which window/app triggered a dialog. It currently fails to do that in
some situations on Wayland, because meta_window_get_pid() only returns a
valid PID for x11 clients.
So use the client PID instead of the X11-exclusive _NET_WM_PID property
to find out the PID of the process that started the window. We can do
that by simply renaming the already existing
meta_window_get_client_pid() API to meta_window_get_pid() and moving
the old API providing the _NET_WM_PID to meta_window_get_netwm_pid().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1180
ClutterBoxLayout's layout policy of using the generic ClutterActor
align/expand properties for children that are expanded and a custom
meta otherwise is confusing, in particular as the x-fill/y-fill
defaults don't match the default CLUTTER_ACTOR_ALIGN_FILL align.
StBoxLayout's own custom child meta (which was deprecated last
cycle) is probably the only consumer. And luckily, the St meta
uses different x-fill/y-fill default that match the ClutterActor
defaults, so removing it will not affect code that doesn't use
the deprecated properties themselves.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1265
This stuff has been deprecated for a very long time, and given that
ClutterBoxLayout is most commonly used via StBoxLayout, the impact of
removing it should be low. It will however open the door to further
cleanups.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1265
We're going to remove the "allocation-changed" signal from ClutterActor
since it's no longer needed now that ClutterAllocationFlags are gone.
So listen to "notify-allocation" instead, which has been the recommended
thing to do for some time now anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245
The ABSOLUTE_ORIGIN_CHANGED allocation flag is only really useful to
propagate the information of the absolute origin of an actor having
changed inside Clutter. It wasn't used anywhere else besides for some
debug messages and it probably shouldn't be used in custom layout
implementations anyway since 1) actors shouldn't have to be aware of
absolute allocation changes and 2) it doesn't factor in changes to the
transformation matrix of a parent.
Also the propagation of absolute origin changes using this flag broke
with commit 0eab73dc2e and now hidden actors are no longer notified
about those changes.
Additionally, this flag gets in the way of a few potential optimizations
since it has to be propagated even if the allocation box of the child
hasn't changed, forcing a reallocation of the child.
So replace this flag with a simple new private property of ClutterActor
absolute_origin_changed, but keep the exact same behavior for now.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245
Since we now only layout the children ourselves in case the actor
implementation doesn't override the allocate vfunc, we can remove
clutter_actor_maybe_layout_children() and move the functionality inside
clutter_actor_real_allocate().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245
Now that we no longer have the DELEGATE_LAYOUT we expect all actors
overriding the allocate() vfunc to allocate their children themselves.
Since clutter_actor_set_allocation() is only called from custom
vfunc_allocate() implementations, the condition in
clutter_actor_maybe_layout_children() would always fail, which makes
calling the function useless anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245
The CLUTTER_DELEGATE_LAYOUT flag is unintuitive and makes the allocation
process inside Clutter unnecessarily complicated. It's very easy for
actors overriding the allocate() vfunc to layout their children
themselves (in fact most of them do this), and it also never made sense
that clutter_actor_set_allocation() does eventually layout children.
There was no ClutterActor implementation in mutter or gnome-shell which
actually used the DELEGATE_LAYOUT flag, but even without it, it's fairly
easy to archive the same behavior now: In the allocate() override,
adjust the allocation as wanted, then chain up to the parent vfunc
without calling clutter_actor_set_allocation().
So remove the CLUTTER_DELEGATE_LAYOUT flag, which will allow making the
relayout code in Clutter a bit easier to follow.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245
We're going to remove allocation flags, so stop depending on the
DELEGATE_LAYOUT flag in ClutterStage and call
clutter_layout_manager_allocate() directly, which is pretty
straightforward.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245
They all checked that the remote session service talked with the
correct peer, and some of them did check that there is an associated
screencast session.
Add a new check for the session being started (as it's state is
decoupled with screencast session availability) and move all checks
to a function that is called from all input-oriented DBus methods.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1254https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1258
The public API to get the parent actor, clutter_actor_get_parent() does
a type check whether the actor is actually a ClutterActor. In case of
_clutter_actor_apply_relative_transformation_matrix(), which is called
recursively and very often during the paint process, this type check
shows up with almost twice the amount of hits than the actual matrix
multiplication.
So use the parent pointer directly in some code paths that are executed
very often and avoid the expensive type checking there, we can do that
since both places are not public API.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1259
It was removed in 3.34 as part of 6ed5d2e2. And we thought that was the
only thread that might exist and use X11. But the top gnome-shell crasher
in 3.36 seems to suggest otherwise.
We don't know what or where the offending thread is, but since:
1. We used XInitThreads for years already prior to 3.34; and
2. Extensions or any change to mutter/gnome-shell could conceivably use
threads to make X calls, directly or indirectly,
it's probably a good idea to reintroduce XInitThreads. The failing assertion
in libx11 is also accompanied by a strong hint:
```
fprintf(stderr, "[xcb] Most likely this is a multi-threaded client " \
"and XInitThreads has not been called\n");
```
https://bugs.launchpad.net/bugs/1877075
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1252https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1256
Reverting the scale and offset applied to the damage history can be done
in one step, using a few less temporary allocations by passing the
offset right away to a new scale_offset_and_clamp_region() function.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
Since the damage history region is tracked per-view, all the regions it
includes should be inside the current view anyway, so don't
unnecessarily intersect that region with the view.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
Since we now check for the buffer age before setting up the
fb_clip_region, that region will be set to the full extents of the view
in case the buffer age is invalid. This in turn means we don't have to
do this again later and can simply fill the damage history with the
fb_clip_region that's already set for us.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
Since a NULL redraw_clip means that a full view redraw should be done
and an empty redraw clip may never be set (see the width/height checks
in clutter_stage_view_add_redraw_clip()), the fb_clip_region should
always be set to a reasonable region that's either the whole view or
individual regions inside the view.
So make sure that's actually the case by warning and that the
fb_clip_region isn't empty, which allows dropping another few lines of
code.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
Right now we're checking for the DISABLE_CLIPPED_REDRAWS debug flag
after creating the fb_clip_region and adjusting the redraw_clip. That
means that if may_use_clipped_redraw was TRUE, the redraw_clip will
still be set to the region and thus cause the stage to only be partially
redrawn. Since we don't push a clip to the framebuffer though
(use_clipped_redraw is now FALSE), parts of the view will get corrupted.
To fix that, disable clipped redraws right away if the debug flag is
set. This also allows removing the may_use_clipped_redraw bool and
replacing it entirely with use_clipped_redraw.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
We already have a better way to paint the redraw clip: Painting the
damage region paints the individual rects of the clip region and not
only the bounding rect.
So stop painting an outline around the redraw clip bounding rect when
CLUTTER_DEBUG_REDRAWS is set.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
While this is meant as an optimzation to only use the scissor clip and
not the stencil buffer if there's only one clip rectangle, it's not
needed since this optimization is going to be applied to region clips
anyway inside _cogl_clip_stack_gl_flush() (see cogl-clip-stack-gl.c).
So remove the unnecessary optimization here and rely on cogl-clip-stack
to do it for us.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
This was introduced with commit 9ab338d7b6 because the clipping of
fractionally scaled redraws caused glitches, it seems like this is no
longer needed nowadays, so let's remove it.
This should make obscured region culling work a bit better for
fractionally scaled framebuffers because because we overdraw a slightly
smaller region than the actually damaged one. We still do overdraw
though since the clipping region is stored using integers and thus
any non-integer values have to be extended to the bounding rect.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
It doesn't make sense to set the redraw clip when painting the stage if
clipped redraws are disabled. That's because when visualizing the redraw
clip and any new redraws are clipped, the old visualiziations would
remain visible, leaving multiple confusing rectangles on the screen.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
When the wallpaper image is larger than the monitor resolution we already
use mipmapping to scale it down smoothly in hardware. We use
`GL_TEXTURE_MIN_FILTER` = `GL_LINEAR_MIPMAP_LINEAR` for the highest quality
scaling that GL can do. However that option is designed for 3D use cases
where the mipmap level is changing over time or space.
Since our wallpaper is not changing distance from us we can improve the
rendering quality even more than `GL_LINEAR_MIPMAP_LINEAR`. To do this we
now set `GL_TEXTURE_MAX_LEVEL` (if available) to limit the mipmap level or
blurriness level to the lowest resolution (highest level) that is still
equal to or higher than the monitor itself. This way we get the benefits
of mipmapping (downscaling in hardware) *and* retain the maximum possible
sharpness for the monitor resolution -- something that
`GL_LINEAR_MIPMAP_LINEAR` alone doesn't do.
Example:
Monitor is 1920x1080
Wallpaper photo is 4000x3000
Mipmaps stored on the GPU are 4000x3000, 2000x1500, 1000x750, ...
Before: You would see an average of the 2000x1500 and 1000x750 images.
After: You will now only see the 2000x1500 image, linearly sampled.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1003
It's very useful to have common functions for easily creating a monitor
test setup for all kinds of tests, so move create_monitor_test_setup()
and check_monitor_configuration() and all the structs those are using to
monitor-test-utils.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1243
We're going to move some structs from monitor-unit-tests.c to
monitor-test-utils.h and some names are currently clashing with the
struct names here, so rename those to be specific to the
MonitorStoreUnitTests.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1243
check_monitor_test_clients_state() is a function that's only meant to be
used in the monitor-unit-tests, and since we're going to move the
functions for creating MonitorTestSetups into a common file, this
function is going to be in the way of that. So move the checking of the
test client state outside of check_monitor_test_clients_state().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1243
We're going to move the functions for building MonitorTestSetups to the
common monitor-test-utils.c file.
To make building test setups a bit more straightforward in case no
TestCaseExpect is wanted, change create_monitor_test_setup() to take a
MonitorTestCaseSetup instead of a MonitorTestCase as an argument.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1243
Commit e06daa58c3 changed the tested values to use corresponding valid
enum values instead of negative ones. Unfortunately that made one value
become a duplicate of an existing one and also in part defeated the original
intention of checking the implementation of
`meta_output_crtc_to_logical_transform`.
Use `meta_monitor_transform_invert` to fix both shortcomings.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1242
One of the important classes in Mutter's handling of client textures is
the `MetaShapedTexture`. This commit adds a few gtk-doc comments which
explain its purpose, with special attention to the viewport methods.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1210
Since we're now connecting to one more signal of MetaWaylandOutput, keep
signal connections in one place and move connecting the
"output-destroyed" signal to surface_entered_output() and disconnecting
it to surface_left_output().
This also allows us to use the "outputs_to_destroy_notify_id" as a
simple set and rename it to "outputs".
While at it, also use g_hash_table_destroy() instead of
g_hash_table_unref() since destroy is more clear than unref and does the
same thing in this case.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1230
When hotplugging a new monitor, we recreate all the MetaWaylandOutputs
and need to emit leave events to the surfaces for the old wl_outputs and
enter events for the newly created ones.
There's a race condition though: We might update the monitors a surface
is on (and thus emit enter/leave events for the wl_outputs) before the
Wayland client is registered with the new wl_output (ie. the
bind_output() callback of MetaWaylandOutput was called), which means we
don't send an enter event to the client in surface_entered_output().
Since MetaWaylandSurface now has the MetaWaylandOutput in its outputs
hashtable, it thinks the client has been notified and won't send any
more enter events.
To fix that, make MetaWaylandOutput emit a new signal "output-bound"
when a client bound to the output and make all surfaces which are on
that output listen to the signal. In the signal handler compare the
newly added client to the client the surface belongs to, and if it's the
same one, send an enter event to that client.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1230
The "output-destroyed" signal is used for notifying MetaWaylandSurfaces
that an output they are shown just got invalid (for example because a
monitor hotplug happened).
While we delay the destroying of outputs by 10 seconds since commit
1923db97 because of a race-condition, it doesn't make sense to wait 10
seconds until we let surfaces know that an output was destroyed.
So move the emission of the "output-destroyed" signal to
make_output_inert(), which is called before we start the 10 seconds
delay.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1230
When tiling, we want to set the tile monitor. To not have to do this
from the call site, make meta_window_tile() fall back to the current
monitor if nothing set it prior to the call.
This will make it more convenient for test cases to test tiling
behavior.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
The test tests that (for both X11 and Wayland) that:
* The client unmaximizes after mapping maximized to a predictable size
* That the client unmaximizes to the same size after toggling maximize
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
This makes sure that a client has properly responded to a configure
event it itself triggered. In practice, this is just two 'wait'
commands, with a 'dispatch' in between, which is needed because a single
one does not reliably include the two way round trip happening when e.g.
responding to a unmaximize configure event triggered by a unmaximize
request.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
The 'assert_size' command checks that the size of the window, both
client side and compositor side, corresponds to an expected size set by
the test case.
The size comparison can only be done when the window is using 'csd', in
order for both the client and server to have the same amount of
understanding of the title bar. For ssd, the client cannot know how
large the title bar, thus cannot verify the full window size.
Sizes can be specified to mean the size of the monitor divided by a
number. This is that one can make sure a window is maximized or
fullscreened correctly.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
Gtk is quite buggy and "fluid" in how it handles the shadow margins for
windows under X11. The "size" of the window fluctuate between including and
excluding a shadow margin in a way that causes issues, as there are no
atomic update of any state going on.
In order to avoid running into those particular issues now, lets get rid
of shadows so the margins are always zero, when the client is using the
X11 backend.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
To get some kind of consistency between what 'resize' means for the
compositor and the client, make the size correspond to the "frame rect"
of the window, i.e. the window geometry in the Wayland case, and the
window size including the titlebar in the X11 case.
This is so that the window size later can be reliably compared both in
the compositor and in the client using the same expected dimensions.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
When toying with the test client to try to reproduce issues (e.g.
writing commands on stdin to create and manipulate windows), when you
write a command incorrectly you'll get a warning printed to standard
out. The problem, however, is that it doesn't include a line break in
the end, meaning when you type the correct command, it won't be on a new
line.
Fix this minor annoyance by adding line breaks to all warning messages.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
The test client could already understand the resize command, but they
could not be added to metatests as the command was not properly plumbed
via the test runner. Establish the plumbing for the resize command so
that resize tests can be added.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
We only test the meson-build job, so there's no point to save artifacts for
the other test-build only builds.
So, only save meson logs artifacts (with a default gitlab expiration time)
for the other build-without-* jobs
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1236
While we don't have an high number of tests, we still have some code
coverage and so we can track this via gitlab CI, given that it supports it
natively.
So add gcovr to the DockerFile dependency, build with -Db_coverage=true
meson native parameter, and add another manual job to make ninja to generate
the coverage reports on requests or in any master or tag ref.
Keep the artifacts around to be able to browse the generated HTML files and
eventually print the text reports so that they can be parsed by gitlab.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1236
This removes ClutterAnimation and related tests. ClutterAnimation has
been deprecated for a long time, and replacements exist and are used by
e.g. GNOME Shell since a while back.
This also disables a few relatively unrelated interactive tests, as they
rely on ClutterAnimation to implement some animations they use to
illustrate what they actually test.
As interactive tests currently are more or less untestable due to any
interaction with them crashing, as well as they in practice means
rewriting the tests using non-deprecated animation APIs, they are not
ported right now. To actually port the interactive tests, it needs to be
possible to fist interact with them.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1192
In the past, it was a odd mix of possible different types, all coalesced
into an unsigned integer. Now, hovewer, it's always a
ClutterAnimationType, so lets change the name of getter, setter and
property to what it really is.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1192
When memfd_create isn't used, the file isn't sealed. Therefore, we
should skip test_readonly_seals on the fallback case. This fixes
compilation error on FreeBSD 12, which does not support memfd_create.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1229
We were iterating through evcodes, but using API that expects Clutter button
numbers. Instead of transforming those to Clutter numbers to have those translated
back, use the inner seat API that already takes evcodes.
Fixes stuck buttons keys after a virtual device is destroyed while those are
pressed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1239
The CLUTTER_ACTOR_IN_REPARENT and the CLUTTER_IN_REPARENT flag are never
set and the logic for skipping unmap, unrealize and the emission of the
"parent-set" signal during reparents has been solved differently by
leaving out the CHECK_STATE and EMIT_PARENT_SET flags when calling
add_child_internal() and remove_child_internal().
The only place where those REPARENT flags are theoretically still useful
is in the clutter_actor_verify_map_state() debugging function, but that
is never called during reparent anyway, so simply leave the comment
regarding reparent there.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1228
Move to center uses all monitors for calculating work area.
This can lead to an unexpected behaviour on some monitor
configurations resulting in current window being split between
monitors. We should move window to the center of the active display.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1073
Inhibiting remote access means any current remote access session is
terminated, and no new ones can be created, until remote access is
uninhibited. The inhibitation is ref counted, meaning there can be more
than one inhibitor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1212
When resizing an X11 window with client side decorations, the shadow is
clipped by the frame bounds so that we don't need to paint the shadow
under the opaque areas covered by the window and its frame.
When the X11 client uses the EMWH synchronization mechanism (like all
gtk-3 based clients), the actual window may not be updated so that the
actual window and it frame may be behind the expected window frame
bounds, which gives the impression of de-synchronized shadows.
To avoid the issue, keep a copy of the frame bounds as a cache and only
update it when the client is not frozen so that the clipping occurs on
the actual content.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1178https://gitlab.gnome.org/GNOME/mutter/merge_requests/1214
The redraw clip that's painted together with the damage region has to be
copied earlier than we do right now. That's because if
PAINT_DAMAGE_REGION is enabled, buffer age is disabled and thus
use_clipped_redraw is FALSE. That means the redraw_clip is updated and
set to the full view-rect. If we copy the queued_redraw_clip after that,
it's also going to be set to the full view-rect. So copy the redraw clip
a bit earlier to make sure we're actually passing the real redraw clip
to paint_damage_region().
Also keep the queued_redraw_clip around a bit longer so it can actually
be used by paint_damage_region() and isn't freed before that.
While at it, move paint_damage_region() from swap_framebuffer() into
clutter_stage_cogl_redraw_view() so we don't have to pass things to
swap_framebuffer() only for debugging.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1104https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1208
It takes coordinates in stage coordinate space, and will result in
a screen cast stream consisting of that area, but scaled up by the scale
factor of the view that overlaps with the area and has the highest scale
factor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
Will be used by the stage to not paint the overlays. We skip all
overlays since overlays are only ever used for pointer cursors when the
hardware cursors cannot or should not be used.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
These phase callbacks are not intended to be inovked when something
secondary is painting the stage, such as a screen cast stream, or
similar. Thus, only invoke the callbacks when there is a view associated
with the paint context, which will not be the case for offscreen
painting.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
Either onto a framebuffer, or into a CPU memory buffer. The latter will
use an former API and then copy the result to CPU memory. The former
allocates an offscreen framebuffer, sets up the relevant framebuffer
matrices and paints part of the stage defined by the passed rectangle.
This will be used by a RecordArea screen cast API. The former to paint
directly onto PipeWire handled dma-buf framebuffers, and the latter for
PipeWire handled shared memory buffers.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
If there is a paint context available (i.e. for the phases that are
during the actual stage paint), pass it along the callbacks, so that
the callback implementations can change their operation depending on the
paint context state.
This also means we can get the current view from the paint context,
instead of the temporarily used field in the instance struct.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
A paint flag affects a paint operation in ways defined by the flags.
Currently no flags are defined, so no semantical changes are defined
yet. Eventually a flag aiming to avoid painting of cursors is going to
be added, so that screen cast streams can decide whether to include a
cursor or not.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
If drmModePageFlip() or custom_page_flip_func fails, process_page_flip() was
forgetting to undo the ref taken for that call. This would leak page_flip_data.
The reference counting works like this:
- when created, ref count is 1
- when calling drmModePageFlip, ref count is increased to 2
- new: if flip failed, ref count is decreased back to 1
- if calling schedule_retry_page_flip(), it takes a ref internally
- if calling mode_set_fallback(), it takes a ref internally
- all return FALSE paths have an explicit unref
- return TRUE path has an explicit unref
This issue was found by code inspection and while debugging an unrelated issue
with debug prints sprinkled around. I am not aware of any end-user visible
issues being fixed by this, as the leak is small and probably very rare.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1209
When testing a laptop with intel and DisplayLink devices, attempting to set the
DL output as the only active output resulted in GNOME/Wayland freezing. The
main event loop was running fine, but nothing on screen would get updated once
the DL output become the only one. This patch fixes that issue.
DisplayLink USB 3 devices use an out-of-tree kernel DRM driver called EVDI.
EVDI can sometimes fail drmModePageFlip(). For me, the flip fails reliably when
hotplugging the DL dock and when changing display configuration to DL only.
Mutter has a workaround for failing flips, it just calls drmModeSetCrtc() and
that succeeds.
What does not work reliably in the fallback path is Mutter keeping track of the
pageflip. Since drmModePageFlip() failed, there will not be a pageflip event
coming and instead Mutter queues a callback in its stead. When you have more
than one output, some other output repainting will attempt to swap buffers and
calls wait_for_pending_flips() which has the side-effect of dispatching any
queued flip callbacks. With multiple outputs, you don't get stuck (unless they
all fail the exact same way at the same time?). When you have only one output,
it cannot proceed to repaint and buffer swap because the pageflip is not marked
complete yet. Nothing dispatches the flip callback, leading to the freeze.
The flip callback is intended to be an idle callback, implemented with a
GSource. It is supposed to be called as soon as execution returns to the main
event loop. The setup of the GSource is incomplete, so it will never dispatch.
Fix the GSource setup by setting its ready-time to be always in the past. That
gets it dispatched on the next cycle of the main event loop. This is now the
default behavior for all sources created by meta_kms_add_source_in_impl().
Sources that need a delay continue to do that by overriding the ready-time
explicitly.
An alternative solution could have been to implement GSource prepare and check
callbacks returning TRUE. However, since meta_kms_add_source_in_impl() is used
by flip retry code as well, and that code needs a delay through the ready-time,
I was afraid I might break the flip retry code. Hence I decided to use
ready-time instead.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1209
According to the XSetSelectionOwner libX11 documentation:
[...] If the owner window it has specified in the request is later
destroyed, the owner of the selection automatically reverts to None,
but the last-change time is not affected.
This is indeed visible through the selection_timestamp field in
XFixesSelectionNotify events.
Use this to check whether the selection time is recent-ish (thus
likely coming from an explicit XSetSelectionOwner request) and honor
the client intent by setting a "NULL" owner. If the selection time
is too old, it's definitely an indication of the owner client being
closed, the scenario where we do want the clipboard manager to take
over.
This fixes two usecases:
- X11 LibreOffice / WPS clear the selection each time before copying
its own content. Mutter's clipboard manager would see each of those
as a hint to take over, competing with the client over selection
ownership. This would simply no longer happen
- Password managers may want to clear the selection, which would be
frustrated by our clipboard manager.
There's a slight window of opportunity for the heuristics to fail
though, if a X11 client sets the selection and closes within 50ms, we
would miss the clipboard manager taking over.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1206
The X11 selection source was being preserved after unsetting its
ownership. This is no leak as it would be eventually replaced by
another source, or destroyed on finalize. But it's pointless to
keep it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1206
Test the two modes of MetaAnonymousFile, MAPMODE_SHARED and
MAPMODE_PRIVATE and make sure they don't leak data to other FDs when
writing to an FD provided by `meta_anonymous_file_get_fd` even though
the data of both FDs is residing in the same chunk of memory.
We do all the reading tests using mmap instead of read() since using
read() on shared FDs is going to move the read cursor of the fd. That
means using read() once on the shared FD returned by
meta_anonymous_file_get_fd() in MAPMODE_PRIVATE breaks every subsequent
read() call.
Also test the fallback code of MetaAnonymousFile in case `memfd_create`
isn't used for the same issues.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1012
Add MetaAnonymousFile, an abstraction around anonymous read-only files.
Files can be created by calling meta_anonymous_file_new(), passing the
data of the file. Subsequent calls to meta_anonymous_file_open_fd()
return a fd that's ready to be sent over the socket.
When mapmode is META_ANONYMOUS_FILE_MAPMODE_PRIVATE the fd is only
guaranteed to be mmap-able readonly with MAP_PRIVATE but does not
require duplicating the file for each resource when memfd_create is
available. META_ANONYMOUS_FILE_MAPMODE_SHARED may be used when the
client must be able to map the file with MAP_SHARED but it also means
that the file has to be duplicated even when memfd_create is available.
Pretty much all of this code was written for weston by Sebastian Wick,
see https://gitlab.freedesktop.org/wayland/weston/merge_requests/240.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1012
Instead of having everything clumped at MetaWaylandDataManager,
split the primary selection to its own struct. This manager is
handled separately from wl_data_device_manager and other selection
managers, so they would be able to interoperate between them, even.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1193
This is still an openly defined struct, as we will need accessed
by "subclasses". Same principle applies than with the
MetaWaylandDataSource refactor, this is not meant to introduce
functional changes, so just go with it.
On the bright side, the interactions are now clearer, so it could
be made saner in the future.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1193
The split wasn't 100% clean, and some extra private API had to be
added for it (but well, looking at the API, it's already evident
there's a cleanup/streamlining task due). This is meant to be a
refactor with no functional changes, so just go with it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1193
We already have a signal callback that translates selection ownership changes to
data_device/primary .selection events. Given both will be run when a data source
is being replaced, and this event emission being deleted is kinda short sighted
in that in only knows about Wayland, rely entirely on MetaSelection::owner-changed
emission.
Fixes spurious .selection(null) events being sent when a compositor-local source
takes over the selection without the focus changing (eg. screenshot to clipboard).
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1160https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1204
We are meant to send a .cancelled event after the drop is performed
in certain situations, but only for version>3 clients. Since this is
all version 3 business, only set the drop_performed flag for v3
clients. This drops the need to perform version checks at the time
of cancelling (which is present for other usecases in v1).
Fixes emission of wl_data_source.cancelled for v1 clients.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1177https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1203
For the cases where we read a fixed size from the selection (eg. imposing
limits for the clipboard manager), g_input_stream_read_bytes_async() might
not read up to this given size if the other side is spoonfeeding it content.
Cater for multiple read/write cycles here, until (maximum) transfer size is
reached.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
Flushing the X11 selection output stream may happen synchronously or
implicitly, in which case there is not a task to complete. Check there
is actually a task before returning errors. We additionally set the
pipe_error flag, so future operations will fail with an error, albeit
with a more generic message.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
If a write_async() comes up while we are flushing on the background,
the task will be queued, but not deemed a reason on itself to keep
flushing (and finish the task) after a property delete event.
To fix this, do not ever queue up write_async tasks (this leaves
priv->pending_task only used for flush(), so the "flush to end"
behavior in the background is consistent). We only start a
background flush if there's reasons to do it, but the tasks are
immediately finished.
All data will still be ensured to be transfered on flush/close,
this makes the caller in this situation still able to reach to it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
It does not make sense to check for the stream not being closed,
this might happen multiple times during the lifetime of the stream
for a single transfer. We want to notify the INCR transfer just
once.
Check for the explicit conditions that we want, that the remaining
data is bigger than we can transfer at once, and that we are not
yet within the INCR transfer.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
The stream automatically flushes after data size exceeds the
size we deem for INCR chunks, but we still try to copy it all.
Actually limit the data we copy, and leave the rest for future
INCR chunks.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
INCR transfers are mandated to finish with a final 0-size XChangeProperty
roundtrip after the final data chunk. Actually honor this and ensure we
iterate just once more for this.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
This seemed to work under the assumption that a flush() call can
only result in one INCR roundtrip. This is evidently not true, so
we should hold things off until all pending data is actually flushed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
If say we want 32bit data, but have 2 bytes stored, we would simply
ignore flush requests. Allow (and don't clear) the needs_flush flag
if we have less than the element size accumulated.
Instead handle this in can_flush(), so it's triggered whenever we
have enough data to fill 1 element, or if the stream is closing
(seems a broken situation, but triggered by the caller).
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
XMaxRequestSize/XMaxExtendedRequestSize are documented to return
the maximum size in 4-byte units, whereas we are comparing this
to byte lenghts. We can afford 4x the data here.
Since I don't know the payload size of the XChangeProperty request,
be generous and allot 400 bytes for it, we have some to spare.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
When closing the lid of a laptop, we reconfigure all the monitors in order
to update the CRTCs and (if enabled) the global UI scaling factor.
To do this, we try first to reuse the current configuration for the usable
monitors, but if we have only monitor enabled and this one is on the laptop
lid we just end up creating a new configuration where the primary monitor is
the laptop one (as per find_primary_monitor() in MetaMonitorConfigManager),
but ignoring the user parameters.
In case the user selected a different resolution / scaling compared to the
default one, while the laptop lid is closed we might change the monitors
layout, causing applications to rescale or reposition.
To avoid this, when creating the monitors configuration from the current
current state, in case we have only one monitor available and that one is
the laptop panel, let's just reuse this configuration.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1200
Try to bypass compositing if there is a fullscreen toplevel window with
a buffer compatible with the primary plane of the monitor it is
fullscreen on. Only non-mirrored is currently supported; as well as
fullscreened on a single monitor. It should be possible to extend with
more cases, but this starts small.
It does this by introducing a new MetaCompositor sub type
MetaCompositorNative specific to the native backend, which derives from
MetaCompositorServer, containing functionality only relevant for when
running on top of the native backend.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
We need to coordinate with MetaCompositor during pre-paint so that we
have control over whether MetaLater callbacks happen first, or the
MetaCompositor pre-paint logic.
In order to do so, make MetaLater listen to a new signal "pre-paint" on
MetaCompositor, that is called MetaCompositors own pre-paint handling.
This fixes an issue where the top window actor was calculated after the
MetaCompositor pre-paint handling, meaning the top actor being painted
was out-of-date.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Since the order of destruction during MetaDisplay tear down is a bit
unordered, there are pieces that try to destruct its compositing
dependent pieces (i.e. queued MetaLater callbacks) after MetaCompositor
has been cleaned up, meaning we need to put some slightly awkward NULL
checks to avoid crashing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
MetaCompositor is the place in mutter that manages the higher level
state of compositing, such as handling what happens before and after
paint. In order for other units that depend on having a compositor
instance active, but should be initialized before the X11 implementation
of MetaCompositor registers as a X11 compositing manager, split the
initialization of compositing into two steps:
1) Instantiate the object - only construct the instance, making it
possible for users to start listening to signals etc
2) Manage - this e.g. establishes the compositor as the X11 compositing
manager and similar things.
This will enable us to put compositing dependent scattered global
variables into a MetaCompositor owned object.
For now, compositor management is internally done by calling a new
`meta_compositor_do_manage()`, as right now we can't change the API of
`meta_compositor_manage()` as it is public. For the next version, manual
management of compositing will removed from the public API, and only
managed internally.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
While at it, fix some style inconsistencies, for now use a single
singleton struct instead of multiple static variables, and
other non-functional cleanups. Semantically, there is no changes
introduced.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
This will check whether the current backing buffer is compatible with
the primary plane of the passed CoglOnscreen. Since this will extend the
time before a buffer is released, the MetaWaylandBufferRef is swapped
and orphaned if a new buffer is committed before the previous one was
released. It'll eventually be released, usually by the next page flip
callback.
Currently implemented for EGLImage and DMA-BUF buffer types.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Advertising support for modifiers means we will most likely not not be
able to scan out client buffers directly, meaning it just as likely that
we won't be able to scan out even fullscreen windows without atomic KMS.
When we have atomic support, we should advertise support for modifiers
if atomic is used to drive the CRTCs, as we by then can check whether we
can scan out directly, place in an overlay plane, etc.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
While this is fairly incomplete, as to check things fully we need to use
TEST_ONLY in atomic to try out a complete assignment on the device, but
this works well enough for legacy non-modifier cases.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Make it possible to cause the next frame to scan out directly from the
passed CoglScannout. This makes it possible to completely bypass
compositing for the following frame.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Instead of always swapping buffers and flipping the back buffer, make it
possible to scan out a provided buffer directly without swapping any EGL
buffers.
A buffer is passed as an object implementing the empty CoglScanout
interface. It is only possible to do this in the native backend; and the
interface is implemented by MetaDrmBufferGbm. When directly scanned out,
instead of calling gbm_surface_lock_front_buffer() to get the gbm_bo and
fbid, get it directly from the MetaDrmBufferGbm, and use that to create
the page flip KMS update.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Transitions are used for animating actors when e.g. going from/to
fullscreen, and the like. We need to know such things when deciding
whether to avoid compositing a window actor, so make add API visible to
mutter that checks whether there are any transitions active.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
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
Surface buffers are created with meta_drm_buffer_new_acquire(), taking a
gbm_surface acquiring the gbm itself, and meta_drm_buffer_new_take()
that takes over ownership of a passed gbm_bo.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Currently a buffer use count always reaches zero before it is replaced.
This is due to the fact that at the point a new buffer is attached, the
last potential user releases it (the stage) since the currently
displayed frame has a composited copy of the buffer.
This may however change, if a buffer is scanned out directly, meaning it
should not be released until the page flip callback is invoked.
Prepare for this by making the buffer reference a heap allocated struct,
enabling us to keep a pointer to it longer than the buffer is attached.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
The CRTC level transform (not necessarily the hw transform) must be
taken into account when calculating the position of the CRTC in the
stage coordinate space, when placing the hw cursor, otherwise we'll
place the cursor as if the monitor was not rotated.
This wasn't a problem in the past, as with rotation, we always used the
OpenGL cursor, so the issue newer showed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1199
The port to per CRTC views was incomplete; we still used the logical
monitor layout as the stage view layout, while still using one view per
CRTC.
This worked fine for most cases, e.g. regular monitors, tiled or
non-tiled, transformed or non-transformed. Where it broke, however, was
when a monitor consists of multiple CRTCs. We already have the layout a
CRTC corresponds to on the stage kept with the CRTC metadata, so use
this directly.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1170https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1199`
The CRTC level transform (i.e. not necessarily the one set on the
hardware) is what is relevant for calculating the layout the CRTC will
have on the stage, so only use the one that can be handled by the
hardware for the CRTC assignment.
This makes the CRTC layout valid for tiled monitors.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1199
Previously the tile coordinate was used to offset a CRTC scanout
coordinate within a larger framebuffer. Since 3.36 we're always
scanning out from (0, 0) as we always have one framebuffer per CRTC; we
instead use the tile coordinate to calculate the coordinate the tile has
in the stage view. Adapt calculation to fulfil this promise instead of
the old one.
This also corrects the tiled custom monitor test case.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1199
test_client_new might return early if conditions are not met, leaving some
allocated data around without freeing it.
Since we're not using the client before, there's no need to initialize it early
and just initialize it when it's going to be returned.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1195
Dereference the loop variable rather than the original list head. This
fixes a regression introduced in 4413b86a3 ("backends: Replace
ClutterDeviceManager usage in favor of ClutterSeat", 2019-10-04) which
broke button scrolling with trackballs.
Closes:https://gitlab.gnome.org/GNOME/mutter/-/issues/1120
Most visible with xwayland-on-demand, at the time of setting things up
for X11 selections, we don't forward the current state. This makes the
first started X11 app oblivious to eg. the current clipboard.
Syncing selections up at the time of initializing the X11 selection
stuff ensures that doesn't happen.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1186
click_action_query_long_press() can potentially schedule more than
one timeout, since it doesn't clear any already-existing timeout.
Make sure to clear the long press timeout before scheduling a new
one.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1188
Like the click action, it makes sense to cancel the ongoing gesture
when the action is disabled. Do so by overriding our new friend,
ClutterActorMeta.set_enabled, and canceling the gesture when disabling
the action.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1188
ClutterClickAction, like other actions, can potentially be disabled
at any time (that is not during painting). When that happens with
ClutterClickAction, it must release all timeouts and disconnect from
the stage's 'capture-event'.
Override ClutterActorMeta.set_enabled and release the click action
when the action is being disabled.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1188
Various subclasses of ClutterActorMeta need to reacto to being
disabled. Right now, however, the only way to do that is by
overriding GObject's 'notify' vfunc, and doing a string comparison
against "enabled".
Add a new vfunc to ClutterActorMeta in order to replace this bad
practice.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1187
On VT switch, the devices are removed, which means for Wayland disabling
the keyboard.
When the keyboard is disabled, the associated `xkb_state` is freed and
recreated whenever the keyboard is re-enabled when switching back to the
compositor VT.
That means the `xkb_state` for Wayland is lost whereas the same for
clutter is kept, which causes to a discrepancy with locked modifiers on
VT switch.
To avoid that issue, preserve the XKB info only to dispose it when the
keyboard is eventually finalized.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/344https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1185
In the unlikely case we have multiple rectangles in our selection
(selection spanning several lines, or across LTR/RTL bounds), paint each
of those instead of setting a CoglPath-based clip/fill.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1126
The motion events of tablets for example need to be mapped on the
selected screen area if the input device is configured to use only a
part of the active logical monitor.
To achieve this behavior each motion event is transformed using the
transformation matrix set for the input device.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1118
At some point we crossed the streams... In a short timespan we had
1f00aba92c merged, pushing WacomDevice to a common parent object,
and dcaa45fc0c implementing device grouping for X11.
The latter did not rely on the former, and just happened to
merge/compile without issues, but would promptly trigger a crash
whenever the API would be used.
Drop all traces of the WacomDevice internal to MetaInputDeviceX11.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1183
With the introduction of "shallow" relayouts, we are now able to enter
allocation cycles not only at the stage but also deeper down the
hierarchy if we know an actors allocation isn't affected by its children
since the NO_LAYOUT flag is set.
Now that means when queuing relayouts it's possible that
`priv->needs_allocation` gets set to TRUE for some actors down the
hierarchy, but not for actors higher up in the hierarchy. An actor tree
where that happens could look like that:
stage -> container -> container2 (NO_LAYOUT) -> textActor
With that tree, if the "textActor" queues a relayout, "container2" will
be added to the relayout hashtable of the stage and the actors "stage"
and "container" will have `priv->needs_allocation` set to FALSE.
Now if another relayout on the stage actor is queued,
`clutter_stage_queue_actor_relayout()` currently removes all the other
hashtable entries in favour of the stage entry, (wrongly) assuming that
will allocate everything. It doesn't allocate everything because in the
example above "container" has `priv->needs_allocation` set to FALSE,
which makes clutter_actor_allocate() return early before allocating its
children, so in the end "container2" will never get a new allocation.
To fix this, stop flushing the relayout hashtable when queuing a
stage-relayout and still add new entries to the hashtable if a stage
relayout is already queued to make sure we still go through all the
previously queued "shallow" relayouts. That shouldn't hurt performance,
too, because as soon as an actor got allocated once, it doesn't need an
allocation anymore and should bail out in clutter_actor_allocate() as
long as it's absolute position didn't change.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2538https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1173
We have branched now, time for a shiny new CI image.
Update the Dockerfile to:
- switch to F32
- use a single shared copr
- drop dependencies that are now covered by builddep
- do not include weak deps
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1176
Currently we check whether a window is alive everytime it's focused.
This means that an application that doesn't respond to the check-alive
event during startup always showing the "application froze" dialog,
without the user ever trying to interact with it.
An example where this tends to to happen is with games, and for this
particular scenario, it's purely an annoyance, as I never tried to
interact with the game window in the first place, so I don't care that
it's not responding - it's loading.
To avoid these unnecessary particular "app-is-frozen" popups, remove the
alive check from the focus function, and instead move it back to the
"meta_window_activate_full()" call. To also trigger it slightly more
often, also add it to the path that triggers the window focus when a
user actively clicks on the window.
This means that we currently check whether a window is alive on:
* Any time the window is activated. This means e.g. alt-tab or
selecting the window in the overview.
* The user clicks on the window.
Note that the second only works for an already focused window on
Wayland, as on X11, we don't refocus it. This particular case isn't
changed with this commit, as we didn't call meta_window_focus() to begin
with here.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1182
This fixes an issue where a non-maximized screen casted window would be
stretched to fill the whole screen cast stream, instead of just the crop
that corresponds to the current window size.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1174
It isn't immediately obvious that this is impossible, because there's some
"action at a distance" going on with framebuffers that have their size
set lazily, after their textures get allocated; so let's make this a
critical warning rather than crashing.
In particular, this works around a crash when gnome-shell tries to blur a
background that hasn't yet had any space allocated for it - which it seems
is really an actor layout bug, but more robustness seems good to have.
Workaround for <https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2538>.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1172
Signed-off-by: Simon McVittie <smcv@debian.org>
A texture with no pixels isn't a useful thing to have, and breaks
assumptions elsewhere. For example, CoglFramebuffer assumes that after
a texture has been allocated, it will have width and height both greater
than 0.
In particular, this works around a crash when gnome-shell tries to blur a
background that hasn't yet had any space allocated for it - which it seems
is really an actor layout bug, but more robustness seems good to have.
Workaround for <https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2538>.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1172
Signed-off-by: Simon McVittie <smcv@debian.org>
Disabling a click action after a button-press but before a
button-release is captured makes ClutterClickAction connect to
captured-event and never disconnect.
This change fixes it by making sure the captured-event is only
processed if the action is still enabled, otherwise releasing
the action (reset state) and propagating the event.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1170
Nothing should ever disable an actor modifier (e.g. effect) during the
paint sequence, nor should any actor be set or unset on it. If this
would happen, log warnings so that it can be tracked down.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1166
Picking now only happens on allocated actors, but the
callback in the actor-pick test is not waiting for the
stage to run an allocation cycle. Ideally, we'd wait
for this cycle, but for now, forcing an allocation works
as well.
Allocate the overlay actor in the actor-pick test.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1169
When selecting the pick regions for an actor we were not considering
whether the actor was allocated and that was causing issues where the
preferred width/height of the actor was used when deciding whether
the actor should be considered as a pick target.
Check if the actor has a valid allocation, in addition to being mapped
and being in pick mode, in clutter_actor_should_pick_paint().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1169
Normally we bail out in `sync_actor_geometry()`. The comment there
states:
```
Normally we want freezing a window to also freeze its position; this allows
windows to atomically move and resize together, either under app control,
or because the user is resizing from the left/top. But on initial placement
we need to assign a position, since immediately after the window
is shown, the map effect will go into effect and prevent further geometry
updates.
```
The signal for the initial sync originates in `MetaWindow` though and predates
`xdg_toplevel_set_maximized`, which again calls `meta_window_force_placement`,
triggering the signal too early. As a result, Wayland clients that start up
maximized have a wrong map animation, starting in the top-left corner.
In order to fix this without changing big parts of the geometry logic and risking
regressions, force the initial sync again before mapping.
Solution suggested by Jonas Ådahl.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1164
cogl_object_[get|set]_value_object() are annotated as [get|set]-value-func
for objects and primitives, so they must be visible for any derived types
to be usable from introspection.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1146
IBusInputContext/ClutterInputFocus/GtkIMContext all go for offset+len
for their ::delete-surrounding signals, with offset being a signed int
(neg. to delete towards left of selection, pos. to delete towards right
of selection) and len being an unsigned int from the offset (and
presumably, skipping the current selection).
The text-input protocols however pass in this event two unsigned integers,
one being the length of text to delete towards the left of the selection,
and another the length of text to delete towards the right of the selection.
To translate properly these semantics, positive offsets shouldn't account
for before_length, and negative offset+len shouldn't account for after_length.
The offset/length approach may of course represent deletions that are
detached from the current cursor/selection, we simply delete the whole range
from the cursor/selection positions then.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/517
The input method can assign a negative value to
clutter_input_method_delete_surrounding() to move the cursor to the left.
But Wayland protocol accepts positive values in delete_surrounding() and
GTK converts the values to the negative ones in
text_input_delete_surrounding_text_apply().
https://gitlab.gnome.org/GNOME/mutter/issues/539
GObject recommends to break references to other objects on dispose
instead of finalize, also we want to release the pressed virtual buttons
as early as possible if we know the object is getting destroyed.
So release the pressed buttons and unref our virtual
MetaInputDeviceNative when the dispose vfunc is called, which also
allows us to release the buttons immediately from javascript instead of
waiting for the garbage collector by calling run_dispose() on the
object.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1157
In commit d846fabda we moved to using the override color alpha, however
it was missed that the actor opacity is transferred to the PangoRenderer
through the default color alpha, and the reason it was used there.
We actually want to factor in both alpha values, in order to respect
both foreground color alpha and actor opacity. This is done on the
unpremultiplied color, so we just need to change the alpha value.
Fixes effects on text actors that involve actor opacity.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1158
pango_renderer_get_alpha() returns 0 to indicate that the alpha value
should be inherited from the environment, but we are passing it on
(and therefore making the text fully translucent).
Instead, make the text fully opaque as expected.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1156
This allows us to screencast any window continuously, even
without it being visible. Because it's still being painted,
clients continue to receive frame callbacks, and people
are happy again.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1129
Just like what's done for monitor screencasting. Unfortunately, there's
no mechanism to share fences with PipeWire clients yet, which forces
us to guarantee that a frame is completed after blitting.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1129
MetaScreenCastWindowStreamSrc connects to the "damaged" signal of
MetaWindowActor. This signal is not exactly tied to the paint cycle
of the stage, and a damage may take quite a while to arrive when
a client doesn't want to draw anything. For that reason, the window
screencast can start empty, waiting for a damage to arrive.
Ensure at least one frame is recorded when enabling the window stream.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/1097https://gitlab.gnome.org/GNOME/mutter/merge_requests/1129
cogl_framebuffer_push_rectangle_clip() acts on the current modelview
matrix. That means the result of clipping then translating will be
different of the result of translating then clipping.
What we want for window screencasting is the former, not the latter.
Move the translation code (and associated) to after clipping.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/1097https://gitlab.gnome.org/GNOME/mutter/merge_requests/1129
Fix a regression that got introduced with
c483b52d24 where we started passing the
redraw_clip to paint_stage() instead of creating a temporary view_region
for unclipped redraws: In case we detect an invalid buffer age, we fall
back to doing an unclipped redraw after we passed the first check
setting up may_use_clipped_redraw. That means we didn't reset the
redraw_clip to the view_rect, and we're now going to redraw the stage
using the original redraw clip even though we're swapping the full
framebuffer without damage.
To fix that, check for the buffer age before setting up the
fb_clip_region and the redraw_clip and set may_use_clipped_redraw to
FALSE if the buffer age is invalid, too. This ensures the redraw_clip is
always going to be correctly set to the view rect when we want to force
a full redraw.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/1128
When calculating the transform we should apply to the cursor sprite
before uploading it to the cursor plane, we must also take into
account non upright mounted LCD panels.
Otherwise the cursor ends up 90 degrees rotated on devices where the
LCD panel is mounted 90 degrees rotated in its enclosure.
This commit fixes this by calling meta_monitor_logical_to_crtc_transform
in get_common_crtc_sprite_transform_for_logical_monitors to adjust the
transform for each Monitor in the LogicalMonitor.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1123https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1153
Support for them appears to be way less common than e.g. png, which is
currently the preferred format from Firefox, Chromium, Libreoffice and others.
Adopt to that fact.
As a side effect, this works around a bug observed when copying images in
Firefox on Wayland.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1141
Cogl shares some GL functions between the GLES and the big
GL drivers. Namely, it shares _cogl_driver_gl_context_init
and _cogl_driver_gl_context_deinit between these two drivers.
The plot twist is: even though these functions are shared and
their prototypes are in cogl-util-gl-private.h, they're actually
implemented inside cogl-driver-gl.c, which is strictly only
about the big GL driver.
This is problematic when building Mutter on ARM v7, where we
need to disable OpenGL, but keep GLES enabled.
Fix this by moving the shared GL functions to a shared GL file.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1151
When resizing a window interactively, we'll set a grab operation and a
grab window, among other things. If we're resizing (including setting
initial size, i.e. mapping) another window, that didn't change position,
don't use the gravity of the grab operation when resizing our own
window.
This fixes an issue with jumpy popup position when moving a previously
mapped gtk popover.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/999
The transactional KMS API has been modelled after atomic KMS. Atomic KMS
currently doesn't support forwarding cursor hotspot metadata, thus it
was left out of the transactional KMS API having the user set the simply
create a plane assigment with the cursor sprite assigned to a cursor
plane using regular coordinates.
This, however, proved to be inadequate for virtual machines using
"seamless mouse mode" where they rely on the cursor position to
correspond to the actual cursor position of the virtual machine, not the
cursor plane. In effect, this caused cursor positions to look "shifted".
Fix this by adding back the hotspot metadata, right now as a optional
field to the plane assignment. In the legacy KMS implementation, this is
translated into drmModeSetCursor2() just as before, while still falling
back to drmModeSetCursor() with the plane coordinates, if either there
was no hotspot set, or if drmModeSetCursor2() failed.
Eventually, the atomic KMS API will learn about hotspots, but when
adding our own atomic KMS backend to the transacitonal KMS API, we must
until then still fall back to legacy KMS for virtual machines.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1136
When calculating the resource scale of a clone source, we might end up
in situations where we fail to do so, even though we're in a paint. A
real world example when this may happen if this happens:
* A client creates a toplevel window
* A client creates a modal dialog for said toplevel window
* Said client commits a buffer to the modal before the toplevel
If GNOME Shell is in overview mode, the window group is hidden, and the
toplevel window actor is hidden. When the clone tries to paint, it fails
to calculate the resource scale, as the parent of the parent (window
group) is not currently mapped. It would have succeeded if only the
clone source was unmapped, as it deals with the unmapped actor painting
by setting intermediate state while painting, but this does not work
when the *parent* of the source is unmapped as well.
Fix this by inheriting the unmapped clone paint even when calculating
the resource scale.
This also adds a test case that mimics the sequence of events otherwise
triggered by a client. We can't add a Wayland client to test this, where
we actually crash is in the offscreen redirect effect used by the window
dimming feature in GNOME Shell.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/808https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1147
For HiDPI pointer cursors backed by Wayland surfaces, the hotspot must
be placed using integers on the logical pixel grid. In practice what
this means is that if the client loads a cursor sprite with the buffer
scale 2, and it's hotspot is not dividable by 2, it will be rounded
down to an integer that can. E.g. a wl_surface with buffer scale 2 and a
cursor image with hotspot coordinate (7, 7) will have the coordinate
(3.5, 3.5) in surface coordinate space, and will in practice be rounded
down to (3, 3) as the hotspot position in wl_pointer only takes
integers.
To not potentially shift by 1 pixel on HiDPI monitors when switching
between wl_surface backend cursor sprites and built-in ones, make the
built in one emulate the restrictions put up by the Wayland protocol.
This also initializes the theme scale of the xcursor sprite instances to
1, as they may not have been set prior to being used, it'll only happen
in response to "prepare-at" signals being emitted prior to rendering.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/1092https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1107
We checked that the content size was appropriately painted in the stage,
but didn't take into account that the size of the sampled texture
region, meaning that when stage views were scaled, we'd think that we
would draw a texture scaled, as e.g. a 200x200 sized texture with buffer
scale 2 would have the size 100x100. When stage views were not scaled,
we'd apply a geometry scale meaning it'd end up as 200x200 anyway, thus
pass the check, but when stage views are scaled, it'd still be painted
as a 100x100 shaped texture on the stage, thus failing the
are-we-unscaled test.
Fix this by comparing the transformed paint size with the sampled size,
instead of the paint size again, when checking whether we are being
painted scaled or not. For example, when stage views are scaled, our
200x200 buffer with buffer scale 2, thus content size 100x100 will
transform to a 200x200 paint command, thus passing the test. For
non-scaled stage views, our 200x200 buffer with buffer scale 2 thus
content size 100x100 will also transform into a 200x200 paint command,
and will also pass the check, as the texture sample region is still
200x200.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/804https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1124
A user may have configured an output to be panning, e.g. using xrandr
--output <output> --mode <mode> --panning <size>. Respect this by making
the logical monitor use the panning size, instead of the mode. This
makes e.g. makes the background cover the whole panning size, and panels
etc will cover the whole top of the panned area, instead of just the top
left part covering the monitor if having panned to (0, 0).
No support is added to configuring panning, i.e. a panned monitor
configuration cannot be stored in monitors.xml.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1085
Just like libmutter-clutter, and libmutter, mark exported symbols with
an COGL_EXPORT macro. This removes the .map and .map.in files previously
used, containing a list of semi private symbols. This symbol was out of
date, i.e. pointed to non-existing symbols, and was also replaced with
COGL_EXPORT macros.
unit_test_* symbols are exported by the help of the unit test defining
macro. test_* symbols are no longer supported as it proved unnecessary.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1059
This is so that cogl-trace.h can start using things from cogl-macros.h,
and so that it doesn't leak cogl-config.h into the world, while exposing
it to e.g. gnome-shell so that it can make use of it as well. There is
no practical reason why we shouldn't just include cogl-trace.h via
cogl.h as we do with everything else.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1059
The upper layers (OSDs basically) want to know the monitor that a
tablet is currently assigned to, not the monitor just as configured
through settings.
This broke proper OSD positioning for display-attached tablets since
commit 87858a4e01, as the MetaInputMapper kicks in precisely when
there is no configured monitor for the given device.
Consulting both about the assigned output will make OSDs pop up
again in the right place.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/971
We used to inhibit all pad actions while the OSD is shown, but one we
would actually want to handle are mode switches while the OSD is open.
So it has an opportunity to catch up to the mode switch.
This lets MetaInputSettings reflect the mode switch (eg. when querying
action labels), so the OSD has an opportunity to update the current
actions.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/975
Commit cda9579034 fixed a corner case when setting the initial workspace
state of transient windows, but it still missed a case:
should_be_on_all_workspaces() returns whether the window should be on all
workspaces according to its properties/placement, but it doesn't take
transient relations into account.
That means in case of nested transients, we can still fail the assert:
1. on-all-workspaces toplevel
2. should_be_on_all_workspaces() is TRUE for the first transient's parent,
as the window from (1) has on_all_workspaces_requested == TRUE
3. should_be_on_all_workspaces() is FALSE for the second transient's
parent, as the window from (2) is only on-all-workspace because
of its parent
We can fix this by either using the state from the root ancestor
instead of the direct transient parent, or by using the parent's
on_all_workspaces_state.
The latter is simpler, so go with that.
https://gitlab.gnome.org/GNOME/mutter/issues/1083
This class sits between ClutterInputDevice and the backend implementations,
it will be the despositary of features we need across both backends, but
don't need to offer through Clutter's API.
As a first thing to have there, add a getter for a WacomDevice. This is
something scattered across and somewhat inconsistent (eg. different places
of the code create wacom devices for different device types). Just make it
here for all devices, so users can pick.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1109
Most people just see a harmless warning when applying this setting to
all touchpads (which this patch fixes). But tap[-and-drag] is supposed
to remain enabled for display-less Wacom tablets, despite configuration
changes.
Fix this by using the mapping function, so the setting is forced on for
wacom devices. This happens on a per-device basis, so the warning is
gone too.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1145
This fixes a case that was overlooked in
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1036 - when we
have a geometry scale > 1 and Wayland subsurfaces that have an offset
to their parent surface (which is often the case when the toplevel surface
includes decoration/shadows etc.), we have to add extra offset to their
opaque regions so they match their 'visible' location.
This is necessary as `meta_cullable_cull_out_children` moves the coordinate
system during culling, but does not know about geometry scale.
Also, remove the redundant check for `window_actor` - we only hit this code
path if a `window_actor` culls out its children.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1108
Some tablets like the Cintiq 24HDT have several mode switch buttons
per group. Those are meant to jump straight to a given mode, however
we just handle cycling across modes (as most other tablets have a
single mode switch button per group).
So spice up the mode switch handling so we handle multiple mode
switch buttons, assigning each of them a mode. If the device only
has one mode switch button, we do the old-fashioned cycling.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/970
This error was just logged but not raised. Do as the code comment said
and raise a pipe error at that moment, and for subsequent operations
on the output stream (although none besides close() should be expected
after propagating the error properly).
Related: https://gitlab.gnome.org/GNOME/mutter/issues/1065
When a page flip fails with a certain error code, we've treated this as
a hint that page flipping is broken and we should try to use mode
setting instead.
On some drivers, it seems that this error is also reported when there
was no mode set, which means we'll have no cached mode set to use in the
fallback. The lack of prior mode set tends to happen when we hit a race
when the DRM objects change before we have the time to process a hotplug
event.
Handle the lack a missing mode set in the flip fallback path, with the
assumption that we'll get a hotplug event that'll fix things up for us
eventually.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/917
Both IBus and ClutterInputFocus work in character offsets for the cursor
position in the preedit string. However the zwp_text_input protocol does
define the preedit string cursor offset to be in bytes.
Fixes client bugs in representing the caret within the preedit string,
as we were clearly giving the wrong offset.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/2517https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1132
We send configure events for state changes e.g. for `appears-focused`,
etc. What we don't want to do is to do this for popup windows, as in
Wayland don't care about this state.
When the focus mode was configured to "sloppy focus" we'd get
`appears-focused` state changes for the popup window only by moving the
mouse cursor around, and while a popup may care about focus, it does not
care about related appearance, as there is no such state in xdg_popup.
What these state changes instead resulted in was absolute window
configuration events, intended for toplevel (xdg_toplevel) windows. In
the end this caused the popup to be positioned aginst at (0, 0) of the
parent window, as the assumptions when the configuration of the popup
was acknowledged is that it had received a relative position window
configuration.
Fix this by simply ignoring any state changes of the window if it is a
popup, meaning we won't send any configuration events intended for
toplevels for state changes. Currently we don't have any way to know
this other than checking whether it has a placement rule. Cleaning up
MetaWindow creation is left to be dealt with another day.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/1103https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1122
If the CRTCs the cursor is visible on do not share a common scale
and transform, we can't use the cursor hardware plane as we only have one.
We therefore fall back to software / gl cursor.
The check for that currently happens after we tried to upload the cursor image
to the hardware plane though.
This is made worse by the fact that in the scaling step, where we scale the
cursor image to the desired size, until now we expected a valid common scale -
otherwise scaling the image by an uninitialized float.
Make sure we bail out early during the scale/upload step if we don't have common
scales and transforms - to avoid that bug and save some unnecessary work.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1125
Make sure it is only the special modifier (hardcoded to 1 currently)
which is being pressed (not counting locked modifiers) before notifying
that the special modifier is pressed, as we are interested in it being
pressed alone and not in combination with other modifier keys.
This helps in two ways:
- Pressing alt, then ctrl, then releasing both won't trigger the locate
pointer action.
- Pressing alt, then ctrl, then down/up to switch workspace won't interpret
the last up/down keypress as an additional key on top of the special ctrl
modifier, thus won't be forwarded down to the focused client in the last
second.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/812https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1014
If you first press a key that triggers the "special modifier key" paths
(ctrl, super), and then press another key that doesn't match (yet?) any
keybindings (eg. ctrl+alt, super+x), the second key press goes twice
through process_event(), once in the processing of this so far special
combination and another while we let the event through.
In order to keep things consistent, handle it differently depending on
whether we are a wayland compositor or not. For X11, consider the event
handled after the call to process_event() in process_special_modifier_key().
For Wayland, as XIAllowEvents is not the mechanism that allows clients see
the key event, we can just fall through the regular paths, without this
special handling.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1014
There is a race where an output can be used as a fullscreen target, but
it has already been removed due to a hotplug. Handle this gracefully by
ignoring said output in such situations.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1120
To keep consistent and avoid confusion, rename the function:
`meta_window_x11_buffer_rect_to_frame_rect()`
to:
`meta_window_x11_surface_rect_to_frame_rect()`
As this function doesn't deal with the `window->buffer_rect` at all.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1091
The code in `build_and_scan_frame_mask` predates the introduction of the
`MetaShapedTexture` API to get the texture width hand height.
Use the new `meta_shaped_texture_get_width/height` API instead of using
the CoGL paint texture.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1091
For X11 clients running on Wayland, the actual texture is set by
Xwayland.
The shape, input and opaque regions, however are driven by X11
properties meaning that those may come at a different time than the
actual update of the content.
This results in black areas being visible at times on resize with
Xwayland clients.
To make sure we update all the regions at the same time the buffer is
updated, update the shape, input and opaque regions when the texture is
committed from when the Xwayland surface state is synchronized.
That fixes the remaining black areas being sometimes visible when
resizing client-side decorations windows on Xwayland.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1007https://gitlab.gnome.org/GNOME/mutter/merge_requests/1091
For X11 clients running on Xwayland, the opaque, input and shape regions
are processed from different properties and may occur at a different
time, before the actual buffer is eventually committed by Xwayland.
Add a new API `update_regions` to window actor to trigger the update of
those regions when needed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1091
Commit 7dbb4bc3 cached the client area when the client was frozen.
This is not sufficient though, because the buffer size might still be
lagging waiting for the buffer from Xwayland to be committed.
So instead of caching the client size from the expected size, deduce the
client area rectangle from the surface size, like we did for the frame
bounds in commit 1ce933e2.
This partly reverts commit 7dbb4bc3 - "window-actor/x11: Cache the
client area"
https://gitlab.gnome.org/GNOME/mutter/issues/1007https://gitlab.gnome.org/GNOME/mutter/merge_requests/1091
Listen for GPU hotplug events to initialize their cursor support.
This fixes one reason for why DisplayLink devices may not be using a hardware
cursor. Particularly, when a DisplayLink device is hotplugged for the first
time such that EVDI creates a new DRM device node after gnome-shell has already
started, we used to forget to initialize the cursor support.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1097
Extract the code to initialize a single GPU cursor support into its own
function. The new function will be used by GPU hotplug in the future.
This is a pure refactoring without any behavioral changes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1097
For every stream src, we created and attached a GSource. Upon stream
src destruction, we g_source_destroy():ed the GSource. What
g_source_destroy() does, hawever, is not really "destroy" it but only
detaches it from the main context removing the reference the context had
added for it via g_source_attach(). This caused the GSource to leak,
although in a detached state, as the reference taken on creation was
still held.
Fix this by also removing our own reference to it when finalizing.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1106
PipeWire will be unable to dequeue a buffer if all are already busy.
This can happen for valid reasons, e.g. the stream consumer not being
fast enough, so don't complain in the journal if it happens.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1115
While we will always have cursor planes, as we'll currently create fake
ones when real ones are missing (See #1058), eventually we will run into
situations where we can't create fake ones, for example for atomic KMS
drivers that don't advertise any cursor planes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1079
If we don't force the placement, we enter the constrain machinery with
the position (0, 0), meaning we always get the "current work area" setup
to correspond to whatever logical monitor was at that position.
Avoid this by doing the same as "meta_window_force_placement()" and set
"window->calc_placement" to TRUE while move-resizing, causing the
move-resize to first calculate the initial position.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/1098https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1110
This commit completes the implementation of `xdg_wm_base` version 3,
which introduces support for synchronized implicit and explicit popup
repositioning.
Explicit repositioning works by the client providing a new
`xdg_positioner` object via a new request `xdg_popup.reposition`. If the
repositioning is done in combination with the parent itself being
reconfigured, the to be committed state of the parent is provided by the
client via the `xdg_positioner` object, using
`xdg_positioner.set__parent_configure`.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
This sets the `is_reactive` flag on the window placement rules, causing
the popups to be reconfigured as they are affected by environmental
changes, such as the parent moving in a way making the popup partially
offscreen.
As with synchronization, the implementation is dormant, as the
version of the advertised global isn't bumped yet, as the new protocol
version is not yet fully implemented.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
This commits adds support on the MetaWindow and constraints engine side
for asynchronously repositioning a window with a placement rule, either
due to environmental changes (e.g. parent moved) or explicitly done so
via `meta_window_update_placement_rule()`.
This is so far unused, as placement rules where this functionality is
triggered are not yet constructed by the xdg-shell implementation, and
no users of `meta_window_update_placement_rule()` exists yet.
To summarize, it works by making it possible to produce placement rules
with the parent rectangle a window should be placed against, while
creating a pending configuration that is not applied until acknowledged
by the client using the xdg-shell configure/ack_configure mechanisms.
An "temporary" constrain result is added to deal with situations
where the client window *must* move immediately even though it has not yet
acknowledged a new configuration that was sent. This happens for example
when the parent window is moved, causing the popup window to change its
relative position e.g. because it ended up partially off-screen. In this
situation, the temporary position corresponds to the result of the
movement of the parent, while the pending (asynchronously configured)
position is the relative one given the new constraining result.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
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
A placement rule placed window positions itself relative to its parent,
thus converting between relative coordinates to absolute coordinates,
then back to relative coordinates implies unwanted restrictions for
example when the absolute coordinate should not be calculated againts
the current parent window position.
Deal with this by keeping track of the relative position all the way
from the constraining engine to the move-resize window implementation.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
To organize things a bit better, put the fields related to the placement
rule state in its own anonymous struct inside MetaWindow. While at it,
rename the somewhat oddly named variable that in practice means the
current relative window position.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
After popup placement rules have gone through the constraints engine has
ended up resulting in an actual move, pass the window configuration down
the path using relative coordinates, as that is what the next layer
(xdg-shell implementation) actually cares about.
In the future, this will also be helpful when the configured position is
not against the current state of the parent.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
A placement rule is always about placing a window relative to its
parent. In order to eventually place it against predicted future parent
positions, make the placement rule processing output relative
coordinates, having the caller deal with turning them into absolute.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
meta_window_wayland_finish_move_resize() inhibited window moves to be
finished if there was a resize grab active at the time, in order to
handle window resizing. Change this to only affect the grabbed window
itself, so that e.g. a popup can be positioned according to a pending
configuration while there is an active resize grab.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
This is made a signal, so the upper layers (read: gnome-shell) may
decide what services to spawn. The signal argument contains a task
that will resume MetaX11Display startup after it is returned upon.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/945
This is used by GDK and the X11 bits, but may also be used for
other initialization services we might need to run along with
Xwayland initialization.
However, as the -initfd argument in Xwayland is a fairly new
feature, add some meson build-time checks so that the feature
is handled transparently while allowing to explicitly set/unset
it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/945
This shape region culling was wrongly implemented in f5a28aa9, as it
does not take frame offsets into account, and is also redundant, as
we already set the opaque region of the underlying surface accordingly.
The other parts were implemented in ac7aa114, the reason given in
the commit message:
```
Wayland clients do this through the opaque region in the surface
actor. However X11 clients were considered fully transparent for
culling purposes, which may result in mutter painting other bits
of the background or other windows that will be painted over in
reality.
```
is wrong though - culling on X11 actors works just fine and did only
not work in Wayland sessions because of a bug that got fixed in
19814497.
In conclusion the whole part appears to be redundand and some testing
done suggests the same. Drop it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1082
If a opaque region is explicitly set we should not consider the surface
opaque, as that implies e.g. a shape region is set.
If no opque region is set but the texture does not have an alpha channel,
we can savely cull it out.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1082
We need the stencil buffer to consist of binary values of 0 and 1
because we're doing additions and subtractions on the buffer, so even
though this is the default, explicitely set the stencil mask to 0x1.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1096
When using a region clip and something has a rectangle clip pushed, a
special drawing method for ClutterTexts (emit_vertex_buffer_geometry()
in cogl-pango-display-list.c) starts to fail and clipping issues with
long texts (because emit_vertex_buffer_geometry() is only used for texts
longer than 25 characters) start to appear. This specifically happened
in Looking Glass, where the StViewport of the ScrollView sets a
rectangle clips and the texts are usually longer than 25 characters.
This is caused by the changing of the perspective and modelview matrix
when drawing to the stencil buffer and started happening when
region-clipping was introduced with commit 8598b654. Even though the
changing of the matrices was done before that, too, the issue probably
didn't happen because `rect->can_be_scissor` was TRUE and no stencil
buffer clipping was used at all.
To fix this, temporarily save the old matrices, then set the new ones
and restore the old ones when we're done drawing to the stencil buffer.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/2246https://gitlab.gnome.org/GNOME/mutter/merge_requests/1096
We want sysprof's exact datadir for compatability with
platforms where software is installed into their own
individual immutable prefix's. Such that, mutter's prefix will
never equate to sysprof's. This depends on a MR in sysprof [0]
which adds datadir to its pkgconfig files, as these files will always
have the proper path we want.
This adds version a constraint on sysprof_dep, as datadir was added to
the .pc in this version.
[0]: https://gitlab.gnome.org/GNOME/sysprof/merge_requests/19https://gitlab.gnome.org/GNOME/mutter/merge_requests/957
Given that on Wayland we are pretty much guaranteed to finish MetaX11Display
setup after the MetaCompositor is enabled, we may drop the
meta_compositor_manage() x11 initialization bits, and move them into the
MetaX11Compositor subclass where it's actually needed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/944
We artificially made Xwayland initialization synchronous, as we used
to rely on MetaX11Display and other bits during meta_display_open().
With support for Xwayland on demand and --no-x11, this is certainly
not the case.
So drop the main loop surrounding Xwayland initialization, and turn
it into an async operation called from meta_display_init_x11(). This
function is turned then into the high-level entry point that will
get you from no X server to having a MetaX11Display.
The role of meta_init() in Xwayland initialization is thus reduced
to setting up the sockets. Notably no processes are spawned from here,
deferring that till there is a MetaDisplay to poke.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/944
This ATM completes the task right away, but we will want to do
further things here that are asynchronous in nature, so prepare
for this operation being async.
Since the X11 backend doesn't really need this, make it go on
the fast lane and open the MetaX11Display right away, the case
of mandatory Xwayland on a wayland session is now handled
separately.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/944
With Xwayland initialization going async, these errors will seep
into the parts controlled by g_test*(), resulting in the harmless
errors about DBus names not acquired turned fatal.
Set an error log handler, and specifically ignore those.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/944
It might not be available right on initialization time if X11 is started
asynchronously. As this is a requirement for our tests, ensure it is there
before proceeding with the test.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/944
This used to be set on meta_compositor_manage(), but only if there is a
MetaX11Display. Given meta_display_init_x11() is Wayland only, and we can
always assume compositing to be enabled, just have it invariably set after
the X server is up.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/944
Even though cogl_framebuffer_flush() was supposed to be enough,
it ends up creating streams with odd visual glitches that look
very much like unfinished frames.
Switch back to cogl_framebuffer_finish(), which is admittedly
an overkill, but it's what works for now. There is anedoctal
evidence showing it doesn't incur in worse performance.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1086
Much like monitor streaming, implement window streaming by
making the window actor draw itself with a paint context
that used the passed framebuffer.
Now that all MetaScreenCastStreamSrc subclasses implement
blit_to_framebuffer, remove the conditional check from
meta_screen_cast_stream_src_blit_to_framebuffer().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1086
Implement PipeWire's add_buffer and remove buffer, try and export
a DMA buffer first and, on failure, fallback to memfd.
When DMA buffers are successfully created and shared, blit the
framebuffer contents when drawing instead of downloading the pixels.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1086
Create a new gbm_bo using the same given geometry, and export the new
bo's DMA buffer fd. The new bo lives as long as necessary to be used,
and reused, by PipeWire.
Unfortunately, PipeWire doesn't support modifiers properly, so use the
linear format for now. For now, a hardcoded format of DRM_FORMAT_XRGB8888
is set, so we don't need to negotiate the format with PipeWire early.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1086
This is a winsys-specific API that allows exporting a DMA buffer fd.
The CoglDmaBufHandle structure allows passing the ownership of the
DMA buffer to whoever is using it, so the winsys doesn't need to
manually track it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1086
In future patches, we'll create additional CoglFramebuffers that
will be shared via DMA-Buf with PipeWire. When recording frames,
we'll blit the current onscreen framebuffer into the shared one.
However, that presents a problem: cogl_framebuffer_blit() mimics
glBlitFramebuffer() semantics, and doesn't do an implicit flush
of the GPU command stream. As a consequence, clients may receive
unblitted or incomplete framebuffers.
We could use cogl_framebuffer_finish() to ensure the commands were
submitted to the GPU, but it is too harsh -- it blocks the CPU
completely until the commands are finished!
Add cogl_framebuffer_flush(), which ensures the command stream is
submitted to the GPU without blocking the CPU. Even though we don't
use the framebuffer specifically, it may be useful in the future
for e.g. a potential Vulkan backend to have access to the framebuffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1086
If the cursor sprite does not match the scale factor or transformation
of the monintor, we currently fall back to a software cursor, causing
redraws of the shell. This commit implements scaling and transforming
of the cursor sprite, so we can use it with hardware planes, too.
This commit does the following steps:
1. Make sure we reupload the cursor image if the cursor is over
a logical monitor not matching the scale or transform from the previous
update.
2. Before upload to the hardware plane, scale and transform the cursor
image if possible and necessary.
3. Make sure we always use the hardware cursor if possible (only fall
back to software/OGL cursor if it is visible on multiple logical monitors
with differet scales/transforms).
4. Transform or scale the cursor coordinates if necessary.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/526
In Wayland clients can commit transformed surfaces, so the compositor
can directly use them on hardware planes. We already support that
for other surfaces, this is the first step to also support it on
cursor sprites.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/526
This may be used indirectly before creation as we dispatch libinput events
right after creation (to let input devices be known), so those device
additions would trigger the touch-mode checks.
Creating it in advance results in checks being correctly performed, although
redundantly.
Spotted by Bastien Nocera.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1067
When applying a configuration to XRANDR, we first disable CRTCs that
happen to extend outside of the to-be X11 screen size. While doing so,
we fail to actually check whether the CRTC is active or not, meaning
we'll try to query the content of the CRTC configuration even though it
has none, leading to a NULL pointer dereference.
Fix this by simply ignoring non-configured CRTCs.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1093
This adds a new frameclock tracing mark for a single cycle of the frame
clock. Doing so allows Sysprof to potentially do more with the information
that happens during the frameclock. For example, we can now find
allocations that happen while the frame clock is advancing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1088
offset_scale_and_clamp_region() creates a new region resulting in
view_damage which at this point is the only thing left pointing to what
originally was fb_damage getting overwritten and being leaked.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1089
While the old merge request URLs still work, gitlab recently started
including an additional /- for merge requests.
Adjust the regex to account for that, so that simply copying the URL
from gitlab works again.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1090
The stage window handled the redraw clip in a global manner; this would
interfere if we want to paint views individually as it'd mean
intersecting views (i.e. mirrored monitors) would loose the redraw clip
once the first view was painted. It also is awkward to have a global
state for something that is built up before redrawing, and only really
valid during paint, due to buffer damage history.
This commits removes all redraw clip management from the stage window,
moving it all into the stage views. When a redraw clip is added to the
stage, every affected view will get the same redraw clip added to it,
and eventually when painted, the stage window (ClutterStageCogl) will
retrieve the redraw clip for each view as it repaints them.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
Instead of users fetching it via `clutter_stage_get_redraw_clip()`, pass
it via the paint context. This is helpful as it is only valid during a
paint, making it more obvious that it needs to be handled differently
when there is no redraw clip (i.e. we're painting off-screen).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
Add a helper that scales and clamps a region, aimed to be used when
transforming between framebuffer coordinate space and view coordinate
spaces.
This helps readability by moving out the verbose for loops that deals
with the individual rects of a region to the helper, making the logic
where it's used much simpler.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
The 'have_clip' variable has repeatedly confused me to meaning that
there is a clip. What it actually means is that the effective clip
covers the whole view; the 'redraw_clip == NULL' meaning full redraw is
an important implementation detail for the context, and makes the
intention of the variable unclear; especially since we will after a
couple of blocks will *always* have a clip, just that it covers the
whole view.
Rename the variable to 'is_full_redraw' and negate the meaning, aiming
to make things a lot more clear.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
When calculating the fallback framebuffer clip region, which should be
the region in framebuffer coordinates, we didn't scale the view layout
with the view framebuffer scale, meaning for any other scale than 1,
we'd draw a too small region of the view. Fix this by just using the
size of the framebuffer directly, avoiding any scale dependent
calculation all together.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
We'll expect a swap event if any of the view paints resulted in a swap;
make the logic dealing with this clearer by making changing the less
vilible '|| swap_event' postfix with a up front '|=' operator.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
Prior to this commit the stage was drawn separately for each logical
monitor. This allowed to draw different parts of the stage with
different transformations, e.g. with a different viewport to implement
HiDPI support.
Go even further and have one view per CRTC. This causes the stage to
e.g. draw two mirrored monitors twice, instead of using the same
framebuffer on both. This enables us to do two things: one is to support
tiled monitors and monitor mirroring using the EGLStreams backend; the
other is that it'll enable us to tie rendering directly to the CRTC it
will render for. It is also a requirement for rendering being affected
by CRTC state, such as gamma.
It'll be possible to still inhibit re-drawing of the same content
twice, but it should be implemented differently, so that it will still
be possible to implement features requiring the CRTC split.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
To make it more reliable to distinguish between values that are read
from the backend implementation (which is likely to be irrelevant for
anything but the backend implementation), split out those values (e.g.
layout).
This changes the meaning of what was MetaCrtc::rect, to a
MetaCrtcConfig::layout which is the layout the CRTC has in the global
coordinate space.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
This only needs to be initialized once but is in the hot path of creating
new paint nodes (for which we create many). Instead, do this as part of
the clutter_init() workflow to keep it out of the hot path.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1087
When calculating regions, a lot of temporary allocations are created. For
the array of rects (which is often a short number of them) we can use
stack allocations up to 1 page (256 cairo_rectangle_int_t). For building
a region of rectangles, cairo and pixman are much faster if you have all
of the rectangles up front or else it mallocs quite a bit of temporary
memory.
If we re-use the cairo_rectangle_int_t array we've already allocated (and
preferably on the stack), we can delay the creation of regions until after
the tight loop.
Additionally, it requires fewer allocations to union two cairo_region_t
than to incrementally union the rectangles into the region.
Before (percentages are of total number of allocations)
TOTAL FUNCTION
[ 100.00%] [Everything]
[ 100.00%] [gnome-shell --wayland --display-server]
[ 99.67%] _start
[ 99.67%] __libc_start_main
[ 99.67%] main
[ 98.60%] meta_run
[ 96.90%] g_main_loop_run
[ 96.90%] g_main_context_iterate.isra.0
[ 96.90%] g_main_context_dispatch
[ 90.27%] clutter_clock_dispatch
[ 86.54%] _clutter_stage_do_update
[ 85.00%] clutter_stage_cogl_redraw
[ 84.98%] clutter_stage_cogl_redraw_view
[ 81.09%] cairo_region_union_rectangle
After (overhead has much dropped)
TOTAL FUNCTION
[ 100.00%] [Everything]
[ 99.80%] [gnome-shell --wayland --display-server]
[ 99.48%] _start
[ 99.48%] __libc_start_main
[ 99.48%] main
[ 92.37%] meta_run
[ 81.49%] g_main_loop_run
[ 81.49%] g_main_context_iterate.isra.0
[ 81.43%] g_main_context_dispatch
[ 39.40%] clutter_clock_dispatch
[ 26.93%] _clutter_stage_do_update
[ 25.80%] clutter_stage_cogl_redraw
[ 25.60%] clutter_stage_cogl_redraw_view
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1071
g_signal_emit_by_name() is used to emit signals on ClutterContainer when
actors are removed or added. It happens to do various interface lookups
which are a bit unneccessary and can allocate memory.
Simply using emission wrappers makes all of that go away.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1083
On x11 we emulate pointer events from touch events as long as there's
only one touchpoint on screen, this obviously leads to x11 sending us
crossing events triggered by the emulated pointer. Now if we get a leave
event and set the stage of the ClutterInputDevice to NULL, new touch
events will be discarded by clutters backend because the core pointer
doesn't have a stage associated. This means Mutter completely loses
state of a touchpoint as soon as it crosses a shell actor.
An easy reproducer for this issue is to start the four-finger-workspace
gesture above a window and to move the pointer emulating touch outside
of the window, this will freeze the gesture as the gesture no longer
receives touch events.
To fix this, stop tracking stage changes on crossing events and simply
leave the ClutterInputDevice stage as-is. In our case there is only one
stage anyway and that won't change in the future.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/423
Remove the rather useless callback function that's currently used for
handling the "visibility-changed" signal and instead connect to the
signal using `g_signal_connect_swapped()`.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1077
Add API to ClutterSeat that allows inhibiting the unsetting of the
pointer focus surface. This can be useful for drawing custom cursor
textures like the magnifier of gnome-shell does.
In the future this API should also control unsetting of Clutters
focus-actor, not just the focus surface, that's not really needed right
now since we never unset the focus-actor anyway.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1077
The check-alive feature is there for the user to be able to terminate
frozen applications more easily. However, sometimes applications are
implemented in a way where they fail to be reply to ping requests in a
timely manner, resulting in that, to the compositor, they are
indistinguishable from clients that have frozen indefinitely.
When using an application that has these issues, the GUI showed in
response to the failure to respond to ping requests can become annoying,
as it disrupts the visual presentation of the application.
To allow users to work-around these issues, add a setting allowing them
to configure the timeout waited until an application is considered
frozen, or disabling the check completely.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1080
`meta_xwayland_surface_get_relative_coordinates()` may cause a crash if
the Xwayland surface has no window associated.
That can be observed when using drag and drop from an X11 window to a
Wayland native window:
```
at src/core/window.c:4503
at src/wayland/meta-xwayland-surface.c:200
at src/wayland/meta-wayland-surface.c:1517
at src/wayland/meta-wayland-pointer.c:1048
at src/wayland/meta-wayland-pointer.c:840
at src/wayland/meta-wayland-pointer.c:865
at src/wayland/meta-wayland-pointer.c:954
at src/wayland/meta-wayland-pointer.c:456
at src/wayland/meta-wayland-pointer.c:993
at src/wayland/meta-wayland-data-device.c:1004
at src/wayland/meta-wayland-data-device.c:1278
at src/wayland/meta-xwayland-dnd.c:326
```
Check if the xwayland surface has an associated MetaWindow prior to get
its buffer rect.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1073
The cancellable of a request might already be cancelled by the time
the cancelled_cb is connected resulting in finish_cb being called via
ca_context_cancel before g_cancellable_connect returns. In this case
the request that is written to has already been freed.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/1060
On a Surface Pro 2017, touch-mode is currently only detected correctly
after detaching and attaching the Type Cover (detachable keyboard) once,
it seems that `has_external_keyboard` is only set to the correct value
after MetaSeatNative is initialized.
So fix that and call `update_touch_mode()` once again when the object is
initialized and the `has_external_keyboard` and `has_touchscreen`
properties have been finally updated.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1075
Which offscreens actor rendering only in cases where it hasn't changed for
2 frames or more. This avoids the performance penalty of offscreening an
actor whose content is trying to animate at full frame rate. It will
switch automatically.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1069
It is only useful for clients that do not set an opaque region but
still can be detected as being opaque. This is helpful for X11 clients
as opaque regions only got introduced around 2012 and only as part of EWMH
and are thus not used in many cases.
On Wayland however opaque regions have been part of the core protocol from the
beginnig and we can assume they are used more commonly.
As the current implementation in `MetaWindowActor` does not handle Wayland
subsurfaces well, instead of adding more complexity just move it to
`MetaWindowActorX11`.
While on it, take the shape region into account that is set when clients
use the X Nonrectangular Window Shape Extension Protocol, so we have exact
culling with those clients.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1058
Allow screen casters (e.g. VNC remote desktop services) to ask for
animations to be inhibited, in order to lower the number of frames sent
over the network.
Currently only sets a field on the screen cast session object. Later
it'll be exposed via the remote access handle and via D-Bus by
gnome-shell.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/838
If the transform matrix is an identity, then positioning wont change and
we can avoid creating the transform node altogether. This is based on
a similar find in GTK today while reducing temporary allocations.
This cuts the number of transforms created in clutter_actor_paint() by
about half under light testing of GNOME Shell from 6.8% to 2.4% of
allocations.
Before:
ALLOCATED TOTAL FUNCTION
[ 20.4 MiB] [ 21.20%] clutter_actor_paint
[ 11.0 MiB] [ 11.45%] clutter_paint_node_paint
[ 6.6 MiB] [ 6.84%] clutter_transform_node_new
[ 2.5 MiB] [ 2.61%] clutter_actor_node_new
After:
ALLOCATED TOTAL FUNCTION
[ 33.4 MiB] [ 24.12%] clutter_actor_paint
[ 26.2 MiB] [ 18.91%] clutter_paint_node_paint
[ 3.4 MiB] [ 2.43%] clutter_actor_node_new
[ 3.3 MiB] [ 2.41%] clutter_transform_node_new
Allocation amounts will have differed due to different amounts of running
time, but the % of allocations has now dropped below
clutter_actor_node_new() which should be expected.
https://gitlab.gnome.org/GNOME/mutter/issues/1056
There are two surface roles owning a MetaWindow: MetaWaylandShellSurface
(basis of MetaWaylandXdgToplevel, MetaWaylandXdgPopup,
MetaWaylandWlShellSurface, etc), and MetaXwaylandSurface.
With these two role types, the MetaWindow has two different types of
life times. With MetaWaylandShellSurface, the window is owned and
managed by the role itself, while with MetaXwaylandSurface, the
MetaWindow is tied to the X11 window, while the Wayland surface and its
role plays more the role of the backing rendering surface.
Before, for historical reasons, MetaWindow was part of
MetaWaylandSurface, even though just some roles used it, and before
'wayland: Untie MetaWindowXwayland lifetime from the wl_surface' had
equivalent life times as well. But since that commit, the management
changed. To not have the same fied in MetaWaylandSurface being managed
in such drastically different ways, rearrange it so that the roles that
has a MetaWindow themself manages it in the way it is meant to; meaning
MetaWaylandShellSurface practically owns it, while with Xwayland, the
existance of a MetaWindow is tracked via X11.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
The role determines how a relative coordinate is calculated. More
specifically, using clutters API to transform coordinates is only
accurate right after a clutter layout pass but this function is used
e.g. to deliver pointer motion events which can happen at any time. This
isn't a problem for Wayland clients since they don't control their
position, but X clients do and we'd be sending outdated coordinates if a
client is moving a window in response to motion events.
This was already done already, but now move the Xwayland specific logic
to the Xwayland surface role, keeping the generic transformation logic
in the generic actor surface role.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
The shell surface role is the one where subsurfaces may exist, and it
has direct relation to the MetaWindowActorWayland which currently has
the subsurface stacking logic.
Instead of directly finding the window actor when dealing with
subsurfaces, notify the parent surface that the subsurface state
changed, so that it can outsource the application of this information to
the role. For subsurface roles, this simply means forward upward to the
parent; for shell surface roles, this means regenerate the surface actor
layering.
This allows us to move away from accessing the window directly from the
surface, which in turn allows us to change the ownership structure of
windows.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
If a window already is being pinged, it doesn't make sense to send more
pings to the window, instead we should just wait for that answer or
timeout until we send a new one.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/891
Using a timestamp twice in a row (e.g. when activating two windows in
response to the same event or due to other bugs) will break the window
detection and show a close dialog on the wrong window. This is a grave
error that should never happen, so check every timestamp before sending
the ping for uniqueness and if the timestamp was already used and its
ping is still pending, log a warning message and don't send the ping.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/891
Increase the number of checks whether a window is still responsive and
ping windows on every call to `meta_window_focus()` instead of
`meta_window_activate_full()`. This ensures the window is also pinged in
case normal interaction like clicks on the window happen and a close
dialog will eventually get shown.
Related https://gitlab.gnome.org/GNOME/mutter/issues/395https://gitlab.gnome.org/GNOME/mutter/merge_requests/891
Currently when a window is requested to be unredirected, the
corresponding pixmap and texture can get cleared before the window has
been unredirected by the X server. This can result in the windows behind
showing through which causes a short flicker after showing an OSD or
notification when a fullscreen application is running.
Fix this by ensuring the texture is only cleared after the window has
been unredirected by the server.
Similarly when the window is being redirected again, the pixmap of the
window can only be requested after the redirection has been completed by
the server. This currently can happen in a different frame than the next
redraw of the actor resulting in an empty texture until the next redraw.
Fix this by queuing a redraw immediately after redirecting.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/997
By default clutter will show an actor as it is added to a parent. This
means that after we create the window actor, when it's added to the
window group, we implicitly show it. What we really want is to not show
it until the window is supposed to be shown, which happens when
meta_window_actor_show() is called, as showing prior to that, could
cause issues.
Avoid the implicit show by setting the "show-on-set-parent" property on
the window actor to `FALSE` on window actor construction.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1066
We didn't log what we enabled, just g_info():ed what failed to be
enabled. Change this to g_warning() what failed to be enabled, and
g_message() on what was enabled, so that both will be visible in the
logs.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1061
We preserve the core one, which represents the union of all input
devices. It might make sense to make this per-seat in the future,
but certainly the per-device granularity is unused (at last!) and
useless.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1039
XWayland clients get their opaque region set from their window, not the
surface. Doing both resulted in the surface constantly overwriting the
opaque region - effectively disabling culling of XWayland clients.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1049
Devices have capabilities that other parts need to know about. Instead
of having them probe using drmMode* API, outsource this to
MetaKmsDevice. Currently the only capability tracked is HW cursor size.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
Turns the cursor setting and movement into cursor plane assignment
primitives. In the current simple implementation, this in turn
translates into legacy drmModeSetCursor() and drmModeMoveCursor() calls.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
A cursor plane can now be assigned, and for the simple KMS
implementation, it'll translate into drmModeSetCursor() and
drmModeMoveCursor() calls.
When assignments failed, the cursor planes that failed to be assigned
are communicated via the feedback object.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
The current API as all synchronous, so they can be made to return
feedback immediately. This will be needed for the cursor renderer which
needs to know whether it should fall back to OpenGL cursor rendering.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
meta_kms_update_process_..() makes it sound like it's a MetaKmsUpdate
function called update_..() but in fact it's a MetaKms function that
calls the corresponding process-update impl function. Clear up this
naming confusion.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/930
The frame bounds as returned by `meta_window_actor_get_frame_bounds()`
would be used as cropping values when streaming a window content.
But, as its name implies, it returns the actual frame bounds, whereas we
may want to include the whole buffer, to include client side shadows for
example.
Rename the `get_frame_bounds()` API to `get_buffer_bounds()` (which was
previously partly removed with commit 11bd84789) and return the actual
buffer bounds to use as the cropping area when streaming a window.
Fixes: 931934511 - "Implement MetaScreenCastWindow interface"
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1022
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1018
The clip bounds passed in `meta_window_actor_capture_into()` represent
the actual allocated buffer size where the window actor image will be
eventually copied.
As such, it is completely agnostic to the scaling factors that might
affect the different surface actors which compose the window actor.
So instead of trying to compute the scale factor by which the given
clipping bounds need to be adjusted, simply clip the resulting image
based on the given bounds to make sure we never overflow the destination
buffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1022
This taps on:
1) Touchscreen availability
2) Availability of external keyboards
3) Tablet mode switch, if existent
So we get this property enabled whenever it makes sense to show touch
focused features (eg. the OSK).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1044
And the corresponding getter. This property returns FALSE by default
and must be overridden by subclasses. This will allow gnome-shell to
hook up specific behavior that should not happen on mouse+keyboard
setups.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1044
During compilation, gen_default_modes.py shows two warnings that
say that a comparison is using 'is' instead of '=='.
This patch fixes this bug.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/985
The actors of Wayland subsurfaces are set to be reactive on creation,
when receiving the `wl_subcompositor.get_subsurface` request.
However, if a client creates several subsurfaces and then creates the
xdg_toplevel object after, the previous subsurface actors are reset.
As a result, Clutter picking will skip and ignore those actors in
`clutter_actor_should_pick_paint()` because they aren't marked as
reactive anymore.
An example of such a client being affected by this issue is SCTK, the
Rust library implementing client side decorations for Wayland used
internally by winit and alacritty.
Move the `set_reactive()` call from `get_subsurface()` to the subsurface
`sync_actor_subsurface_state()` vfunc to make sure those remain reactive
even after `xdg_surface.get_toplevel` is invoked.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1024https://gitlab.gnome.org/GNOME/mutter/merge_requests/1040
Some cullable implementation may have extra information about their
expected size. The main example here are surface actors which can be scaled
by geometry scale.
Add an API to overwrite the default size / untransformed check for such cases.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1036
The local copy of the clip- and unobscured region are used to optimize
painting. To get correct results when the actor is scaled, thus "grows",
the corresponding regions have to "shrink", i.e. get scaled down.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1036
Modify create_for_builtin_display_rotation to lookup the
MetaLogicalMonitorConfig for the panel in the logical_monitor_configs
list instead of only working when there is only 1 monitor.
The goal of this change is to honor accelerometer value changes when there is
more than 1 monitor.
Note, since create_for_builtin_display_rotation is also used for handling the
"rotate-monitor" hotkey and this commit modifies the common path of
create_for_builtin_display_rotation this means that we will now also honor
"rotate-monitor" hotkey keypresses when there is more than 1 monitor and
update the builtin display rotation instead of ignoring "rotate-monitor"
hotkey keypresses when there is more than 1 monitor. If this is deemed
undesirable this is easy to fix, but I believe that doing things this way
is more consistent.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/959
Add a clone_logical_monitor_config_list helper function for making a deep
copy of MetaLogicalMonitorConfig lists.
This is a preparation patch for honoring accelerometer value changes when
there is more than 1 monitor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/959
When creating a new config because of a monitor being (un)plugged or
because of super+p being pressed, honor the orientation reported by
the accelerometer for the internal panel.
Before this commit we would always configure the internal panel with
a normal / upright transform when e.g. an external monitor gets plugged
in even if another transform was in use before plugging in the external
monitor. This is inconsistent and causes problems for several use-cases.
This commit fixes this by querying the accelerometer when creating a new
config for an internal panel.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/707
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/924https://gitlab.gnome.org/GNOME/mutter/merge_requests/959
Bail out of sync_state() immediately if the orientation is locked, before
calling read_iio_prox() which updates the curr_orientation value.
There are 2 reasons for this change:
1. Currently meta-monitor-config-manager.c always assumes normal / upright
orientation when generating a new config. This means that e.g. when an
external monitor gets plugged in the builtin panel's transform will be reset
to normal / upright even if the device is not in an upright orientation.
To fix this meta-monitor-config-manager.c needs to call
meta_orientation_manager_get_orientation() to get the current orientation
when generating a new config. Without this change locking the orientation
would stop the emitting of "orientation-changed" signals but we would
still update the curr_orientation value. So when a new config needs to
be generated the latest orientation would be used, effectively ignoring
the "orientation-lock" setting, not updating curr_orientation when
locked fixes this.
2. This ensures we properly emit an an "orientation-changed" signal when
the orientation has changed between when it was locked and it was
unlocked. Before this change if the user locked the orientation, changed it
and then unlocked it, no signal would be raised as we would already have
updated the curr_orientation value turning the sync_state() call in
orientation_lock_changed() into a no-op.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/959
Using `-Dnative_backend=false` caused build failure due to a missing
(implicit) definition of `META_IS_BACKEND_X11`. But if we define it
properly then that just leaves some of the function's locals uninitialized
and it will never work anyway. Just return unconditionally if there's no
native backend to initialize the variables.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1025
Scaling the `monitor_area` before texture creation was just wasting
megabytes of memory on resolution that the monitor can't display. This
was also hurting runtime performance.
Example:
Monitor is natively 1920x1080 and scale set to 3.
Before: The monitor texture allocated was 5760x3250x4 = 74.6 MB
After: The monitor texture allocated is 1920x1080x4 = 8.3 MB
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2118https://gitlab.gnome.org/GNOME/mutter/merge_requests/1004
When creating a virtual device for the native backend, no "device-added"
is emitted.
Similarly, no "device-removed" signal is emitted either when the virtual
device is disposed.
However, the backend plugs into the "device-added" signal to set the
monitor device. Without the "device-added" signal being emitted, the
monitor associated with a virtual device remains NULL.
That later will cause a crash in `meta_idle_monitor_reset_idlettime()`
called from `handle_idletime_for_event()` when processing events from a
virtual device because the device monitor is NULL.
Make sure to emit the "device-added" signal when creating a virtual
device, and the "device-removed" when the virtual device is disposed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1037
When an X11 window requests an initial workspace, we currently trust
it that the workspace actually exists. However dynamic workspaces
make this easy to get wrong for applications: They make it likely
for the number of workspaces to change between application starts,
and if the app blindly applies its saved state on startup, it will
trigger an assertion.
Make sure that we pass valid parameters to set_workspace_state(),
and simply let the workspace assignment fall through to the default
handling otherwise.
https://gitlab.gnome.org/GNOME/mutter/issues/1029
Most usually, applications either expose clipboard content either as text
or as images, so the prioritization here is pointless. However there's some
outliers like LibreOffice Calc which exports content as both image and text
formats (besides other internal ones).
In that mixed case, we probably prefer to keep text formats, rather than
image based ones.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/919
The devices_by_id hash table is responsible for managing the reference
to the devices. In remove_device however, for non-core devices there are
additional calls to dispose/unref, after the last reference has
already been dropped by the hash table.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1032
Interoperation between wl_data_device_manager v1 and v3 got broken
at some point. Ensure that we resort to the "copy" action if either
the drop site or the drag source are from a client that requested v1.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/965
MetaX11SelectionOutputStream was storing copies of strings only to use
them in init and then free them in finalize. This was also causing a
small leak, because one of these strings was not freed. Instead of doing
that just don't create these unnecessary copies in the first place.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1001
e9fbbd5853 changed meta_backend_get_idle_monitor() to use
ClutterInputDevice pointers instead of device IDs, but did not adjust
the call in meta_backend_native_resume() which was still using 0 to get
the core idle monitor resulting in a NULL pointer dereference.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1029
If an actor sets flag `CLUTTER_ACTOR_NO_LAYOUT` then that means it
is (or should be) unaffected by `queue_relayout` calls in its children.
So we can avoid propagating `queue_relayout` all the way up to the stage
and avoid a full stage relayout each time.
But those children whose parent has `CLUTTER_ACTOR_NO_LAYOUT` still need
to be allocated at some point. So we do it at the same point where it
happened before. Only we now queue a *shallow* relayout so the `allocate`
run on the next frame doesn't need to descend the whole actor tree anymore.
Only a subtree and hopefully very small.
For free-floating and top-level actors this provides a measurable
performance benefit. According to Google Profiler, calls to
`_clutter_stage_maybe_relayout` are now so cheap that they no longer show
up in performance profiles.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/575
The meta_seat_native_constrain_pointer() function receives the current
pointer position, and the new pointer position as in/out parameters.
We were however calculating the new coordinates based on the last pointer
position if there was no pointer constrain in place.
Fortunately to us, this didn't use to happen often/ever, as a pointer
constrain function is set on MetaBackend initialization. This behavior
did also exist previously in MetaDeviceManagerNative.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1028
The backend being initialized triggers a pointer warp (and motion event)
where we want to observe the callbacks put in place. So ensure we set
up the hooks before that could happen.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/852
Just go ATM through backend checks, and looking up directly the
native event data, pretty much like the rest of the places do that...
Eventually would be nice to have this information in ClutterEvent,
but let's not have it clutter the MetaBackend class.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/852
This is unlikely to happen, and unlikely to be right (eg. we don't translate
input event coordinates, since those are not in display coordinate space, we
don't offer any feedback for those either).
This can simply be dropped, we listen to XIAllMasterDevices, which suffices
for what we want to do.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/852
When a Wayland window is mapped or unmapped, the Wayland compositor is
expected to send the coorespoindign `wl_pointer` enter/leave events to
the affected clients.
To do so, mutter calls `meta_wayland_compositor_repick()` which
eventually calls `meta_wayland_pointer_repick()` and
`repick_for_event()`.
If pointer input device has not been updated yet, the old clutter actor
is picked and no enter/leave event is emitted.
Make sure we update the pointer input device prior to do the repick to
get the actual `ClutterActor` under the pointer.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1016https://gitlab.gnome.org/GNOME/mutter/merge_requests/1026
The private function `_clutter_input_device_update()` is not currently
exported.
This function calls `_clutter_input_device_set_actor()` which updates
the `ClutterActor` under the pointer, so making that function available
outside of Clutter will allow to make sure the pointer device actor is
updated prior to do picking.
Also, now that the functions is exported to the upper layers, drop the
underscore suffix from the function name.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1026
As we now call `meta_wayland_compositor_repick()` when the effects are
complete for Wayland surfaces, we can safely remove the Wayland specific
code to do the same from `meta_window_show()`.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1026
When mapping/unmapping windows, an animation may be played which can
change the actual actor size and location, hence defeating picking if
done too early.
Make sure we repick when the affects are completed, once the actor is
sized and placed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1026
When building the frame mask, the current reported frame size may not
match when is actually on screen if the buffer has not been updated
yet.
So instead of getting the frame size from the meta window, deduce it
from the texture size.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1009
Currently, `meta_frame_get_mask()` and `meta_ui_frame_get_mask()` will
return the frame mask applied to the current frame size, by querying the
frame themselves.
To be able to get the frame mask at an arbitrary size, change the API to
take a rectangle representing the size at which the frame mask should be
rendered.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1009
With Xwayland, the shape region is recomputed and reapplied even when
the actor is frozen to prevent the black shadows effect.
However, while recomputing the shape region, the current client size is
taken into account, rather than the size when the client was frozen,
which is ahead of the actual client size using the NET_WM_SYNC protocol.
Keep the current client area and to reuse them when the X11 window actor
is frozen for rebuilding the client mask texture.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1009
Right now the CONTENT_SIZE request mode for a ClutterActor is only
respected by `clutter_actor_get_preferred_size()`, but not by
`get_preferred_width()` and `get_preferred_height()`. Those simply try
to ask the layout manager and will return [0, 0] for actors without
children. So be consistent and also return the content size in those two
functions.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1019
In XDND, we just get a hint on XdndPosition about what's the action
chosen by the user. Make the data source actions the full set on
XdndEnter (as we can't know better), and pass the hint in XdndPosition
as the user chosen action as it should be.
Makes Wayland drop sites aware of the user action as per XDND with X11
drag sources, and still makes modifiers during DnD work.
https://gitlab.gnome.org/GNOME/mutter/issues/974https://gitlab.gnome.org/GNOME/mutter/merge_requests/1005
The gamma value pointers of the current_state are overwritten by the
calls to memdup causing a small leak. while the leak itself is small, it
can be triggered quite often from things like night light.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1020
The acked configuration is removed from the pending configuration list
by acquire_acked_configuration(), but finish_move_resize() does not free
the data after applying the configuration.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1020
As recommended by the docs for `g_settings_schema_source_get_default`:
> The returned source may actually consist of multiple schema sources
> from different directories, depending on which directories were given
> in XDG_DATA_DIRS and GSETTINGS_SCHEMA_DIR. For this reason, all lookups
> performed against the default source should probably be done recursively.
Now it's actually found and works again, including subpixel font smoothing.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1447https://gitlab.gnome.org/GNOME/mutter/merge_requests/1017
ClutterActors width and height can be reset to automatically use the
preferred (calculated) value by setting the width or height to -1, so
far this only works by setting it using `clutter_actor_set_width()` or
`clutter_actor_set_height()`, make sure it can also be done using the
"width" and "height" GObject properties.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1018
Where possible, try to export the buffer rendered by the primary GPU as a
dmabuf and import it to the secondary GPU and turn it into a DRM FB for
scanout. If this works, we get a zero-copy path to secondary GPU outputs.
This is especially useful on virtual drivers like EVDI (used for DisplayLink
devices) which are not picky at all about what kind of FBs they can handle.
The zero-copy path is prioritised after the secondary GPU copy path, which
should avoid regressions for existing working systems. Attempting zero-copy
would have the risk of being less performant than doing the copy on the
secondary GPU. This does not affect the DisplayLink use case, because there is
no GPU in a DisplayLink device.
The zero-copy path is prioritised before the primary GPU and CPU copy paths. It
will be tried on the first frame of an output and the copy path is executed
too. If zero-copy fails, the result from the copy path will take over on that
frame. Furthermore, zero-copy will not be attemped again on that output. If
zero-copy succeeds, the copy path is de-initialized.
Zero-copy is assumed to be always preferable over the primary GPU and CPU copy
paths. Whether this is universally true remains to be seen.
This patch has one unhandled failure mode: if zero-copy path first succeeds and
then fails later, there is no fallback and the output is left frozen or black.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
With all the three paths this is quite a handful of code, and it was mostly
duplicated in two places. A follow-up patch would need to introduce a third
copy of it. Therefore move the code into a helper function.
There are two behavioral changes:
- The format error now prints the string code as well, because it is easy to
read.
- The g_debug() in init_dumb_fb() is removed. Did not seem useful.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
There will be another place where I need to release the dumb buffers but not
destroy the whole secondary_gpu_state, so extract this bit of code into a
helper.
The checks of fb_id are dropped as redundant with the check already in in
release_dumb_fb ().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
release_dumb_fb () checks 'map' to see if anything needs freeing. Other places
are checking fb_id instead. The checks maybe redundant, but let's reset all
fields here while at it, so that all the checks work as expected.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
Simplify the bo freeing functions by not checking what the copy mode is. This
matches what swap_secondary_drm_fb () already does. g_clear_object () is safe
to call even if the value is already NULL.
The copy mode does not change mid-operation. If it did, this change would
ensure we still clean up everything. So this is more future-proof too.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
To mirror what happens in meta_onscreen_native_swap_buffers_with_damage(), warn
here too if next_fb is not NULL. This makes it clear to the reader of what the
expectations are inside this function.
Ensuring next_fb is NULL as the first thing in the function will make all error
paths equal: no longer some failures reset next_fb while others don't. Removing
such special cases should reduce surprises.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/810
Just pass it in to the vertex shader like in GLES, it's one less thing
to vary between drivers. mutter is, shall we say, not a heavy user of
point primitives, so any performance impact (it might be measurable, who
knows) is not an issue. Again, the feature flag remains to be cleaned up
in a future commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/995
We're always running through the GLSL pipeline so the fixed-function
alpha test is never invoked. This change does not yet remove the
alpha-test feture bit from the context because this bit of uniform
handling is going to be simplified in a future commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/995
If we end up trying to do a mode set on a DRM state that has already
changed behind our back without us yet having seen the hotplug event we
may fail with `EINVAL`. Since the renderer layer doesn't handle mode set
failure, it'll still try to page flip later on, which will then also
fail. When failing, it'll try to look up the cached mode set in order to
retry the mode set later on, as is needed to handle other error
conditions. However, if the mode set prior to the page flip failed, we
won't cache the mode set, and the page flip error handling code will get
confused.
Instead of asserting that a page flip always has a valid cached mode set
ready to look up, handle it being missing more gracefully by failing to
mode set. It is expected that things will correct themself as there
should be a hotplug event waiting around the the corner, to reconfigure
the monitor configuration setting new modes.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/917https://gitlab.gnome.org/GNOME/mutter/merge_requests/1007
On Xwayland, freezing actor updates on sync requests means the
server-side frame and shadows repaint will be frozen as well, which
causes the shadow to show black at times when resizing X11 clients
which support NET_WM_SYNC.
Using freeze/thaw commits prevents the content from changing, yet the
shape window still needs to be updated when frozen otherwise the
difference in shape induced by the on-going resize operation will show
as well, even if the toplevel window has its commits frozen.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
Closes: https://bugzilla.gnome.org/show_bug.cgi?id=767212
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/858
To address the black shadows that sometimes show during resize with
Xwayland, we need to update the window shape regardless of the frozen
status of the window actor.
However, plain Xorg does not need this, as resized windows do not clear
to black, so add a new vfunc to window/x11 to indicate whether or not
the backing windowing system (either plain X11 or Xwayland) would
require the shape to be always updated.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
Currently, the window actor freeze/thaw implementation sets the frozen
state of the surface actor using `meta_surface_actor_set_frozen()`.
If we want to expand that behavior to also freeze/thaw commits for X11
windows running on Xwayland, we need to have a specific vfunc to abstract
that in the window actor specific implementation.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
To make sure the frame is painted before the commits are thawed, freeze
the commits when invalidating the GDK window, only to thaw to it after
the actual frame draw is performed or the frame is destroyed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
Make sure we freeze commits before resizing the window as this will
clear the frame to black.
Set the "thaw on paint" flag so that the post paint for window actor X11
can then thaw the freeze initiated prior to the resize and keep the
freeze/thaw balanced.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
To be able to thaw commits following a resize that might have frozen
commits, to keep freezes and thaws even, we need a way to tell whether
a repaint should also thaw commits.
Add a flag to `MetaWindowX11` and the appropriate functions to set and
query it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
Xwayland may post damages for an X11 window as soon as the frame
callback is triggered, while the X11 window manager/compositor has not
yet finished updating the windows.
If Xwayland becomes compliant enough to not permit updates after the
buffer has been committed (see [1]), then the partial redraw of the X11
window at the time it was posted will show on screen.
To avoid that issue, the X11 window manager can use the X11 property
`_XWAYLAND_ALLOW_COMMITS` to control when Xwayland should be allowed to
post the pending damages.
Add `freeze_commits()` and `thaw_commits()` methods to `MetaWindowX11`
which are a no-op on plain X11, but sets `_XWAYLAND_ALLOW_COMMITS` on
the toplevel X11 windows running on Xwayland.
[1] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/316
See-also: https://gitlab.gnome.org/GNOME/mutter/merge_requests/855https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
At the moment we only disarm the watchdog timer set up for SYNC counter
requests if we're in the middle of a resize operation.
It's possible that the resize operation finished prematurely by the user
letting go of the mouse before the client responded. If that happens, when the
client finally updates mutter will erroneously still have the watchdog timer
engaged from before until it times out, leading to resizes for the next second
or so to not get processed, and the client to get blacklisted from future sync
requests.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
This avoids using bogus geometric values from an unmapped actor to
determine whether an actor is on a logical monitor or not. This would
happen when committing to a subsurface of a yet to be mapped toplevel.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
Without 'wayland/surface-actor: Reset and sync subsurface state when
resetting' this test would fail.
This also adds a simple framework for testing lower level Wayland
semantics.
In contrast to the test-client and test-driver framework, which uses
gtk and tests mostly window management related things, this framework is
aimed to run Wayland clients made to test a particular protocol flow,
thus will likely consist of manual lower level Wayland mechanics.
A private protocol is added in order to help out clients do things they
cannot do by themself. The protocol currently only consists of a request
meant to be used for getting a callback when the actor of a given
surface is eventually destroyed. This is different from the wl_surface
being destroyed due to window destroy animations taking an arbitrary
amount of time. It'll be used by the first test added in the next
commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
As with most other state that ends up being pushed to the actor and the
associated shaped texture, also push the texture and the corresponding
metadata from the actor surface. This fixes an issue when a toplevel
surface was reset, where before the subsurface content was not properly
re-initialized, as content state synchronization only happened on
commit, not when asked to synchronize.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
A actor surface may be reset by an xdg_toplevel if a NULL buffer is
attached. This should reset the actor state of the toplevel to an empty
state, while unmapping the previous actor. Subsurfaces, however, should
stay intact, including their relationship to the toplevel. They should
also not be yanked away from the actor of the actor surface prior to it
resetting, so that a window-destroy animation can include the subsurface
actor.
This fixes a potential crash when a subsurface tries to commit to its
wl_surface after the destroy animation of the toplevel has finished, as
the actor would at that point have been destroyed and cleared from the
actor surface struct, causing a segmentation fault.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
Similar to wl_list_foreach(), add
META_WAYLAND_SURFACE_FOREACH_SUBSURFACE() that iterates over all the
subsurfaces of a surface, without the caller needing to care about
implementation details, such as leaf nodes vs non-leaf nodes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
While it's not very relevant now, as we would rarely create it anyway
since the buffer nor texture never changes for a surface, it will be in
the future, as the actor state (including its content,
MetaShapedTexture) will be synchronized by the MetaWaylandActorSurface
at a later point in time, and not by MetaWaylandSurface, at state
application time.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
The method `relative_motion_across_outputs` is used to adjust the
distance/delta of a mouse movement across multiple monitors to take the
different scale factors of those monitors into account. This works by
getting the adjacent monitors that the movement-line/vector intersects
with and adjusting the final position (or end point of the
movement-line) by multiplying the parts of the line spanning across
different monitors with the scale factors of those monitors.
In the end of this calculation, we always want to set the new end
coordinates of the relative motion to the new end coordinates of the
adjusted movement-line. We currently only do that if all adjacent
monitors the line is crossing actually exist, because only then we end
up inside the "We reached the dest logical monitor" else-block and set
`x` and `y` to the correct values. Fix that and make sure the returned
values are also correct in case an adjacent monitor doesn't exist by
adding separate `target_x` and `target_y` variables which we update during
each pass of the while loop so we're always prepared for the while loop
exiting before the destination monitor was found.
Thanks to Axel Kittenberger for reporting the initial bug and tracking
the issue down to `relative_motion_across_outputs`.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/774
Some ClutterOffscreenEffect subclasses, such as ClutterBrightnessContrastEffect,
early-return FALSE in pre-paint before chaining up. It's an important optimization
that avoids creating or updating the offscreen framebuffer.
However, if an offscreen framebuffer already exists by the time pre-paint fails,
it will be used *without* repaint the actor over it. That causes an old picture
of the actor to be displayed.
Fix that by always clearing the offscreen framebuffer when pre-paint fails.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/810https://gitlab.gnome.org/GNOME/mutter/merge_requests/992
When changing the 'enabled' property and disabling the offscreen effect,
it doesn't make sense to preserve the offscreen framebuffer. It's not
drawing, after all.
Furthermore, because ClutterOffscreenEffect only checks if the offscreen
framebuffer exists to decide whether or not to redraw, keeping the fbo
alive is a waste of resources.
Clear the offscreen framebuffer when the effect is disabled or enabled.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/810https://gitlab.gnome.org/GNOME/mutter/merge_requests/992
Touch-wise, those are essentially giant touchpads, but have no buttons
associated to the "touchpad" device (There may be pad buttons, but
those are not mouse buttons).
Without tap-to-click/drag, touch in those devices is somewhat useless
out of the box. Have them always enable these features, despite the
setting.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/968
From `meta_cullable_cull_out`:
```
Actors that may have fully opaque parts should also subtract out a region
that is fully opaque from @unobscured_region and @clip_region.
```
As we do no check for the intersection of these two elsewhere in the code,
let's substract from the clip region, too.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/985
FLT_MIN is the smallest *positive* number above 0 that can be
represented as floating point number. If this is used to initialize the
maximum x/y coordinates of a rectangle, this will always be used if all
x/y coordinates of the rectangle are negative. This means that picking
at 0,0 will always be a hit for such rectangles.
Since mutter creates such a window for server side decorations on X11,
this window will always be picked at 0,0 preventing clicking/hovering
the activities button in gnome-shell at that coordinate.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/893
Using the same scale for the window as the
logical monitor only works correctly when having
the experimental 'scale-monitor-framebuffer'
feature enabled.
Without this experimental feature, the stream
will contain a black screen, where the actual
window only takes a small part of it.
Therefore, use a scale of 1 for the non-
experimental case.
Patch is based on commit 3fa6a92cc5.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/976
At this point only the gl driver is at all aware of the difference
between core and compat contexts. COGL_PRIVATE_FEATURE_GL_FIXED is also
now quite misnamed, since we're using the GLSL pipeline even for pre-GL3
contexts. Remove the private feature and handle the few remaining
differences by checking the driver class inside the gl driver.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/973
There's quite a bit of CoglContext that properly belongs to the driver.
Add some hooks to allow the context to create/destroy such state. We
don't have driver-private storage in the CoglContext yet, though we
probably should.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/973
Podman can also be used to create the image. The only thing to keep in
mind with podman is to add --format docker, so that the image will be
compatible with all CI runners.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/966
'xwayland: Do not queue frame callbacks unconditionally' changed the
frame callback behavior of Xwayland surfaces so that they behave the
same way as other actor surfaces (e.g. xdg-shell ones), except for the
case when they are initially assigned.
Remove this special casing as well including the now incorrect comment,
so that the Xwayland surfaces behave the same as the others in this
regard also when assigning.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/964
The vfunc is not called when a surface commits its state, but when the
state is applied. Make this clearer by changing the name to
"apply_state" (and "pre_apply_state").
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
This changes how asynchronous window configuration works. Prior to this
commit, it worked by MetaWindowWayland remembering the last
configuration it sent, then when the Wayland client got back to it, it
tried to figure out whether it was a acknowledgment of the configuration
or not, and finish the move. This failed if the client had acknowledged
a configuration older than the last one sent, and it had hacks to
somewhat deal with wl_shell's lack of configuration serial numbers.
This commits scraps that and makes the MetaWindowWayland take ownership
of sent configurations, including generating serial numbers. The
wl_shell implementation is changed to emulate serial numbers (assuming
each commit acknowledges the last sent configure event). Each
configuration sent to the client is kept around until the client one. At
this point, the position used for that particular configuration is used
when applying the acknowledged state, meaning cases where we have
already sent a new configuration when the client acknowledges a previous
one, we'll still use the correct position for the window.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
In Wayland, window configuration is asynchronous. Window geometry is
constrained, the constrained geometry is sent to the client, and the
client will adapt its surface and acknowledge the configuration. When
acknowledged, we shouldn't reconstrain again, as that may invalidate the
constraint calculated for the configured size.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
Historically, wl_shell clients used to pretend the input region was
equivalent to the window geometry, so for "correctness" lets do that
here too. This makes wl_shell clients with drop shadow behave marginally
better than before.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
This moves the cached subsurface surface state into the generic
MetaWaylandSurface namespace. Eventually it'll be used by other surface
roles which as well aim to implement synhcronization.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
The name didn't communicate it was about surface state, and it somewhat
confusingly had the name "pending" in it, which could be confused with
the fact that while it's used to collect pending state, it's also used
to cache previously committed pending state.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
With the eventual aim of exposing the internals of MetaWaylandSurface
outside of meta-wayland-surface.c, make users of the pending state use a
helper to fetch it. While at it, rename the struct field to something
more descriptive.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
The intention of meta_window_wayland_move_resize() is to finish a
move-resize requested previously, e.g. by a state change, or a
interactive resize. Make the function name carry this intention, by
renaming it to meta_window_wayland_finish_move_resize().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
Presumably this function is supposed to be like
meta_kms_impl_simple_handle_page_flip_callback() but the condition in the
if-statement is inverted. Fix the inversion to make these two functions look
alike.
This is part 2 of 2 fixing a complete desktop freeze when drmModePageFlip()
fails with EINVAL and the fallback to drmModeSetCrtc() succeeds but the success
is not registered correctly as completed "flip". The freeze occurs under
wait_for_pending_flips() which calls down into meta_kms_impl_device_dispatch()
which ends up poll()'ing the DRM fd even though drmModeSetCrtc() will not
produce a DRM event, hence the poll() never returns. The freeze was observed
when hotplugging a DisplayLink dock for the first time on Ubuntu 19.10.
This patch makes meta_set_fallback_feedback_idle() actually end up calling into
notify_view_crtc_presented() which decrements
secondary_gpu_state->pending_flips so that wait_for_pending_flips() can finish.
CC stable: gnome-3-34
https://gitlab.gnome.org/GNOME/mutter/merge_requests/953
mode_set_fallback() schedules a call to mode_set_fallback_feedback_idle(), but
it is possible for Mutter to repaint before the idle callbacks are dispatched.
If that happens, mode_set_fallback_feedback_idle() does not get called before
Mutter enters wait_for_pending_flips(), leading to a deadlock.
Add the needed interfaces so that meta_kms_device_dispatch_sync() can flush all
the implementation idle callbacks before it checks if any "events" are
available. This prevents the deadlock by ensuring
mode_set_fallback_feedback_idle() does get called before potentially waiting
for actual DRM events.
Presumably this call would not be needed if the implementation was running in
its own thread, since it would eventually dispatch its idle callbacks before
going to sleep polling on the DRM fd. This call might even be unnecessary
overhead in that case, synchronizing with the implementation thread needlessly.
But the thread does not exist yet, so this is needed for now.
This is part 1 of 2 fixing a complete desktop freeze when drmModePageFlip()
fails with EINVAL and the fallback to drmModeSetCrtc() succeeds but the success
is not registered correctly as completed "flip". The freeze occurs under
wait_for_pending_flips() which calls down into meta_kms_impl_device_dispatch()
which ends up poll()'ing the DRM fd even though drmModeSetCrtc() will not
produce a DRM event, hence the poll() never returns. The freeze was observed
when hotplugging a DisplayLink dock for the first time on Ubuntu 19.10.
CC stable: gnome-3-34
https://gitlab.gnome.org/GNOME/mutter/merge_requests/953
When rendering on-stage, it might be necessary to push offscreen
framebuffers to the paint context by external consumers, such as
GNOME Shell effects.
Expose clutter_paint_context_push|pop_framebuffer().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/955
This means CoglContext is now also introspected, although its
constructor and some getters are skipped to avoid having to expose even
more types. This makes it possible to create pipelines using Javascript.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
They have been deprecated for a long time, and all their uses in clutter
and mutter has been removed. This also removes some no longer needed
legacy state tracking, as they were only ever excercised in certain
circumstances when there was sources (pipelines or materials) on the now
removed source stack.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
This means cogl_set_source_color*() that switches to the opaque or
blending pipeline, or cogl_source_set_texture() which switches to the
texture pipeline.
Left is the opaque pipeline, as it is still used to compare other
pipelines to check whether they are opaque or not, and as the default
pipeline still pushed to the source stack during initialization.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Change the warp modes test to sanity check CoglPrimitive based polygon
drawing instead of cogl_polygon(). This removes some checks, as
cogl_polygon() has explicitly documented special behaviour for automatic
wrap modes, which CoglPrimitive does not.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Stop using API that uses the implicit Cogl framebuffer stack, (e.g.
cogl_push_matrix()) and replace usage by the corresponding API taking an
explicit framebuffer (e.g. cogl_framebuffer_push_matrix()).
For offscreens etc, the offscreen framebuffer is still pushed to and
popped from the Cogl framebuffer stack, so that paint nodes still draw
to the right framebuffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
While we still push and pop to the Cogl framebuffer stack, as so is
still needed to render the actors correctly, don't use the API using the
implicit framebuffer stack ourself in the offscreen effect code.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Instead of using cogl_polygon(), which uses deprecated API, implement
polygon drawing using the CoglPrimitive API family. While the test might
have been used to explicitly test cogl_polygon() it could still be
useful to test the non-deprecated way of rendering polygons.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Port tests to use API such as cogl_framebuffer_push_matrix() instead of
cogl_push_matrix() all over the Clutter tests, with one exception:
cogl_polygon(). It'll be ported over in a separate commit, as it is less
straight forward.
Implicitly set CoglMaterial properties are changed to explicitly created
and destructed CoglPipelines with the equivalent properties set.
cogl_push|pop_framebuffer() is replaced by explicitly passing the right
framebuffer, but tests still rely on cogl_get_draw_framebuffer() to get
the target framebuffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
clutter_paint_node_get_framebuffer() fell back on
cogl_get_draw_framebuffer() when the root node didn't have a custom
get_framebuffer vfunc. As this relies on deprecated implicit Cogl stack
API, it needs to go away, so handle this in the caller that knows more
about the context.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Instead of using the intermediate stage state "active framebuffer" to
find the framebuffer a paint eventually targets, use the "base
framebuffer" of the paint context, as this more correctly corresponds to
the end point of a paint. It also means we can then later remove this
intermediate state from the stage.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Instead of pushing and popping the Cogl framebuffer stack, use the
framebuffer passed around using the pick context. This removes usage of
the deprecated framebuffer stack when picking.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Rendering off stage we never cull, and previously this was checked by
comparing the "active framebuffer" of the stage, to the current
framebuffer in the cogl stack. Replace this by checking whether the
current paint context is currently drawing on stage or not.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Just as with painting, add a pick context that carries pick related
temporary state when doing actor picking. It is currently unused, and
will at least at first still carry around a framebuffer to deal track
view transforms etc.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
When painting, actors rely on semi global state tracked by the state to
get various things needed for painting, such as the current draw
framebuffer. Having state hidden in such ways can be very deceiving as
it's hard to follow changes spread out, and adding more and more state
that should be tracked during a paint gets annoying as they will not
change in isolation but one by one in their own places. To do this
better, introduce a paint context that is passed along in paint calls
that contains the necessary state needed during painting.
The paint context implements a framebuffer stack just as Cogl works,
which is currently needed for offscreen rendering used by clutter.
The same context is passed around for paint nodes, contents and effects
as well.
In this commit, the context is only introduced, but not used. It aims to
replace the Cogl framebuffer stack, and will allow actors to know what
view it is currently painted on.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
It's not always clear how the dma-buf functions work (e.g. where memory
is allocated) without actually going in-depth in the code. This just
adds a few commments to more quickly gain understanding.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/871
Checking the leds is not really accurate, since some devices have mode
switch buttons without leds. Check in the button flags whether they are
mode switch buttons for any of ring/ring2/strip/strip2, and return the
appropriate group.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/952
While most of the code to compute a window's layer isn't explicitly
windowing backend specific, it is in practice: On wayland there are
no DESKTOP windows(*), docks(*) or groups.
Reflect that by introducing a calculate_layer() vfunc that computes
(and sets) a window's layer.
(*) they shall burn in hell, amen!
https://gitlab.gnome.org/GNOME/mutter/merge_requests/949
Most of the layer computation that the stack does actually depends
on the windowing backend, so we will move it to a vfunc.
However before we do that, split out the bit that will be shared.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/949
When a window that should be stacked above another one is placed in a lower
layer than the other window, we currently allow promoting it to the higher
layer when it has a "transient type". We should do the same when the window
is an actual transient of the other window.
This is particularly relevant for wayland windows, where types play a
much smaller role: Transient windows like non-modal dialogs (and since
commit 666bef7a, popup windows as well) currently end up underneath their
always-on-top parent.
https://gitlab.gnome.org/GNOME/mutter/issues/587
This was wrongly introduced in 75cffd0ec4. As the comment above explains, we
only want to queue redraws in response to surface/buffer damage.
This triggered a full redraw when using DMA buffers on Wayland as we currently
create a new texture on every buffer_attach(), breaking partial invalidation.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/947
There might be some inconsistent event for which we don't have a known
source device.
In the current state we don't handle them and we could crash when getting
the current device tool.
So, add an utility function that retrieves the source device for an event
that warns if no device is found, and use this for Motion, Key and Button
events.
In case we don't have a valid source in such case, just return early instead
of trying to generate invalid clutter events.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/823
Add an assert that we don't have a MetaWindow::monitor pointer that
points to an old MetaLogicalMonitor. After this, and the other
monitors-changed callbacks have been called, the old MetaLogicalMonitor
will be destoryed, thus if we didn't update the pointer here, we'll
point to freed memory, and will eventually crash later on.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/929
We do check the clip area as an optimization to know which input devices
might need updating state after a relayout (Assuming that if a device is
under a non-painted area, it's actor beneath didn't change).
Use the clip region for this, and drop the last usage of the clip region
bounds.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/867
This commit was split out from `cleanup: Use g_clear_signal_handler()
where possible` as it fixes an actual signal leak and should therefore
get backported to stable releases.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
This is inspired by 98892391d7 where the usage of
`g_signal_handler_disconnect()` without resetting the corresponding
handler id later resulted in a bug. Using `g_clear_signal_handler()`
makes sure we avoid similar bugs and is almost always the better
alternative. We use it for new code, let's clean up the old code to
also use it.
A further benefit is that it can get called even if the passed id is
0, allowing us to remove a lot of now unnessecary checks, and the fact
that `g_clear_signal_handler()` checks for the right type size, forcing us
to clean up all places where we used `guint` instead of `gulong`.
No functional changes intended here and all changes should be trivial,
thus bundled in one big commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
On wl_data_source destruction we used to indirectly unset the DnD selection
owner via the wl_resource destructor triggering the destruction of the
MetaWaylandDataSource, which would be caught through the weak ref set by
the MetaWaylandDragGrab.
This works as long as the grab is held, however we have a window between
the button being released and the drop site replying with
wl_data_offer.finish that the MetaWaylandDataSource is alive, but its
destruction wouldn't result in the call chain above to unsetting the DnD
source.
In other selection sources, we let the MetaWaylandDataDevice hold the
"ownership" of the MetaWaylandDataSource, and its weak ref functions unset
the respective MetaSelection owners. Do the same here, so the
MetaWaylandDataSource destruction is listened for all its lifetime.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/591
This is wrong for both clipboard and DnD, as the selection source
will still be able to focus another surface, and churn another
wl_offer.
We should just detach the data offer from the data source in this
case, and let the source live on. However, we should still check
that there is a source and an offer to finish DnD, do that when
handling the drop operation instead.
https://gitlab.gnome.org/GNOME/mutter/issues/591
Those were used to signal clipboard ownership around, but that got
replaced by MetaSelection and friends. These signals are no longer
listened on, so can be safely removed.
https://gitlab.gnome.org/GNOME/mutter/issues/591
The function create_texture() in test-wrap-modes.c takes a
TestUtilsTextureFlags. However a CoglTextureFlags is passed instead
in two calls. As the enums are identical this patch changes it to
use the TestUtils type.
The enum definitions:
typedef enum
{
COGL_TEXTURE_NONE = 0,
COGL_TEXTURE_NO_AUTO_MIPMAP = 1 << 0,
COGL_TEXTURE_NO_SLICING = 1 << 1,
COGL_TEXTURE_NO_ATLAS = 1 << 2
} CoglTextureFlags;
typedef enum
{
TEST_UTILS_TEXTURE_NONE = 0,
TEST_UTILS_TEXTURE_NO_AUTO_MIPMAP = 1 << 0,
TEST_UTILS_TEXTURE_NO_SLICING = 1 << 1,
TEST_UTILS_TEXTURE_NO_ATLAS = 1 << 2
} TestUtilsTextureFlags;
https://gitlab.gnome.org/GNOME/mutter/merge_requests/938
In _cogl_offscreen_gl_allocate we only want to perform certain actions if
COGL_OFFSCREEN_DISABLE_DEPTH_AND_STENCIL is not set in create_flags.
We perfrom this check with:
if (!offscreen->create_flags & COGL_OFFSCREEN_DISABLE_DEPTH_AND_STENCIL)
which is not correct as we negate the create_flags before the bitwise &.
It happens to work as intended though, as CoglOffscreenFlags only has one
element, and that element has the value 1. If the flag is not set then the
nagation of create_flags is true and the bitwise and with the element value
is true as well.
If any flag is set then the negation will give 0 and the bitwise & will be
false.
So while it works correctly it is fragile as either additional flags or a
change in the enum element value will break this check. This patch makes
things a bit more safe by adding parentheses to let the bitwise & happen
before the negation.
Definition of the enum:
typedef enum
{
COGL_OFFSCREEN_DISABLE_DEPTH_AND_STENCIL = 1
} CoglOffscreenFlags;
https://gitlab.gnome.org/GNOME/mutter/merge_requests/938
cogl_pipeline_get_front_face_winding() is supposed to return a CoglWinding. It
takes a CoglPipeline as argument and does the following input validation:
g_return_val_if_fail (cogl_is_pipeline (pipeline),
COGL_PIPELINE_CULL_FACE_MODE_NONE);
The returned COGL_PIPELINE_CULL_FACE_MODE_NONE is not a winding.
The function was added with this check 8 years ago in
5369b3c601
I do not see any of the two options in the CoglWinding as particularly good
choice for a return value on bad input, but let's go with
COGL_WINDING_CLOCKWISE as that is equivalent with the behavior for all
these years.
Definitions of the two enums:
typedef enum
{
COGL_WINDING_CLOCKWISE,
COGL_WINDING_COUNTER_CLOCKWISE
} CoglWinding;
typedef enum
{
COGL_PIPELINE_CULL_FACE_MODE_NONE,
COGL_PIPELINE_CULL_FACE_MODE_FRONT,
COGL_PIPELINE_CULL_FACE_MODE_BACK,
COGL_PIPELINE_CULL_FACE_MODE_BOTH
} CoglPipelineCullFaceMode;
https://gitlab.gnome.org/GNOME/mutter/merge_requests/934
CallyTexture is an accessibility object associated with ClutterTexture.
ClutterTexture is going away, so prepare by first removing the
accessibility object that would be constructed for it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/932
ClutterTexture is going to be removed, so remove interactive tests that
stand in the way for that. Some test texture features, while some makes
heavy use of ClutterTexture to implement their testing. Remove these
tests to prepare for the removal of ClutterTexture.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/932
ClutterTexture is deprecated, lets remove the trivial usage with a
simple gdk-pixbuf using constructor putting pixel contents into a
ClutterImage then putting said image in a plain ClutterActor.
Tested partially, as the interactive tests cannot be properly run at the
moment.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/932
As was with the tests run via meson test, for the interactive tests we
too need to configure the mutter backend and initialize things in order
to be able to run any tests.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/932
Properly take the panel_orientation_transform into account in
update_monitor_crtc_cursor. This fixes us sometimes drawing the cursor
on two monitors at the same time as we did not properly swap the crtc
width/height when a panel_orientation_transform is active.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/927
clutter_event_get_scroll_finish_flags() should return a ClutterScrollFinishFlags
but due to what looks like a bad copy/paste it instead returns a
ClutterScrollSource on asserts.
The definitions of the enums are these:
typedef enum
{
CLUTTER_SCROLL_SOURCE_UNKNOWN,
CLUTTER_SCROLL_SOURCE_WHEEL,
CLUTTER_SCROLL_SOURCE_FINGER,
CLUTTER_SCROLL_SOURCE_CONTINUOUS
} ClutterScrollSource;
typedef enum
{
CLUTTER_SCROLL_FINISHED_NONE = 0,
CLUTTER_SCROLL_FINISHED_HORIZONTAL = 1 << 0,
CLUTTER_SCROLL_FINISHED_VERTICAL = 1 << 1
} ClutterScrollFinishFlags;
The asserts would only return CLUTTER_SCROLL_SOURCE_UNKNOWN. This
is equal to CLUTTER_SCROLL_FINISHED_NONE which this patch uses
instead. Thus no functional change is intended. This only fixes a
compile warning.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/931
Clutter has a draw debug mode that allows for painting
paint volumes. Right now, this debug mode uses the old
immediate paint mode.
Switch the painting of paint volumes to use paint nodes,
and sneak a few minor style cleanups.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/890
Now that we unconditionally use ClutterActorNode to
paint ClutterActors, move the PAINT private flag to
the ClutterActorNode. This way, we can run the paint
on the actor anywhere inside the paint tree.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/890
It seems that sometimes these functions are called by Javascript in
GNOME Shell during tear down. This causes segfaults and crash reports,
but without any backtraces other than the entry and exit points into
gjs.
In order to get more useful information about where these calls come
from, validate the input passed gracefully, by complaining in the log
and returning NULL values.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/926
Add missing clutter_x11_[un]trap_x_errors around the XIGetProperty call
in meta-input-settings-x11.c's get_property helper function.
This fixes mutter crashing with the following error if the XInput device
goes away at an unconvenient time:
X Error of failed request: XI_BadDevice (invalid Device parameter)
Major opcode of failed request: 131 (XInputExtension)
Minor opcode of failed request: 59 ()
Device id in failed request: 0x200011
Serial number of failed request: 454
Current serial number in output stream: 454
https://gitlab.gnome.org/GNOME/mutter/merge_requests/928
We currently assume that the actor_animate() helper function returns
a timeline. However Clutter may skip implicit animations and simple
set properties directly, for example when the actor is hidden.
The returned timeline will be NULL in that case, and we abort when
using it as instance parameter to g_signal_connect().
Fix this by only setting up a completed handler when we are actually
animating, and complete the effect directly otherwise.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/925
The actor is already in surface coordinate space, so we should not scale
with the buffer scale to transform surface coordinates to stage
coordinates.
This bug causes input method using wayland text-input protocol to
receive wrong cursor location. Reproduced in ibus (when candidate
window is open) with scaling factor other than 1.
This commit also fixes pointer confinement.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/915
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
Override-redirect windows have no workspace by default, and can't be parent
of a top-level window, so we must check that the parent window is not an
O-R one when setting the workspace state.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/895
We're expected by MetaWaylandSurface to always pick the frame callbacks
out from the pending state when committing (applying) so that no frame
callbacks are unaccounted for. We failed to do this if our actor for
some reason (e.g. associated window was unmanaged) was destroyed. To
handle this situation better, store away the frame callbacks until we
some later point in time need to pass them on forward.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/893
As noted in <cogl-texture-2d-gl.h> (now also removed), this is for
allowing external GL callers to promote one of their textures to a
CoglTexture. We aren't doing that and don't want to start.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/883
For stable branches, we currently only check out the correct shell
branch for merge requests. For the regular pipeline, our code to
determine the current mutter branch fails because CI runs on a
temporary "pipeline/12345" branch that doesn't exist for gnome-shell.
Switching to the correct gitlab environment variable fixes that.
https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/811
We ask XLib the next request serial number before performing other actions
triggered by meta_x11_display_set_input_focus_internal() that doesn't use
the request serial anyways. So, just request it before updating the focus
window as that's the operation that needs it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/909
When using DesktopIcons extension and clicking in an icon, gnome-shell
starts an infinite loop caused by the first focus change that may trigger
on X11 a focus in/out event that leads to stage activation/deactivation
which never ends.
This happens because as part of meta_x11_display_set_input_focus_xwindow()
to focus the X11 stage window, we unset the display focus, but this also
causes to request the X11 display to unset the focus since we convolute by
calling meta_x11_display_set_input_focus() with no window, that leads to
focusing the no_focus_window and then a focus-in / focus-out dance that the
shell amplifies in order to give back the focus to the stage.
In order to fix this, mimic what meta_display_set_input_focus() does, but
without updating the X11 display, and so without implicitly calling
meta_x11_display_set_input_focus(), stopping the said convolution and
properly focusing the requested xwindow.
Also ensure that we're not doing this when using an older timestamp, since
this check isn't performed anymore.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/896
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/899https://gitlab.gnome.org/GNOME/mutter/merge_requests/909
This function is already checking for the focus surface client
matching the requestor. The type check was slightly bogus though
as it'd be an screwup in our code, make it an assert instead.
Also, move the check for the client having the focus into the
upper call, so this and wl_data_device.set_selection code can
get more in line.
https://gitlab.gnome.org/GNOME/mutter/issues/878
We have an abstract MetaWaylandDataSource and 2 subclasses for
clipboard/primary data sources. Since the abstraction provided
by the additional sublevel is arguable, push the wl_resource
field up, and leave us with just 2 objects to think about, all
of them containing a wl_resource.
https://gitlab.gnome.org/GNOME/mutter/issues/878
Otherwise we'll end up trying to access the out of date state later.
Fixes the following test failure backtrace:
#0 _g_log_abort ()
#1 g_logv ()
#2 g_log ()
#3 meta_monitor_manager_get_logical_monitor_from_number ()
#4 meta_window_get_work_area_for_monitor ()
#5 meta_window_get_tile_area ()
#6 constrain_maximization ()
#7 do_all_constraints ()
#8 meta_window_constrain ()
#9 meta_window_move_resize_internal ()
#10 meta_window_tile ()
https://gitlab.gnome.org/GNOME/mutter/merge_requests/912
`meta_surface_actor_is_obscured` implies that the actor got successfully culled
out and nothing of it will get painted. This includes that there are no clones,
no effects etc. In this cases we don't want to send frame callbacks, thus avoiding
unnecessary client work.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/918
When setting the root node as child of a clip or transform node, we add a
new reference to it, without removing the one that we've previously added
when getting it from the actor node (and that won't ever be unset by the
auto-pointer since the root_node is re-associated).
So, once we add the root node as child and re-define it, unref it.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/908
Create the intermediate shadow framebuffer for use exclusively when a
shadowfb is required.
Keep the previous offscreen framebuffer is as an intermediate
framebuffer for transformations only.
This way, we can apply transformations between in-memory framebuffers
prior to blit the result to screen, and achieve acceptable performance
even with software rendering on discrete GPU.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/877
Previously, we would use a single offscreen framebuffer for both
transformations and when a shadow framebuffer should be used, but that
can be dreadfully slow when using software rendering with a discrete GPU
due to bandwidth limitations.
Keep the offscreen framebuffer for transformations only and add another
intermediate shadow framebuffer used as a copy of the onscreen
framebuffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/877
A compositor is notably opaque (usually has nothing to be painted on!).
gnome-shell sets this hint, but there's no reason why we wouldn't want
it by default.
Also, the color buffer being cleared messes with stencil clips, as the
clear operation by definition ignores the stencil buffer. We want to
use these more extensively in the future, so just drop this API.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/911
This is a workaround for X11 games which use randr to change the resolution
in combination with NET_WM_STATE_FULLSCREEN when going fullscreen.
Newer versions of Xwayland support the randr part of this by supporting randr
resolution change emulation in combination with using WPviewport to scale the
app's window (at the emulated resolution) to fill the entire monitor.
Apps using randr in combination with NET_WM_STATE_FULLSCREEN expect the
fullscreen window to have the size of the emulated randr resolution since
when running on regular Xorg the resolution will actually be changed and
after that going fullscreen through NET_WM_STATE_FULLSCREEN will size
the window to be equal to the new resolution.
We need to emulate this behavior for these games to work correctly.
Xwayland's emulated resolution is a per X11 client setting and Xwayland
will set a special _XWAYLAND_RANDR_EMU_MONITOR_RECTS property on the
toplevel windows of a client (and only those of that client), which has
changed the (emulated) resolution through a randr call.
This commit checks for that property and if it is set adjusts the fullscreen
monitor rect for this window to match the emulated resolution.
Here is a step-by-step of such an app going fullscreen:
1. App changes monitor resolution with randr.
2. Xwayland sets the _XWAYLAND_RANDR_EMU_MONITOR_RECTS property on all the
apps current and future windows. This property contains the origin of the
monitor for which the emulated resolution is set and the emulated
resolution.
3. App sets _NET_WM_FULLSCREEN.
4. We check the property and adjust the app's fullscreen size to match
the emulated resolution.
5. Xwayland sees a Window at monitor origin fully covering the emulated
monitor resolution. Xwayland sets a viewport making the emulated
resolution sized window cover the full actual monitor resolution.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/739
Add an adjust_fullscreen_monitor_rect virtual method to MetaWindowClass
and call this from setup_constraint_info() if the window is fullscreen.
This allows MetaWindowClass to adjust the monitor-rectangle used to size
the window when going fullscreen, which will be used in further commits
for a workaround related to fullscreen games under Xwayland.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/739
This reverts commit 4918893326.
This commit prevented cogl_stage_cogl_redraw_view() from skipping
swap buffers entirely if the invalidation region ended up empty.
This meant we were actually swapping buffers when we didn't need to.
The source of the glitches was fixed more properly, so this just adds
extra work.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/898
Unknown since when, we started deferring the eglMakeCurrent for the
current framebuffer till we started painting on it, which means we
are preparing for rendering a view without guarantees that the
framebuffer we will paint to is the current drawing surface for the
EGL context.
A fairly common case where that assumption will break is multimonitor
set ups, in this case we will be preparing to paint to a view while
the current draw surface is that of the previously rendered view's.
Mesa will in this case return EGL_BAD_SURFACE when querying the buffer
age, since the surface is not yet the current draw surface. This
makes us give up on buffer age checks, and paint the whole view. Since
the problem repeats when painting the next view, we are effectively
doing full-screen redraws on all monitors.
Since cogl usually works implicitly, and querying the buffer age is
meaningless if you're not meant to paint on a surface, make the surface
the current draw surface implicitly before querying the buffer age.
This brings us glorious partial invalidations back when several views
had to be repainted.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/906
In order to avoid log spamming, just warn once it starts to happen, not
on every frame for every onscreen. Just knowing that this is happening
is a hint that something's going wrong.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/906
Say you're using intel gen3, you poor soul. Your big-GL maxes out at 1.5
unless you use dirty tricks, but you do have GLES2. We try to fall back
to GLES in this case, but we only ever say eglBindAPI(EGL_OPENGL_API).
So when we go to do CreateContext, even though we think we've requested
GLES 2.0, the driver will compare that "2.0" against the maximum big-GL
version, and things will fail.
Fix this by binding EGL_OPENGL_ES_API before trying a GLES context.
https://gitlab.gnome.org/GNOME/mutter/issues/635
In find_onscreen_for_xid() we want to loop over the framebuffers
and skip any that is not onscreen.
The code today does this by negating the framebuffer type variable
and skipping if that equals COGL_FRAMEBUFFER_TYPE_ONSCREEN. This
actually works as the enum used will function as a boolean:
typedef enum _CoglFramebufferType {
COGL_FRAMEBUFFER_TYPE_ONSCREEN,
COGL_FRAMEBUFFER_TYPE_OFFSCREEN
} CoglFramebufferType;
But it is a bit weird logic and fragile if more types are added.
(not that I can think of any different type...)
To simplify this, and to silence a warning in clang this patch just
changes it to a != test.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/905
There are still environment variables for these controls, but having
them in a config file doesn't really make sense for mutter. Even if it
did we probably don't want to be parsing the same file as some
standalone version of cogl.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/902
Since 3.34, the gnome-shell package was cleaned up to only depend
on gnome-control-center-filesystem at build-time. However one of
the gnome-shell tests needs the gettext ITS file for keybindings
provided by the main gnome-control-center package (in fact, the
COPR package is stripped down to just that file), so install that
explicitly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/901
This allows xdg_popup.grab() to work with styli. Without this check
we would bail out and emit xdg_popup.popup_done, leaving stylus users
unable to interact with popup menus, comboboxes, etc...
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/886
When a touch sequence was rejected, the emulated pointer events would be
replayed with old timestamps. This caused issues with grabs as they
would be ignored due to being too old. This was mitigated by making sure
device event timestamps never travelled back in time by tampering with
any event that had a timestamp seemingly in the past.
This failed when the most recent timestamp that had been received were
much older than the timestamp of the new event. This could for example
happen when a session was left not interacted with for 40+ days or so;
when interacted with again, as any new timestamp would according to
XSERVER_TIME_IS_BEFORE() still be in the past compared to the "most
recent" one. The effect is that we'd always use the `latest_evtime` for
all new device events without ever updating it.
The end result of this was that passive grabs would become active when
interacted with, but would then newer be released, as the timestamps to
XIAllowEvents() would out of date, resulting in the desktop effectively
freezing, as the Shell would have an active pointer grab.
To avoid the situation where we get stuck with an old `latest_evtime`
timestamp, limit the tampering with device event timestamp to 1) only
pointer events, and 2) only during the replay sequence. The second part
is implemented by sending an asynchronous message via the X server after
rejecting a touch sequence, only potentially tampering with the device
event timestamps until the reply. This should avoid the stuck timestamp
as in those situations, we'll always have a relatively up to date
`latest_evtime` meaning XSERVER_TIME_IS_BEFORE() will not get confused.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/886
This way, we can simply pop up the Looking Glass and run:
>>> Meta.add_clutter_debug_flags(Clutter.DebugFlag.PICK, 0, 0)
And measure specific actions or events on GNOME Shell.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/862
As we do not prevent the SwapBuffers call from happening, those also
do count. Results in clip area calculations to be right for monitors
that previously did not get invalidated.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/888
Rather than just the latest one, otherwise it might leave the patch
submitter to iterate over every commit, if they didn't know every patch
needed a reference.
Closes: #1809
The passive phrasing makes it sound like there's something inherently
broken with the commit, rather than simply being missing an annotation
that the author can add.
Closes: #1809
Make ClutterActor paint using ClutterTransformNode, ClutterClip
node, and ClutterActorNode. Essencially, the actor node is a
replacement for clutter_actor_continue_paint().
An interesting aspect of this commit is that the order of the
operations is reversed to be preserved.
Before being able to remove the dummy node hack, we'll need to
make ClutterEffects compatible with paint nodes first -- and
naturally, that's enough content for its own merge request.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/872
ClutterActorNode is a paint node that runs the 'paint'
function of an actor. It is a useful helper node to be
used during the transition to paint nodes.
The role of ClutterActorNode will change over time. For
now, it is just a call to clutter_actor_continue_paint(),
which also paints the effects. When ClutterEffect is
ported to paint nodes, ClutterActorNode will morph to
only notify the actor about the painting, and will become
a private node to Clutter.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/872
In a similar vein to commit 8fd55fef85. This notably failed when setting
the focus on the stage (eg. to redirect key events to Clutter actors).
Deeper in MetaDisplay focus updating machinery, it would check
meta_stage_is_focused() which would still return FALSE at the time it's
called.
This would not typically have side effects, but our "App does not respond"
dialogs see the focus change under their feet, so they try to bring
themselves to focus again. This results in a feedback loop.
Changing the order results in later checks on the X11 POV of the focus
being correct, so focus is not mistakenly stolen from the close dialog,
and it actually succeeds in keeping the key focus.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1607https://gitlab.gnome.org/GNOME/mutter/merge_requests/876
This is a _little_ strange, as we still fill in the vtable slot for
glRenderbufferStorageMultisampleIMG, and can in principle still call it.
But that feature was weird to begin with as we were only checking for
that function in big-GL contexts despite that its extension is for GLES.
I'll leave cleaning that up to a future pass.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/866
This was only promoted to core in 3.0, but Mesa's supported it
unconditionally since around 7.0 even in 2.1 contexts, so this is not a
particularly onerous requirement.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/866
Syncronized subsurfaces that call into `merge_pending_state` might
otherwise not create new destroy handlers, ending up with a invalid
handler ids, throwing errors and leaking.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/868
It might be the case that handling an event induces the stream to
trigger completion, hence removing itself from the list. In that
case we would operate on the no longer valid list element to fetch
the next one.
Keep a pointer to the next element beforehand, so we can tiptoe
over streams that did remove themselves.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/869
The streams were only detached from MetaX11Display (and its event handling)
on completion. This is too much to expect, and those might be in some
circumstances replaced while operating.
Make those streams detach themselves on dispose(), so we don't trip into
freed memory later on when trying to dispatch unrelated X11 selection events.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/869
Instead of doing a roundtrip to the X server before setting it, rely on
the previous value fetched before the configuration was sent over DBus.
This matches the argument check we already do elsewhere, and will allow
us to more easily add an additional condition to determine if underscan
is supported.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/673
Midscene tracking was used at a time that some Cogl users
could call random OpenGL API without going through Cogl.
That is not allowed anymore, and certainly not done by
Mutter and GNOME Shell.
Remove midscene tracking from CoglFramebuffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/402
CoglJournal tracks a few OpenGL states so that they can
be batch-applied if necessary. It also has a nice property
of allowing purely CPU-based glReadPixels() when the scene
is composed of simple rectangles.
However, the current journal implementation leaves various
other GL states out, such as dithering and the viewport.
In Clutter, that causes the journal to be flushed when
picking, touching the GPU when we didn't really need to.
Track the viewport of the framebuffer in the journal so that
we can avoid flushing the journal so often.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/402
CoglFramebuffer checks the passed buffer bits in order to
detect when the fast path (that uses the journal) should
be used.
However, it also modifies one of the buffer bits that is
checked for the fast path, meaning we never actually hit
the fast path on cogl_framebuffer_cleaf4f().
Check the depth and color buffer bits before modifying them.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/402
Previously picking was done on an int (x,y) to address a particular pixel.
While `int` was the minimum precision required, it was also an unnecessary
type conversion.
The callers (input events mainly) all provide float coordinates and the
internal picking calculations also have always used floats. So it was
inconsistent and unnecessary to drop to integer precision in between those.
ABI break: This changes the parameter types for public function
`clutter_stage_get_actor_at_pos`, but its documentation is already
sufficiently vague to not need changing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/844
This is an extremely straightforward and minimalistic port of
CoglVector APIs to the corresponding Graphene APIs.
Make ClutterPlane use graphene_vec3_t internally too, for the
simplest purpose of keeping the patch focused.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
As the first step into removing Cogl types that are covered by
Graphene, remove CoglEuler and replace it by graphene_euler_t.
This is a mostly straightforward replacement, except that the
naming conventions changed a bit. Cogl uses "heading" for the
Y axis, "pitch" for the X axis, and "roll" for the Z axis, and
graphene uses the axis themselves. That means the 1st and 2nd
arguments need to be swapped.
Also adapt the matrix stack to store a graphene_euler_t in the
rotation node -- that simplifies the code a bit as well.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Mutter requires Clutter, which requires Cogl. That means
Clutter requires all Cogl dependencies, and Mutter requires
all Clutter dependencies as well.
However, currently, Clutter does not pull in its dependencies,
which means we need to link against Cogl manually.
Add Clutter dependencies to declare_dependency() so that the
graphene dependency only needs to be declared once, for Cogl,
and pulled together.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Graphene is a small library with data types and APIs
specially crafted to computer graphics. It contains
performant implementations of matrices, vectors, points
and rotation tools. It is performance because, among
other reasons, it uses vectorized processor commands
to compute various operations.
Add Graphene dependency to Mutter.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Graphene uses C99 and includes stdbool.h, which adds a
new 'bool' type. Clutter has an a11y test that names a
variable as 'bool' too, and they do not play well together.
Rename this variable to boolean.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
This is a deprecated property that is not used anywhere
in the codebase. Not by GNOME Shell. Because it uses the
deprecated ClutterGeometry type, it's a good target for
cleaning up, given that ClutterGeometry will be dropped
later on.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Fog is explicitly deprecated in favour of CoglSnippet API,
and in nowhere we are using this deprecated feature, which
means we can simply drop it without any sort of replacement.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Move out updating of various shapes (input, opaque, shape) indirectly
from X11 to the corresponding X11 sub types of MetaWindowActor and
MetaSurfaceActor.
Also move fullscreen window unredirection code with it. We want to
effectively do something similar for MetaCompositorServer, but it will
work differently enough not to share too much logic.
While it would have been nice to move things piece by piece, things were
too intertwined to make it feasible.
This has the side effect fixing accidentally and arbitrarily adding
server side shadow to Wayland surfaces.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/727https://gitlab.gnome.org/GNOME/mutter/merge_requests/734
It is opaque if the texture has no alpha channel, or if the opaque
region covers the whole content.
Internally uses a function that checks whether there is an alpha
channel. This API will be exposed at a later time as well.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/734
As we will start adding support for more pixel formats, we will need to
define a notion of planes. This commit doesn't make any functional
change, but starts adding the idea of pixel formats and how they (at
this point only theoretically) can have multple planes.
Since a lot of code in Mutter assumes we only get to deal with single
plane pixel formats, this commit also adds assertions and if-checks to
make sure we don't accidentally try something that doesn't make sense.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/858
When clutter actors with key focus are destroyed we emit ::key-focus-out on
them just after their destruction. This is against our assumption that no
signal should be emitted after "::destroy" (see GNOME/mutter!769 [1]), and
in fact could cause the shell to do actions that we won't ever stop on
destroy callback.
To avoid this to happen, use a private function to set its key-state (so we
can avoid looking for the stage) and emit ::key-focus-in/out events and use
this value in both clutter_actor_has_key_focus(),
clutter_actor_grab_key_focus() and on unmap and destruction to unset the
stage key focus before we emit the ::destroy signal.
As result of this, we can now avoid to unset the key focus on actor
destruction in the stage.
[1] https://gitlab.gnome.org/GNOME/mutter/merge_requests/769
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1704
Clutter had support for internal children in its early revisions, but they
were deprecated for long time (commit f41061b8df, more than 7 years ago) and
no one is using them in both clutter and in gnome-shell.
So remove any alternative code path that uses internal children.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/816
Instead of passing around an X11 Display pointer that is retrieved from
the default Gdk backend, then finding the MetaX11Display from said X11
Display, pass the MetaX11Display directly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/854
The functionality core/core.c and core/core.h provides are helpers for
the window decorations. This was not possible to derive from the name
itself, thus rename it and put it in the right place.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/854
This is for all intents and purposes the same as
`cogl_object_ref/unref`, but still refers to handles rather than
objects (while we're trying to get rid of the former) so it's a bit of
unnecessary redundant API.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/451
We were just looking at DnD actions which might still be unset at that
point. Instead of doing these heuristics, store the selection type on
the data offer.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/845
Requesting a selection with a NULL data source means "unset the clipboard",
but internally we use an unset clipboard as the indication that the
clipboard manager should take over.
Moreover, this unset request may go unheard if the current owner is someone
else than the MetaWaylandDataDevice.
Instead, set a dummy data source with no mimetypes nor data, this both
prevents the clipboard manager from taking over and ensures the selection
is replaced with it.
The MetaSelectionSourceMemory was also added some checks to allow for this
dummy mode.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/793
Instead of taking resource and send/cancel funcs, take a
MetaWaylandDataSource, which exposes all the vfuncs to do the same on the
internal resource.
This has the added side effect that only MetaWaylandDataSource has a
pointer to the wl_resource, which may be unset untimely.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/842
If a data source is destroyed we first unset the resource, and then try to
unref the related selection source. At this point the only event that might
be emitted by the internal selection machinery is .cancelled, so make sure
we avoid it on destroyed sources.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/842
We are still poking the mimetypes from the previous selection when creating
the new offer. This may come out wrong between changes of the copied
mimetypes.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/789
The default value of the ClutterShaderEffect:shader-type
property is CLUTTER_FRAGMENT_SHADER. However, because the
struct field is not actually initialized to it, it ends
up assuming the value 0, which is CLUTTER_VERTEX_SHADER.
Properly initialize ClutterShaderEffect's shader_type to
CLUTTER_FRAGMENT_SHADER.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/846
There are two common ways of building mutter: With both the native
backend and Wayland support (most common, used by most Linux distributions), and
without the native backend and Wayland support (as is done by some
BSD*s).
To catch compilation errors in both these common build configurations,
change the no-native-backend build phase to also not build with Wayland
support.
This also disables building mutter tests, as tests depend on Wayland to
run.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/837
Otherwise we'll get the warning
../src/core/main.c: In function 'meta_test_init':
../src/core/main.c:755:1: error: function might be candidate for attribute 'noreturn' [-Werror=suggest-attribute=noreturn]
755 | meta_test_init (void)
| ^~~~~~~~~~~~~~
when building without Wayland.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/837
If we did a mode set, the gamma may have been changed by the kernel, and
if we didn't also update the gamma in the same transaction, we have no
way to predict the current gamma ramp state. In this case, read the
gamma state directly from KMS.
This should be relatively harmless regarding the race conditions the
state prediction was meant to solve, as the worst case is we get none or
out of date gamma ramps; and since this is for when gamma ramps are not
updated at mode setting time, we'd get intermediate gamma state to begin
with, so it's not worse than what we currently do anyway.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/851https://gitlab.gnome.org/GNOME/mutter/merge_requests/840
Xkb events should be handled by clutter backend but they are not translated
into an actual clutter event. However we're now handling them and also trying
to push an empty event to clutter queue, causing a critical error.
So in such case, just handle the native event but don't push the non-populated
clutter-event to the queue.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/750https://gitlab.gnome.org/GNOME/mutter/merge_requests/764
A frame callback without damage is still expected to be responded to.
Implement this by simply queuing damage if there are any frame callbacks
requested and there is no damage yet. If there already is damage,
we'll be queued already, but with more correct damage. Without we simply
need to make sure we flush the callbacks if any area of surface is not
occluded.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/457https://gitlab.gnome.org/GNOME/mutter/merge_requests/839
It wasn't necessary (see other instances of -DG_LOG_DOMAIN) and somewhere
along the line it was getting turned into forward slashes becoming a syntax
error:
```
/usr/include/glib-2.0/gobject/gobject.h:767: syntax error, unexpected '/' in
...
g_assertion_message (/"CoglPango/",
```
https://gitlab.gnome.org/GNOME/mutter/merge_requests/841
The inhibited state of the monitor was after the initializiation never
updated. meta_idle_monitor_reset_idletime didn't respect the inhibited
state, so it set timeouts if it shouldn't have.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/573
For the most part, a MetaWindow is expected to live roughly as long as
the associated wl_surface, give or take asynchronous API discrepancies.
The exception to this rule is handling of reparenting when decorating or
undecorating a window, when a MetaWindow on X11 is made to survive the
unmap/map cycle. The fact that this didn't hold on Wayland caused
various issues, such as a feedback loop where the X11 window kept being
remapped. By making the MetaWindow lifetime for Xwayland windows being
the same as they are on plain X11, we remove the different semantics
here, which seem to lower the risk of hitting the race condition causing
the feedback loop mentioned above.
What this commit do is separate MetaWindow lifetime handling between
native Wayland windows and Xwayland windows. Wayland windows are handled
just as they were, i.e. unmanaged together as part of the wl_surface
destruction; while during the Xwayland wl_surface destruction, the
MetaWindow <-> MetaWaylandSurface association is simply broken.
Related: https://gitlab.freedesktop.org/xorg/xserver/issues/740
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/762https://gitlab.gnome.org/GNOME/mutter/merge_requests/774
ClutterActor took a reference in its transition 'stopped' handler,
aiming to keep the transition alive during signal emission even if it
was removed during. This is, however, already taken care of by
ClutterTimeline, by always taking a reference during its 'stopped'
signal emission, so no need to add another one.
This also has the bonus of making reference ownership simpler, as well
as avoidance of double free if an actor was destroyed before a
transition has finished.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/828
We get implicit, thus auto-removed, transitions, then manage them
manually by stopping them and emitting "completed" signals. This doesn't
work since they are removed and freed when stopped. To be able to emit
the "completed" signal, hold a reference while stopping, so that we
still can emit the signal as before.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/828
Implicit transitions had a referenced taken while emitting the
completion signals, but said reference would only be released if it was
had remove-on-complete set to TRUE.
Change this to instead remove the 'is_implicit' state and mark all
implicit transitions as remove-on-complete. This fixes a
ClutterPropertyTransition leak in gnome-shell triggered by e.g. showing
/ hiding menus.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1740https://gitlab.gnome.org/GNOME/mutter/merge_requests/828
Dropping the grab has the side effect that the pointer will be re-picked,
and it might find another surface with a pointer constraint. If that were
the case, the focus change would try to add the pointer constraint before
the now old focus surface released its own.
Just invert these operations, so the constraint is unset before the repick
that might enable another pointer constraint.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/779
Just like sync_focus_surface() does, we shouldn't set a focus surface while
the pointer is hidden, so the illusion that there is none remains.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/779
We can't just update the state of the connector and CRTC from KMS since
it might contain too new updates, e.g. from a from a future hot plug. In
order to not add ad-hoc hot plug detection everywhere, predict the state
changes by looking inside the MetaKmsUpdate object, and let the hot-plug
state changes happen after the actual hot-plug event.
This fixes issues where connectors were discovered as disconnected while
doing a mode-set, meaning assumptions about the connectedness of
monitors elsewhere were broken until the hot plug event was processed.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/782https://gitlab.gnome.org/GNOME/mutter/merge_requests/826
After commit 75cffd0e ("shaped-texture: Implement ClutterContent"), the
input to the meta_wayland_tablet_tool_get_relative_coordinates function
is already scaled correctly. By scaling it again, all stylus events are
getting mapped to the screen incorrectly (for anything != 100% scaling).
See also: d3f30d9ehttps://gitlab.gnome.org/GNOME/mutter/merge_requests/830
Correct silly mistake where the MetaWaylandSurface was passed as the
user_data of the surface actor destroy signal handler, instead of the
expected MetaWaylandActorSurface.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/844
Instead of storing the result of meta_prop_get_latin1_string() into
a temporary string value, g_strdup-ing that temp value storing the
g_strdup result into window->sm_client_id and then g_free-ing the
temporary string, we can pass window->sm_client_id as the place where
meta_prop_get_latin1_string() stores its result, since the result
from meta_prop_get_latin1_string() is itself a g_strdup-ed string,
so there is no need to g_strdup it again.
Note this drops the check to only issue the
"Window %s sets SM_CLIENT_ID on itself ..." warning once. This check is
not necessary as update_sm_hints() is only called once at window
creation time and is never called again.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
Use g_strdup instead of malloc + strcpy, this also gets rid of a bunch
of error checking which is no longer necessary, also adjust the free
path accordingly.
Note that there was a malloc + XFree mismatch in the removed error-handling.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
latin1_string_from_results and utf8_string_from_results use g_strndup,
so the returned string should be freed with g_free, rather then with
free or XFree. This fixes all free-s of buffers returned by these 2
functions to properly use g_free.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
Use g_new0 instead of calloc for motif_hints_from_results and adjust
its callers to use g_free.
Note that in the process_request_frame_extents function this replaces
the wrong original mismatch of calloc + XFree with a matching g_malloc +
g_free pair.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
The final version of the function was changed to allow points that are
touching the edge of a quadrilateral to be counted as "inside". Update
the function documentation to refect this.
Also clarify that the function is written in such a way that it is
agnostic to clockwise or anticlockwise vertex ordering.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/783
In `clutter_stage_view_blit_offscreen()`, the given clipping rectangle
is in “view” coordinates whereas we intend to copy the whole actual
framebuffer, meaning that we cannot use the clipping rectangle.
Use the actual framebuffer size, starting at (0, 0) instead.
That fixes the issue with partial repainting with shadow framebuffer
when fractional scaling is enabled.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/820
Clutter actors might emit property changes in dispose, while unparenting.
However we assume that the ::destroy signal is the last one we emit for an
actor, and that starting from this moment the object is not valid anymore,
and so we don't expect any signal emission from it.
To avoid this, freeze the object notifications on an actor during its
disposition, just before the ::destroy signal emission.
Update the actor-destroy test to verify this behavior.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/769
Clutter actors unset their parent on dispose, after emitting the ::destroy
signal, however this could cause ::parent-set signal emission. Since we
assume that after the destruction has been completed the actor isn't valid
anymore, and that during the destroy phase we do all the signal / source
disconnections, this might create unwanted behaviors, as in the signal
callbacks we always assume that the actor isn't in disposed yet.
To avoid this, don't emit ::parent-set signal if the actor is being
destroyed.
Update the actor-destroy test to verify this behavior.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/769
Mutter issues a synchronous grab on the pointer for unfocused client
windows to be able to catch the button events first and raise/focus
client windows accordingly.
When there is a synchronous grab in effect, all events are queued until
the grabbing client releases the event queue as it processes the events.
Mutter does release the events in its event handler function but does so
only if it is able to find the window matching the event. If the window
is a shell widget, that matching may fail and therefore Mutter will not
release the events, hence causing a freeze in pointer events delivery.
To avoid the issue, make sure we sync the pointer events in case we
can't find a matching window.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/821
It was not the lack of forcing the shadow fb that caused slowness, but
rather due to the method the shadow fb content was copied onto the
scanout fb. With 'clutter: Use cogl_blit_framebuffer() for shadow FB'
we'll use a path that shouldn't be slow when copying onto the scanout
fb.
Also 437f6b3d59 accidentally enabled
shadow fb when using hw accelerated contexts, due to the cap being set
to 1 in majority of drivers. While the kernel documentation for the
related field says "hint to userspace to prefer shadow-fb rendering",
the name of the hint when exposed to userspace is
DRM_CAP_DUMB_PREFER_SHADOW, thus should only be taken into consideration
for dumb buffers, not rendering in general.
This reverts commit 437f6b3d59.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/818
The commit 'renderer/native: Use shadow fb on software GL if preferred'
attempted to force using a shadow fb when using llvmpipe in order to
speed up blending, but instead only did so when llvmpipe AND the drm
device explicityl asked for it.
Now instead always force it for llvmpipe and other software rendering
backends, and otherwise just query the drm device (i.e.
DRM_CAP_DUMB_PREFER_SHADOW).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/807
If there is no transformation, use `cogl_blit_framebuffer()` as a
shortcut in `clutter_stage_view_blit_offscreen()`, that dramatically
improves performance when using a shadow framebuffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/809
Since the recent clutter-content work, legacy scaling (in contrast
to the new stage-view-scaling) only applies to surfaces that belong
to a window. This broke scaling of DnD surfaces.
As a workaround, apply the same scaling on DnD-surface-actors until
we use stage-view-scaling by default and can remove this again.
Also: small corrections of geometry calculation
https://gitlab.gnome.org/GNOME/mutter/merge_requests/780
This allows us to implement more sophisticated logic for the different
cases. For DnD surfaces, use the geometry scale of the monitor where
the pointer is, instead of incorrectly assuming '1' as it was before.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/780
The meta_display_update_focus_window() call has indirect dependencies
on the X11 focus window, in order to determine the correct focus window
on the Wayland side (i.e. may turn out NULL with certain X windows).
In order to have the right x11_display->focus_xwindow there, we should
perform first the focus update on the X11 display.
Fixes focusing of Java applications, as those don't seem to go through
_NET_ACTIVE_WINDOW.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/819
With the addition of the locate-pointer special keybinding (defaults to
the [Control] key), we have now two separate special modifier keys which
can be triggered separately, one for the locate-pointer action and
another one for overlay.
When processing those special modifier keys, mutter must ensure that the
key was pressed alone, being a modifier, the key could otherwise be part
of another key combo.
As result, if both special modifiers keys are pressed simultaneously,
mutter will try to trigger the function for the second key being
pressed, and since those special modifier keys have no default handler
function set, that will crash mutter.
Check if the handler has a function associated and treat the keybinding
as not found if no handler function is set, as with the special modifier
keys.
https://gitlab.gnome.org/GNOME/mutter/issues/823
The `process_event()` would check for a existing keybinding handler and
abort if there is none, however the test is done after the handler had
been accessed, hence defeating the purpose of the check.
Move the check to verify there is an existing keybinding handler before
actually using it.
https://gitlab.gnome.org/GNOME/mutter/issues/823
There were multiple bugs present after the ClutterContent transition.
Refactor `get_image` to:
- always assume surface coordinates for the clip
- return a cairo_surface in buffer size
- make the offscreen path take size arguments, so we can
easily change the assumption in get_image
- fix some clipping bugs on the way
https://gitlab.gnome.org/GNOME/mutter/merge_requests/758
Delayed clutter timelines might be removed while they are still in the
process of being executed, but if they are not playing yet their delay
timeout won't be stopped, causing them to be executed anyway, leading to a
potential crash.
In fact if something else keeps a reference on the timelines (i.e. gjs), the
dispose vfunc delay cancellation won't take effect, causing the timelines to
be started and added to the master clock.
To avoid this, expose clutter_timeline_cancel_delay() function and call it
if a timeline is not playing but has a delay set.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/815https://gitlab.gnome.org/GNOME/mutter/merge_requests/805
If a timeline is delayed and we request to stop or pause it, we are emitting
the "::paused" signal on it, however this has never been started, and so
nothing has really be paused.
So, just try to cancel the delay on pause and return if not playing.
No code in mutter or gnome-shell is affected by this, so it is safe to
change.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/805
Some drivers expose EGL_EXT_image_dma_buf_import_modifiers so you can
query supported formats, but don't support any modifiers. Handle this by
treating it like DRM_FORMAT_MOD_INVALID.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/782
Clutter stage used to compute the initial projection using a fixed z
translation which wasn't matching the one we computed in
calculate_z_translation().
This caused to have a wrong initial projection on startup which was then
correctly recomputed only at the first paint.
However, since this calculation doesn't depend on view, but only on viewport
size, perspective's fovy and z_near we can safely do this at startup and
only when any of those parameters change.
Then we can move the computation out _clutter_stage_maybe_setup_viewport()
since the cogl framebuffer viewport sizes aren't affecting this.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1639https://gitlab.gnome.org/GNOME/mutter/merge_requests/803
GCC's manpage says that this flag does the following:
Do not store floating-point variables in registers, and inhibit other
options that might change whether a floating-point value is taken from
a register or memory.
This option prevents undesirable excess precision on machines such as
the 68000 where the floating registers (of the 68881) keep more
precision than a "double" is supposed to have. Similarly for the x86
architecture. For most programs, the excess precision does only good,
but a few programs rely on the precise definition of IEEE floating
point.
We rely on this behaviour in our fork of clutter. When performing
floating point computations on x86, we are getting the wrong results
because of this architecture's use of the CPU's extended (x87, non-IEEE
confirming) precision by default. If we enable `-ffloat-store` here,
then we'll get the same results everywhere by storing into variables
instead of registers. This does not remove the need to be correct when
handling floats, but it does mean we don't need to be more correct than
the IEEE spec requires.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/785
Instead of open coding the X11 focus management in display.c, expose
it as a single function with similar arguments to its MetaDisplay
counterpart. This just means less X11 specifics in display.c.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/751
MetaDisplay and MetaX11Display focus windows are slightly decoupled,
we cannot rely here on the MetaDisplay focus to be updated yet. We
however know the X Window that got focused, so lookup the corresponding
MetaWindow (and client X window) from it.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/751
We have a "setup" phase, used internally to initialize early the x11
side of things like the stack tracker, and an "opened" phase where
other upper parts may hook up to. This latter phase is delayed during
initialization so the upper parts have a change to connect to on
plugin creation.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/771
When starting standalone mutter and running using the native backend, we
always fall back on using the us pc105 keyboard layout. This can be very
frustrating if one is used to using some other keyboard layout, such as
dvorak, causing keyboard fumbling everytime when doing something with
standalone mutter.
Avoid this involuntary fumbling by having the default plugin query
localed what layout the user has actually configured the machine to
operate using. It doesn't add any keymap selection user interface, so
it'll always use the first one it encounters.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/787
The commit f2f4af0d50 missed one situation
where mutter does things differently, i.e. changes what surface actor is
associated with a given window actor: reparenting a Xwayland window when
changing whether it is decorated.
To summarize, there are three types of window actors:
X11 window actors - directly tied to the backing X11 window. The
corresponding surface actor is directly owned by the window actor and
will never change.
Wayland window actors - gets its surface actor from MetaWaylandSurface
at construction. A single MetaWaylandSurface may create and destroy
multiple window actors over time, but a single window actor will never
change surface actor.
Xwayland window actors - a mix between the above two types; the window
corresponds to the X11 window, and so does the window actor, but the
surface itself comes from the MetaWaylandSurface.
Normally when a X11 window is unmapped, the corresponding MetaWindow is
unmanaged. With Xwayland, this happens indirectly via the destruction of
the wl_surface. The exception to this is windows that are reparented
during changing their decoration state - in this case on plain X11, the
MetaWindow stays alive. With Xwayland however, there is a race
condition; since the MetaWindow is tied to the wl_surface, if we receive
the new surface ID atom before the destruction of the old wl_surface,
we'll try to associate the existing MetaWindow and MetaWindowActor with
the new wl_surface, hitting the assert. If the surface destruction
arrives first, the MetaWindow and MetaWindowActor will be disposed, and
the we wouldn't hit the assert.
To handle this race gracefully, reinstate handling of replacing the
surface actor of an existing window actor, to handle this race, as it
was handled before.
Eventually, it should be reconsidered whether the MetaWindow lifetime is
tied to the wl_surface or if it should be changed to be consistent with
plain X11, as this re-exposes another bug where the X11 client and
mutter will enter a feedback loop where the window is repeatedly
remapped. See https://gitlab.freedesktop.org/xorg/xserver/issues/740.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/709https://gitlab.gnome.org/GNOME/mutter/merge_requests/773
When using xdg-output v3 or later, the Wayland compositor does not send
xdg_output.done events which are deprecated.
Instead, it should send a wl_output.done event for the matching
wl_output.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/771
When suspending, the devices are removed and the virtual device
associated with the corresponding core pointer is disposed.
Add the pointer accessibility virtual device to the core pointer
on resume to restore pointer accessibility on resume if enabled.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/761
When starting a DnD operation, mutter would remove keyboard focus from
the client, only to restore it on the data offer destroy.
However, if the DnD fail, the keyboard focus is not restored, leaving
the user unable to type in the focused window, even after clicking in
the window.
That issue would show only on first attempt, as further DnD attempts
would destroy the previous data offer which would also restore the
keyboard focus.
Make sure we restore the keyboard focus on drag end as well.
https://gitlab.gnome.org/GNOME/mutter/issues/747
On drag start, `data_device_start_drag()` issues a keyboard grab, which
in turn will unset the current input focus.
There is not need to unset the input focus in `data_device_start_drag()`
as this is redone in `meta_wayland_keyboard_start_grab()`
https://gitlab.gnome.org/GNOME/mutter/issues/747
2019-09-02 17:06:06 +00:00
995 changed files with 46170 additions and 88614 deletions
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
