For tablet device, the tool was created when the "Wacom Serial IDs" prop
changed values. This property does not exist on the xf86-input-libinput
driver but v1.5.0 of that driver has a different property for the serial.
The serial is constant (the driver creates one X device per serial), so
we can fetch it after device creation and set it then. For earlier
versions of the driver we assign the random serial 0xffffffaa - good
enough to have at least a tool.
This fixes the crash in #3120 - clutter_event_motion_new()
overrides event->device to the tool's device (if any). Without a tool
motion events use the Virtual Core Pointer instead and our source device
is never added to the stage's priv->pointer_devices.
When we generate an crossing event (which uses the source device) we
fall afoul of an assert in clutter_stage_update_device() that expects
our source device to be in priv->pointer_devices.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/3120
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3383>
DRM's kms atomic code was updated to include an API to set the mouse
cursor hotspot. This has historically been missing in the atomic kms
which meant that the virtualized drivers which require mouse cursor
hotspot info to properly render had to be put on a deny list and
had to fallback to the legacy DRM kms code.
Implement the new hotspot API by checking whether the device supports
hotspot properties and if it does set them on the cursor plane. This
enables atomic kms on all virtualized drivers for kernels where
mouse cursor hotspots are in drm core.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3337>
Add META_KMS_PLANE_PROP_HOTSPOT_[X,Y] properties
to the MetaKmsPlaneProp enumeration, and
properly initialise them.
Also, add a convenience method in meta-kms-plane
(i.e., `meta_kms_plane_supports_cursor_hotspot`)
to check whether a plane supports hotspot
property setting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3337>
Based on the pressure curve control points sample a bezier curve and
then look up the pressure at that point of the curve.
We sample 256 points and do linear interpolation in between, this
strikes a balance between having to calculate the point for all
8K pressure points a modern pen supports while still giving us
reasonable detailed curves.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3158
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3399>
This keeps the existing ClutterBezier implementation but changes
the visible API to match the needs of the tablet tool pressure curve:
a bezier defined within a [0.0/0.0, 1.0/1.0] box,(sampled
into a set of x->y mappings for each possible pressure input x, and
a lookup function to get those values out of the curve.
This patch moves the internally-only functions to be statics and changes
meta_bezier_init() to take only the second and third control point, as
normalized doubles. Because internally we still work with integers, the
bezier curve now has an integer "precision" that defines how many points
between 0.0 and 1.0 we can sample.
The meta_bezier_rasterize() function calculates the x->y mapping for
each point on the bezier curve given the initial scale of the curve.
That value is then available to the caller via meta_bezier_lookup().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3399>
The ClutterBezier code was removed in
580d62b9b clutter: Remove unused Path related types
because it wasn't used anywhere. We do need a bezier curve for the
tablet tool pressure curve calculation though so let's move it
to the native backend and rename it to MetaBezier in the process.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3399>
This addresses the following race condition:
1. Window+MetaFrame are created non-fullscreen, _MUTTER_FRAME_EXTENTS
is initialized through widget measuring, accounting for frame.
2. Window and MetaFrame become fullscreen.
3. MetaFrameContent gets first size allocation, already fullscreen.
4. Borders were initialized to 0,0,0,0, become set to 0,0,0,0 correctly
reflecting fullscreen, however notify::borders is not emitted.
5. _MUTTER_FRAME_EXTENTS stays accounting for the frame extents.
It sounds sensible to have the borders initialized to a meaningful value,
so account for the first time the border would be set due to the content
being (re)sized, and let this first value trigger notify::borders resulting
in _MUTTER_FRAME_EXTENTS updates.
Since all later _MUTTER_FRAME_EXTENTS changes happen through content
resizes, we only have to cater for this initial handover between the
frame/content initialization paths done through widget measuring and
the later paths done through MetaFrameContent resizes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2937
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3476>
The test makes sure the YCbCr formats create the expected image and we
don't accidentally break it.
Like all wayland tests, this is now part of mutter/wayland, mutter/tty,
and mutter/kvm and will use either shm or dma-buf depending on which
suite is chosen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3371>
Finding the shm offset and shm stride for each plane is the main issue.
The rest is just creating multiple textures for each plane.
One assumption is that shm planes are always contiguous in memory so the
next plane comes directly after the size of the current plane.
The size of a plane is determined by the height and stride. There is
only a single stride parameter for shm buffers but we assume that the
first plane is always non-subsampled which gives us a number of "logical
elements" on one line (stride / bpp of the first plane). The stride of
the other planes is then the number of logical elements devided by the
subsampling factor and multiplied by the bpp of the plane.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3371>
The assumption is that all planes are always contiguous, and we don't
have any multi-plane formats where the first plane is subsampled.
The stride of the entire buffer is then just the stride of the first
plane and the stride of the other planes is derived from that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3371>
Instead of forcing every user of WaylandBuffer to create a listener and
destroy the wl_resource and the WaylandBuffer object, provide a default
listener which does it for the user.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3371>
The texture coordinates of all planes should be the same in theory so
using the coordinates of the first plane works.
The reason for this change is that Cogl somehow doesn't manage to get us
the correct coordinates for the 3rd plane in some circumstances. This is
really a workaround but not wrong in any way.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3176
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3469>
ClutterInputFocus/GtkIMContext uses char based offset for
delete_surrounding, however, text_input_v3 uses byte based offset for
it. Currently only GTK with mutter can work correctly via text_input_v3
because they both forget to convert between char based offset and byte
based offset.
This commit fixes it in mutter by saving committed surrounding text in
MetaWaylandTextInput and converting char based offset to byte based
offset with the UTF-8 encoded surrounding text.
Fixes <https://gitlab.gnome.org/GNOME/mutter/-/issues/2146>.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2712>
Calculating the mipmap width as half of the texture width leads to a
mipmap width of zero for textures with width of 1 which leads to an
early exit instead of a mipmap texture.
Fixes: 16fa2100d ("shaped-texture: Stop using MetaTextureTower and use GL mipmapping instead")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3468>
A surface commit may change the buffer scale but not attach a new
buffer. In that case, the size of the previously attached buffer needs
to be consistent with the new buffer scale.
Fixes: 7649e2f3ab ("wayland/surface: Move buffer size check to meta_wayland_surface_commit")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3466>
meta_wayland_surface_get_buffer_width/height uses the currently applied
buffer, which may have a different size.
Fixes: 7649e2f3ab ("wayland/surface: Move buffer size check to meta_wayland_surface_commit")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3466>
Multiple reasons:
* More consistent with the protocol spec language.
* Ensures the size is checked and the protocol error sent from a
protocol processing context, instead of whatever context
meta_wayland_surface_commit might get called from.
* The latter implies that surface->resource is guaranteed to be valid.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3211
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3463>
Integrate it into the code, instead of depending on MetaDisplay
notify::focus-window for it. Now, instead of focusing explicitly the
stage window, we focus a NULL window, and let the MetaX11Display
determine whether focus should go to the stage window if there's
a focused actor, or the no_focus_window if nothing has focus.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3269>
We currently offer the mechanism for GNOME Shell to implement, and
while this is not exercised often (our entries are typically surrounded
by a ClutterGrab ensuring key events, so this is reserved to grab-less
entries, probably there are some in extensions), this is arguably
something Mutter should cover by itself without GNOME Shell guidance.
This is only necessary on the X11 backend, although it is conceptually
more tied to the MetaX11Display connection, so perform the focus
tracking there only if not running as a Wayland compositor (i.e. --x11).
This avoids the only case where the low-level
meta_x11_display_set_input_focus_xwindow() function is used, or rather
makes it completely a MetaX11Display implementation detail, leaving
only the MetaDisplay API as the high-level entry points to handle
window key focus.
The public API that allowed GNOME Shell to implement these mechanisms
is also gone in this commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3269>
There might not be a single plane that is "for" a CRTC, so remove the
API that made it appear as if it did. The existing users only cared if
there was some plane for said CRTC, so replace the getters with API that
just checks the existance at all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
When there are a set of primary planes, and a set of CRTCs, where each
plane can be used on multiple CRTCs, we need to make sure that when we
mode set and page flip, each CRTC gets assigned an individual plane that
isn't used with any other CRTC.
Do this during the monitor resource assignments that sets up later to be
applied configurations of the mode setting objects, but with the new
hooks into the backend, so that we don't need to teach the monitor
config manager about planes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2398
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
This means that it doesn't necessarily mean what transform / rotation
the hardware resource gets, e.g. it instead represents the logical
transform related to the configured mode. This allows us to postpone
checking the plane capabilities until later (as rotation capabilities
depends is a plane property), when a plane has been assigned.
This was in practice already handled when configuring the
transform-via-offscreen case, handled when creating the view, and the
mode setting configuration.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
When we're configuring monitors, allow backends to add backend specific
assignments during resource assignment (mapping connectors and CRTCs
etc).
This will later allow the native backend's KMS monitor resources to
assign a primary plane and optionally a cursor plane during
configuration. This will then dictate what plane will be used for
primary plane updates, as well as cursor updates, until reconfigured
again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
A set of primary planes can be usable with a set of CRTCs, meaning we
can't have general purpose functions that gets a plane for a CRTC, as
there is no such one to one relationship.
For tests we still want to have helpers that makes writing tests easier,
so to prepare for those functions going away, make the tests do the
equivalent themselves.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3428>
Musl doesn't seem to include this by default so explicitly including it
should fix compilation on Musl.
Tested with Clang 16/17 and GCC 14.
Error:
src/backends/meta-fd-source.c:70:3: error: call to undeclared function 'close'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
close (fd_source->poll_fd.fd);
^
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3078
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3455>
Otherwise a tablet in relative mode will never have a tool set and
nothing happens on motion events - meta_wayland_tablet_seat_update()
simply exits early for tablet proximity, button or motion events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3410>
The include is currently satisfied by
window-x11-private → iconcache → x11-display-private
The icon cache is about to be removed, so add the missing include
directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3452>
Changing the MultiTexture may require a different set of pipelines when
the texture format is different. We keep track of the attached
MultiTextureFormat just like we do for the width and height.
This fixes misrendering when a client attaches buffers with different
MultiTextureFormats to the same surface.
Fixes: 3dd9f15eb ("shaped-texture: Start using MetaMultiTexture")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3456>
We want to run those tests in VKMS later with the same reference image.
To make the tests as close to each other as possible we use the same
resolution for the VKMS and the virtual output which is 640x480.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3350>
This test currently only works because the monitor has the same width
and height. Generalize it to arbitrary monitor sizes by taking into
account that width and hight are swapped for some rotations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3350>
Most tests use the draw_surface function to draw a solid color to a
surface. This moves it from the shm-only path to WaylandBuffer which
makes all of those tests usable via dma-buf.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3350>
The custom drawing requires adjusting the test. Instead of poking at
memory directly, we can just draw a color at certain coordinates which
makes it independent of the pixel format used.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3350>
It abstracts away the kind of buffer so clients can be tested with both
shm and dma-buf paths. We'll make use of it in the future by adding the
wayland tests to the TTY and KVM test suits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3350>
When capturing the view we have to make sure the stage is actually
updated. In direct scanout mode the stage is unmodified and we can't
find the content we want to test.
Currently the ref-tests are all running on non-native setups where
direct scanout is impossible but we will change that soon!
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3350>
Transfer none was achieved using a stack GArray in the stage which
would get resized to 0 at the end of every frame to "free" it.
In the case of direct scanout however, painting the next frame only
happens after leaving fullscreen again. Until then the array just kept
growing and because GArrays don't reallocate when shrunk, this memory
remained allocated even after leaving fullscreen.
There is no cache benefit from storing paint volumes this way, because
nothing accesses them after their immediate use in the calling code.
Also the reduced overhead from avoiding malloc calls seems negligible as
according to heaptrack this only makes up about 2-3% of the temporary
allocations.
Changing this to transfer full and removing the stack array simplifies
the code and fixes the "leak".
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3191
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3442>
This is a step in cleaning up the Clutter context management. By making
it a GObject it's easier to add e.g. properties and features that helps
with introspection.
For now, this means the context creation is changed to go via a
"constructor" (clutter_create_context()). This is so that the global
context singleton can be mantained outsid of ClutterContext, until it
can be removed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2016>
The original purpose of being able to report errors is no longer
relevant, since the Clutter backend is now practically a thin wrapper
around the actual backend, which has already dealt with error reporting.
Thus move this to the regular constructor path.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2016>
The current usage of MetaWindow::unmanaging may result in confused
focus window lookups while undoing the MetaWindowDrag grab (i.e.
still pointing to the window that is now being unmanaged).
The meta_window_unmanage() function itself takes care of changing
focus outside of the window being unmanaged, so postpone the
MetaWindowDrag undoing to a point after that is done.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3073
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3376>
Since meta_kms_impl_device_get_sync_file always returns the same
file descriptor referencing the same sync_file, this means the atomic
ioctl doesn't need to wait for any fences to signal. This is fine
because we already waited for the buffer to become idle before applying
the Wayland surface state.
Fixes the atomic commit ioctl spuriously synchronizing to the screen
cast paint (at least with the amdgpu driver), which could result in
the page flip missing its target scanout cycle.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3148
v2:
* Rename local variable to signaled_sync_file for consistency with new
function name
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3389>
It returns a file descriptor which references a signaled sync_file.
v2:
* Change function name and add Doxygen comment to hopefully make its
purpose a bit clearer (Ivan Molodetskikh)
v3: (Jonas Ådahl)
* Create sync_file from scratch via a syncobj, no buffer needed anymore
* Initialize priv->sync_file = 1 and use g_clear_fd in finalize
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3389>
The debug controller can optionally, when passing --debug-control,
enable manipulating debug state, so far enabling/disabling HDR, via
D-Bus.
It's always created, in order to have a place to store debug state and
emit signals etc when it changes, but so far, it doesn't have its own
state it tracks, it just mirrors that of the monitor manager.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3432>
While we should ideally have a sensible cursor theme, handle the
case of cursor themes that lack certain cursor names, and fallback
to the 'default' cursor in those cases.
The 'grey rectangle' fallback is still left, in case we even fail
to load a 'default' cursor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3295>
When a stream is destroyed by a consumer, mutter won't be able to
recognize that.
For mutter, the stream just paused, but did not disconnect, because the
connection state of a PipeWire stream only represents, whether the
respective PipeWire context is connected to PipeWire.
In addition to that, it may be the case, that the stream consumer just
recreates the stream.
So even if mutter would be able to know, when the stream consumer
destroyed a stream, but not the whole screencast or remote-desktop
session, then mutter would not know, whether the stream will be resumed
eventually or not.
So, add an explicit API call to the screencast interface to stop a
stream.
For virtual streams, this also means, that the respective virtual
monitor is destroyed.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2889
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3307>
When a virtual stream is destroyed, its respective virtual monitor is
destroyed too. When the virtual monitor is destroyed, mutter reloads
the monitor manager.
However, at this point, the virtual stream is not completely destroyed
yet. The viewport of the virtual monitor still exists at this point and
when the monitor manager reloads, it will try to fetch the logical
monitor of the now destroyed virtual monitor, which will fail and thus
gnome-shell will run into a segfault.
Fix this situation by reloading the monitor manager in an idle callback.
When the monitor manager reloads, the virtual monitor is completely
gone, since the viewport of the virtual monitor is destroyed after the
virtual monitor itself.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2864
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3307>
There is no way to set any gamma luts, or do anything other color
management related. Eventually we'll probably want to, but that requires
bringing color management plumbing to PipeWire.
Doing this is also needed when running a headless session, as when
headless, polkit doesn't let us create colord devices without explicit
user permission, meaning we'll spam the session with useless dialogs
each time a session is started.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3423>
Given destruction order, the display goes away before the stage, so
this lingering signal connection may trigger unintended crashes.
Fixes: 05eeb684d1 ("window: Postpone focusing until grab ended if uninteractable")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3422>
`count_mode_setting_devices` was incorrect in both name and in function.
What it was actually doing was counting GPUs that had been registered with
the backend so far (during the `init_gpus` loop). What it was intended to
do was to count the number of `MetaRenderDeviceEglStream` instances, which
is the thing we're limited to only one of. So `count_mode_setting_devices`
would return zero whenever the first GPU initialized happened to be a
`MetaRenderDeviceEglStream`, which would in turn prevent
`MetaRenderDeviceEglStream` from successfully initializing. Seems it only
ever worked in the case of a hybrid system where the first GPU initialized
was GBM-based.
Now we count `MetaRenderDeviceEglStream` instances (zero or one) externally.
This allows initialization to succeed when it happens to be the first (or
only) GPU. And so `MUTTER_DEBUG_FORCE_EGL_STREAM=1` now works.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2905>
For scanout on a secondary GPU, for the time being try only formats
which are guaranteed to be renderable with GLES3, which notably excludes
10 bpc formats without alpha channel.
v2:
* Use separate format array for 10 bpc formats without alpha.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3139>
If the EGL_KHR_no_config_context extension is supported, use it to
choose a format per onscreen which is compatible with the scanout CRTC
and the GL rendering API used.
Suggested by Jonas Ådahl.
v2:
* Drop code which checked for GLES3 renderability. Makes no sense for
various reasons, in particular that EGLconfigs are about EGLSurfaces,
whereas secondary GPU contexts use an FBO for blitting.
* Use error parameter directly for meta_renderer_native_choose_gbm_format
call (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3139>
Preparation for the following commits, no functional change intended.
v2:
* Pass through MetaEgl pointer
v3:
* Make it return gboolean (Robert Mader)
v4:
* Add debug logging and corresponding purpose parameter
v5:
* Fix excessive function parameter indentation (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3139>
Split the struct into mutable and immutable parts. Access the mutable
parts via getters and the immutable parts via a single struct. This
avoids copying around the immutable parts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3280>
In profilers with a timeline or flame graph views it is a very common
scenario that a span name must be displayed in an area too short to fit
it. In this case, profilers may implement automatic shortening to show
the most important part of the span name in the available area. This
makes it easier to tell what's going on without having to zoom all the
way in.
The current trace span names in Mutter don't really follow any system
and cannot really be shortened automatically.
The Tracy profiler shortens with C++ in mind. Consider an example C++
name:
SomeNamespace::SomeClass::some_method(args)
The method name is the most important part, and the arguments with the
class name will be cut if necessary in the order of importance.
This logic makes sence for other languages too, like Rust. I can see it
being implemented in other profilers like Sysprof, since it's generally
useful.
Hence, this commit adjusts our trace names to look like C++ and arrange
the parts of the name in the respective order of importance.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3402>
Now that the monitor screencast records to DMA-BUF buffers immediately
(since bc2f1145d8), and we know which phase of the paint rountines we
are (since last commit), we have the opportunity to bring back the
blitting technique.
Bring back blitting. This time, instead of simply failing if the blit
fails, add a fallback path that does a stage paint if something goes
wrong. Unlike the previous implementation of blitting, this one only
blits the current view - it does not blit all views that intersect
with the screencasted monitor.
Embedded cursors should still be fine because hardware cursor is
inhibited while embedded cursor screencasts are running.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3406>
Track where we are in terms of the paint cycle. Do this through an
enumeration that is passed through the paint vfuncs of screencast
sources.
Right now, this information is not used by any one of the sources,
but next patch will use it to prevent blitting when detached from
the paint cycle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3406>
With the existing ClutterInputMode terminology (inherited from XI2),
hardware devices may be "physical" (i.e. attached to a logical device),
or "floating" (i.e. detached from all logical devices).
In the native backend, tablet devices are closer to "floating" than
"physical", since they do not emit events relative to the ClutterSeat
pointer logical device, nor drive the MetaCursorTracker sprite. This
is in contrast to X11 where all tablet devices drive the Virtual
Core Pointer by default, along with every other pointing device.
Change this mode in the Wayland backend to be more coherent. The
existing checks on the ClutterInputMode along Mutter seem appropriate
for handling these as floating devices, since they mainly care about
logical vs non-logical.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3393>
The window actor can be mapped every frame, e.g. when it is dragged in
the overview. This commit keeps track when the geometry changed and we
didn't managed to sync the geometry yet and need to sync it at a later
time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3404>
At the end of the sync_actor_geometry function the window buffer_rect
and the WindowActor position and size are the same and consistent.
Call the virtual method at the end and let the implementations look at
either the buffer_rect or the actor position/size itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3404>
In some cases the window is not mapped when the geometry changes.
Without the mapped window the surfaces are not mapped either and don't
have a sensible allocation.
This patch makes sure we abort syncing the geometry if the window is not
mapped and also make sure we sync geometry when the actor eventually
does get mapped.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3152
Fixes: 8f4ab53bd ("window-actor/wayland: Ensure to use allocation for black background check")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3401>
Scoped traces are less error prone, and they can still be ended
prematurely if needed (this commit makes that work). The only case this
doesn't support is starting a trace inside a scope but ending outside,
but this is pretty unusual, plus we have anchored traces for a limited
variation of that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3396>
Allow only specific files to use those deprecated APIs making
it easier to find where deprecated APIs are still in use
and avoid introducing new usages without being noticed
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3400>
Group all the three config files from clutter/cogl/meta into one
and also remove unnused configurations and replace duplicated ones
This also fixes Cogl usage of HAS_X11/HAS_XLIB to match the expected
build options
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3368>
