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
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
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
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
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
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
