In order to get the delta X/Y value of the
LIBINPUT_EVENT_POINTER_SCROLL_FINGER
or LIBINPUT_EVENT_POINTER_SCROLL_CONTINUOUS events the new function
libinput_event_pointer_get_scroll_value should be used instead of
libinput_event_pointer_get_axis_value.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1962>
Ignore deprecated LIBINPUT_EVENT_POINTER_AXIS events and handle
LIBINPUT_EVENT_POINTER_SCROLL_WHEEL,
LIBINPUT_EVENT_POINTER_SCROLL_FINGER and
LIBINPUT_EVENT_POINTER_SCROLL_CONTINUOUS instead.
The scroll source is now encoded in the event type making
libinput_event_pointer_get_axis_source and translate_scroll_source
redundant.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1962>
When building the list of formats to be sent as part of the scanout
tranche, avoid requiring modifier support by the DRM driver for
formats relying on implicit modifiers (DRM_FORMAT_MOD_INVALID).
Specifically, the previous check required the DRM driver to have
advertised some modifier support for the given format in its
IN_FORMATS KMS plane property, regardless of modifier it was. If it
hadn't, the format was left out of the list of formats to be sent
in the scanout tranche.
When no formats remained to be sent in the scanout tranche, the
tranche simply wasn't sent.
This resulted in the scanout tranche never being sent for GPUs where
modifiers aren't supported. In those cases, no formats are advertised
using the IN_FORMATS property, and thus the list of formats to be sent
in the scanout tranche remained empty.
Since Mesa doesn't use scanout-compatible buffers for native Wayland
clients unless specifically requested to do so using the "scanout"
tranche flag, it effectively means that direct scanout of native
Wayland clients wasn't supported for GPUs without modifiers support.
Sending a tranche with formats paired with the implicit modifier
(DRM_FORMAT_MOD_INVALID) is both allowed by the protocol and is
already done by default for GPUs with modifiers support, unless the
experimental support for explicit modifiers is enabled in Mutter.
So instead of requiring modifiers to be supported for each format
being evaluated for the scanout tranche, when processing formats
which rely on implicit modifiers, only check if the format in
question is supported by the DRM driver for scanout on the primary
plane.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2510>
While the check for `clutter_actor_has_mapped_clones` clearly indicates
an intention to take clones into account, the following code
does not do so, likely because it predates the introduction of
`clutter_actor_is_effectively_on_stage_view()`.
Switch to that newer API in order to take clones into account. This
avoids unnecessary `wl_surface_send_enter()` and `wl_surface_send_leave()`
events when entering the overview, reducing client work.
This also avoids unnecessarily allocating a `cairo_region_t`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2502>
`clutter_actor_set_child_at_index()` is far from a no-op, even if
the current index is equal to the new one - presumably for good
reasons. For the use-case here we want it to be a no-op though, so
skip calling it if the index already matches.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2501>
Unparenting the surface actor when the subsurface object is destroyed
has several issues:
- subsurface actors can be unparented while a close animation is
still ongoing, breaking the animation for e.g. Firefox.
- adding and removing the actor to/from the parent is not handled in
one place, making the code harder to follow.
- if the destroyed subsurface had children of its own, they potentially
stick around until a surface-tree rebuild. This makes the Firefox
hamburger menu not close with the "compositor" backend.
Move the unparenting back to
`meta_window_actor_wayland_rebuild_surface_tree()` and instead just
notify the parent of a state change, if it still exist. This will ensure
a correct mapping between the subsurface node tree and the flat surface
actor list. In case of the closing animation the parent will already be
removed and the call is skipped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2501>
Since b443bd42ac, we unmanage a wayland window when clearing its
transient parent. That's to make sure that xdg-foreign doesn't
leave the dialog around after the imported surface was destroyed.
While that behavior is sound, it is problematic to implement it
by unmanaging the window, as that happens entirely behind the
client's back.
Instead, send a close event for the window. Unless the client has
good reasons, it should honor the request. (And if it has good
reasons - like unsaved work - then effectively hiding the window
from both the user and client is probably not the best idea anyway).
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5458
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2499>
Not all windows can be minimized: X11 clients can disable the
functionality, and so do we for windows that aren't shown in
the alt-tab popup or the shell overview, so there would be no
way of getting them back.
While we make sure that we respect that ourselves (keybinding,
window menu, etc.), we don't guard meta_window_minimize(), so
clients or extensions can still minimize a window that isn't
supposed to be minimized.
That can lead to all kinds of issues, from the hidden window
being lost (as far as users are concerned) to a crash when
the minimzed window has a transient parent.
Just add an explicit check to make sure the unexpected doesn't
happen after all, and print a warning if it does.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2491>
The cursor rendering code path used by the screen cast code relies on
the cursor tracker machinery to determine where to blit the cursor
texture, but at the moment the cursor position invalidation is behind
a check for whether the shell is using a Wayland backend. (This code
path used to be Wayland-specific before 00cbcb7ba1 but has been
backend-agnostic since).
This commit removes the check for a Wayland compositor, allowing
cursor drawing to function correctly on X11 when screen casting in
embedded cursor mode.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1780
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2474>
The test case checks that the stage views of hidden actors are
not updated when the views of the visible outer parent change.
The check for the outer parent's updated stage views currently
relies on ClutterFixedLayout not excluding hidden children in
its size request: As the container doesn't contain any visible
children at that point, its size would change to 0x0 and end
up on no stage view (rather than the assumed two).
Avoid that oddity by giving the outer container a fixed size,
so that the visibility of its child doesn't affect the test
when we fix ClutterFixedLayout.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2488>
This adds support for E-EDID extensions. Tags are allocated by VESA and
the CTA has such an extension defined in CTA-861.
The switch in `decode_ext_cta` is empty in this commit because we don't
parse any CTA-861 data blocks, yet.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2351>
The EDID code is copy from elsewhere, without adapting to conventions
regarding e.g. API and types. Clean this up a bit, as EDID information
will be kept around longer when possible, to be used e.g. by color
management.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2351>
The test aims to test that trying to fetch X11 clipboard content after
Xwayland went away doesn't cause issues. What happens though is that
sometimes the clipboard content doesn't have time to settle (i.e. fetch
mime types etc) before Xwayland gets terminated, which causes flakyness.
Fix this by waiting for the compositor side clipboard owners to finish
setting up before continuing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2484>
The pixel clock determines how fast pixels can be processed. When adding
non-native common modes, avoid adding modes that exceed the max pixel
clock frequency of the native modes. Avoiding these avoids potential
mode setting failures where the GPU can't handle the modeline since the
configured pixel clock is too fast. This replaces the "bandwidth" check
which used the number of pixels and refresh rate, which wasn't enough to
avoid incompatible modes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2492>
'screen-cast/monitor-src: Use clutter_stage_paint_to_buffer'
(6c818cd8d5) made the non-dma-buf path use
clutter_stage_paint_to_buffer() to avoid running into direct scanout
issues. At a glance, the dma-buf paths didn't have the same issue since
it explicitly handled dma-bufs by blitting them.
What it also did was move the recording to an idle callback, to avoid
paint reentry issues. A side effect of this, however, is that it also
broke the dma-buf paths, as they rely on the back buffer existing, and
the stage view direct scanout already being setup, which it isn't in an
idle callback.
Fix this by using the dma-buf variant of
clutter_stage_paint_to_buffer(): clutter_stage_paint_to_framebuffer().
This has some negative performance impact, but we can't use
cogl_blit_framebuffer() when using an idle callback for recording.
Potential performance improvements to make things work more as they did
before is to enhance 'cogl_blit_framebuffer()' a bit, making it a vfunc
that could be implemented by MetaOnscreenNative. A flag to say whether
to look at the back or front buffer would let MetaOnscreenNative know
whether to use the already committed-to-KMS buffer, or the current back
buffer.
Fixes: 6c818cd8d5
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2282
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2462>
Fixes leak:
==14889== 2,168 (16 direct, 2,152 indirect) bytes in 1 blocks are definitely lost in loss record 15,308 of 15,584
==14889== at 0x48445EF: calloc (vg_replace_malloc.c:1328)
==14889== by 0x4BAC1D0: g_malloc0 (gmem.c:155)
==14889== by 0x4AAFF60: meta_wayland_dma_buf_feedback_new (meta-wayland-dma-buf.c:298)
==14889== by 0x4AAFFE0: meta_wayland_dma_buf_feedback_copy (meta-wayland-dma-buf.c:317)
==14889== by 0x4AB16B6: ensure_surface_feedback (meta-wayland-dma-buf.c:1121)
==14889== by 0x4AB1848: dma_buf_handle_get_surface_feedback (meta-wayland-dma-buf.c:1169)
==14889== by 0x66F77E9: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==14889== by 0x66F6922: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==14889== by 0x5318750: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-server.so.0.20.0)
==14889== by 0x5313B99: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-server.so.0.20.0)
==14889== by 0x5316649: wl_event_loop_dispatch (in /usr/lib/x86_64-linux-gnu/libwayland-server.so.0.20.0)
==14889== by 0x4AA7C19: wayland_event_source_dispatch (meta-wayland.c:110)
Fixes: 64e6bedb6b ("wayland/dma-buf: Add support for scanout surface feedback")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2469>
The MetaKeyboardA11yFlags are used by gnome-shell to show a dialog
whenever a keyboard accessibility feature is switched using the
keyboard.
Unfortunately, commit c3acaeb25 renamed the Clutter flag to Meta and
moved them to a private header. As a result, gnome-shell do not show any
dialog anymore when a keyboard accessibility feature is activated.
Move the MetaKeyboardA11yFlags definition to a public header so that
gnome-shell can use it.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2306
Fixes: c3acaeb25 - backends: Move keyboard a11y into backends
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2463>
The min distance to the right/bottom edge depends on Wayland concepts
(wl_fixed_t) and eventually geometry scale. Move the logic the Wayland
side of the pointer constraints machinery to avoid the backend trying to
figure this out without the proper data.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2460>
There were some coordinate nudging to avoid running into Clutter
floating point math issues related to coordinate transformations. Over
the years these things have improved, especially with the move to
graphene, so remove the old work around.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2460>
The ImplDeviceAtomic converts the MetaKmsPlaneRotation back to the
concrete KMS value. The MetaMonitorTransform is always directly
converted to a MetaKmsPlaneRotation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2379>
Updating the PropTable has the side effect that the parse callback now
also gets called on hotplug but it is used to initialize data. The parse
callbacks are moved to the read_state functions which are aware if this
is an initializing call or just an update.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2379>
* creating an actor will result in it being assigned a color state
with the color space sRGB
* creating an actor with a color state passed will result in that
color state being returned
* changing an actor's color state makes that happen
* changing an actor's color state to NULL ends up with it being
changed back to a color state with the sRGB color space
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2443>
This avoids the following error:
../src/tests/wayland-test-clients/dma-buf-scanout.c💯5: error:
implicit declaration of function ‘close’; did you mean ‘pclose’?
[-Werror=implicit-function-declaration]
100 | close (buffer->dmabuf_fds[i]);
| ^~~~~
| pclose
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2458>
The Cogl feature was removed a while back, while Clutter just hard coded
it to TRUE. Lets remove the confusion that GLSL isn't supported and just
remove the (dead) fallback paths.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2015>
Add `sync_effects_completed()` and `verify_view()` in
order to allow Wayland test clients to trigger verifications
and add convenience functions to use them to client-utils.
Notes:
- `sync_effects_completed()` works in two stages in order
to ensure it doesn't race with window effects. By the time
`sync_effects_completed()` is processed, an effect could
already have ended or not yet been scheduled. Thus we
defer a check for pending effects to the next paint cycle,
assuming that by then they should have been scheduled.
- `meta_ref_test_verify_view()` internally triggers the
`paint` signal for the stage which is why it can not be run
in the after-paint signal handler.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1055>
Version 2 is required for buffer transform, however directly going
for the highest currently supported version doesn't break any
tests and makes more features available.
Also fix indentation below while on it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1055>
Our internal interpretation of output transforms is not in line with
the Wayland spec. Wayland describes them as the transform that a
compositor will apply to a surface to compensate for the rotation
or mirroring of an output device - counter-clockwise.
Mutter in turn interprets it the other way around. One could
argue it does the same but clock-wise - or it interprets the transform
from the viewpoint of the content, not the device.
In either way, the difference is that 90 and 270 degree values are
switched. Thus swap these accordingly when we translate from
`WL_OUTPUT_TRANSFORM` to `META_MONITOR_TRANSFORM`.
See: https://gitlab.freedesktop.org/wayland/weston/issues/99
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1055>
This launches Xvfb, using xvfb-run, and inside tests the following:
1. Launching 'mutter --x11' works
2. Launching a couple of X11 clients works (doesn't crash or result in
warnings)
3. Launching 'mutter --x11 --replace' works
4. Terminating works
It does this using a simple shell script.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2434>
We don't make use of the refresh rate in any useful way in the X11, and
in this case we just ended up with warnings since the refresh rate was
NaN. Fix this by making it 0.0 to mean "no refresh rate". This also is
what 'xrandr' itself reports.
Fixes warnings when launching 'mutter --x11' in Xvfb.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2434>
This adds a minimalistic fullscreen direct scanout test case, that runs
on vkms. It doesn't use EGL, and it uses uninitialized memory, thus it
lacks any kind of implicit synchronization, but it does test that the
scanout selection paths are working.
What is tested is:
* DMA buffer allocated using gbm on top of VKMS
* Buffer passes a mode setting TEST_ONLY check
* Paint is omitted
* Correct buffer active in KMS after presentation
What isn't yet tested:
* Implicit synchronization related behavior
* Presented pixel content
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2417>
We passed the pointer to a GError * as user data on an async I/O call.
The callback function didn't make use of it, so it was never written to,
thus remained NULL, thus was dead code. Remove it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2446>
It works by using an X11 client to set the clipboard content, using a
mimetype that on purpose is not handled by the clipboard manager. The
test then makes sure we don't crash when trying to transfer data from
the old X11 selection source.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2364>
The Xwayland server can go away at any time; when this happen we might
have a test client running, and for it to tear down more nicely, make
sure to avoid trying to clean up X11 resources on the old X11 display.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2364>
Xwayland can disappear at any time, for example during a new_async() or
read_async() call. When we eventually finalize the stream, the X11
display it was created for is gone, thus can't clean up the X11
resources. Handle this by making the MetaX11Display pointer a weak
pointer, and ignore cleaning up if it disappeared. This is fine since
the X11 server it created those resources one is gone already.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2364>
The property doesn't necessarily exist when using drivers that doesn't
support atomic mode setting, and the way it worked will break night
light and other gamma related features. This makes things use the gamma
length; if it is higher than 0, it definitely supports it one way or the
other, i.e. GAMMA_LUT with the atomic backend, and drmModeCrtcSetGamma()
with the legacy/simple backend.
Fixes: 364572b95c
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2287
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2435>
It doesn't depend on whether the CRTC is active or not, so always read
it. This is also useful to know whether a CRTC supports gamma, before it
is being turned on, without relying on the existance of properties.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2435>
The COMPOSITOR_GRAB event route has effectively been replaced by
ClutterGrabs, which are no longer covered by the existing check.
So check for grabs as well to restore the old behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436>
The event-route is never set to COMPOSITOR_GRAB nowadays, so the
condition will never be met.
Furthermore, it is expected that ClutterGrabs only happen when
events are routed normally, so the remaining NORMAL check should
already fully cover the old COMPOSITOR_GRAB case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436>
We already bypass wayland if there is a ClutterGrab, so the case
that used to be covered by the event-route check is already handled,
and we can just remove the obsolete check.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436>
Since the new ClutterGrab API replaced the old plugin-modal hook,
the event-route is never set to COMPOSITOR_GRAB.
The code in question already checks whether the stage has a grab,
so we can just remove old checks.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436>
Initializing the event mask, SubstructureRedirectMask in particular,
before taking the manager selection fails with BadAccess. Fix this by
initializing said mask after taking the manager selection.
This fixes `--replace`.
Fixes: eb4307c350
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2432>
The code is already trying to avoid creating new laters when there
already is one for the queue type, but this wasn't working because the
ID of the later was never stored after creating a new one. This would
then result in as many laters as meta_display_queue_window() was called
and all of them would run the handler function, even if only the first
one had a non-empty window queue.
Similarly this was causing the later to not be removed if the window
queue got empty after meta_display_unqueue_window().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2414>
Currently the signal is getting emitted accidentally, because even when
removing a window from the queue, the later handler of that queue will
still get run due to a bug. This bug is going to get fixed in the next
commit, but some things might depend on the signal getting emitted when
the visibility of a window has changed.
This change affects the behavior in two ways. First the signal is now
emitted immediately rather than from an idle. And second it now
correctly includes the window in the should_show or should_hide list.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2414>
The compositor currently only updates the topmost window actor that is
visible to it after stacking changes. The visibility of a window actor
to the compositor however might only change via the display idle queue
after the stacking changes. This could then lead to the topmost window
actor being assumed to be NULL on Wayland after switching from an empty
workspace or when opening the first window on an empty workspace. The
result of this is direct scanout being disabled in these cases.
To fix this also trigger the update when the visibility of windows
changes.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2269
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2413>
Some windows span the entire screen but still use transparency, such as
the desktop window of Nemo. When these windows were used for direct
scanout, the transparent areas would turn black and nothing else would
be rendered.
In addition to checking the surface for opaqueness, for X11 windows also
the window actor itself has to be checked, because its opacity might
have been changed via _NET_WM_WINDOW_OPACITY.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2263
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2409>
This replaces the API to get the topmost surface actor with an API to
get the surface actor that could be a candidate for direct scanout. The
advantage of this is that it allows X11 and Wayland specific
restrictions for these actors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2409>
It's not allowed to call eglQueryWaylandBuffer() if the call to
eglBindWaylandDisplay() failed, and will result in an assert being hit
in mesa if called.
Avoid that by keeping track whether we succeeded to bind, and only
attempt to realize a legacy EGL wl_buffer if binding succeeded.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2415>
Mutter makes use of a gsettings scheme that comes from
gnome-settings-daemon to check for the screen orientation.
In use cases where gnome-settings-daemon is not available,
this would lead to a crash as the key doesn't exists
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2398>
The monitors settings such as the privacy screen property is propagated
to the monitors via kms updates, however during initialization and
on monitors changes, we end up clearing the pending KMS updates because
such settings are added to the queue before the backend has fully
initialized the monitors, and this may lead to discarding all the
pending updates, including the one we've just planned.
To avoid this, move settings applications after we've both initialized
the backend and notified it about changes.
Also avoid to try set the settings during actual initialization, but
delay that after post-init.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2372>
Prior to 'compositor: Destroy actors when unmanaging', window actors
were destroyed when the compositor object was destroyed, long after the
windows were unmanaged, however, when this instead changed to happen
when unmanaging, with the original goal to avoid having these actors try
to interact with the disposed MetaCompositor instance, it caused an
issue where window actors would be indirectly destroyed as a side effect
of their parents being destroyed, which caused some fallout in the logic
handling window-close animation tracking, which relies on
meta_window_actor_queue_destroy() being called before a window actor is
actually destroyed.
Fix this by unmanaging windows before unmanaging the compositor.
From an X11 point of view, this should be harmless, since all it really
do is call XCompositeUnredirectSubwindows().
For the native backend and the common behavior, all unmanaging the
compositor instance does is destroy clutter actors, so doing so after
window actors were already cleaned up should not be a problem, as this
was the case before too.
Fixes: 35ac3a096d
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5330
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2403>
Quoting Ray Strode:
we don't expose a way to explicitly save the session in gnome anymore
afaik, and I don't think it's going to show on log out because
I believe we use the FORCE flag from the log out dialog.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2370>
'kms/impl-device/simple: Get the buffer handle from MetaDrmBuffer'
changed how fb ids are generated, but it only made it fully work with
atomic mode setting. For legacy/simple mode setting, it only handled the
primary plane buffer, not the hardware cursor.
Fix this by making sure the fb id is generated also in the legacy mode
setting case.
Fixes: ea39142da2
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2250
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2397>
When an X11 window becomes an all-workspace window its `workspace` is
set to NULL before `meta_window_x11_current_workspace_changed()` is
called. The latter then checks for `workspace` being NULL (which also
happens when unmanaging) and then returns early. So this does not update
`_NET_WM_DESKTOP` to 0xFFFFFFFF. Instead it remains at the workspace the
window was on before. This was causing programs like `wmctrl` to switch
to this old workspace when activating such a window.
Fix this by checking if the window is unmanaging instead.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2242
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2387>
Simply signal preedit string changes from/to NULL once, in order
to avoid unwanted activity in the client side. We do still need to
send the preedit once each .done event, if there is one, in order
to behave according to the protocol when it matters the most.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2395>
With the unthrottled input emission, we ended up often getting the
cursor updates long before any damage had been posted, meaning that if
you moved around the mouse pointer where the mouse had a high enough
refresh rate, we'd effectively stall the screen cast stream by only
sending cursor updates and nothing else.
Fix this by scheduling an update when we get a cursor update, then
sending a cursor-only frame after any damage and relayout has been
processed, but only if there is no queued damage that will cause an
actual repaint.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2393>
This handle is used by the legacy KMS API; lets avoid having to have GBM
specific code where this is done by letting the MetaDrmBuffer API, that
already has this information, expose it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2275>
We'd put the message in a variable called `message`. If something passed
to meta_topic() was called `message`, it'd end up being `NULL` in the
log entry. Avoid this by making the local message variable a bit more
"on topic".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2391>
Unfortunately we cannot do this generically since the target of the
button/touch press does matter, e.g. tapping on the OSK, or clicking
the IBus candidates window. These situations should not trigger a
reset.
So be more selective about the situations where button/touch presses
trigger an IM reset, in the case of ClutterText these are still clicks
inside the actor, for Wayland's text-input it is when clicking the
surface that has text_input focus.
For all other situations where clicking anywhere else might make
sense to trigger an IM reset are covered by the focus changing paths,
that also ensure a reset before changing focus between surfaces/actors.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1961
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
Focus changes should trigger an IM reset, as some engines do want
to maybe commit the preedit string before changing focus. In addition,
we do not want the preedit string to be able to move between
windows/applications.
Ensure that the commit string is committed when the IM deems so, and
ensure we send a .done event disntinct to the .leave event, so that
the client doesn't miss the commit.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2030
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
DMA buffers might be allocatable, but it doesn't mean the driver doesn't
fail when we try to allocate a buffer with an implicit modifier. Using
the proprietary NVIDIA driver for example, it will fail. Lets catch this
up front and avoid advertising DMA buffer support when we know it won't
work.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2383>
As of currently, we only emit .done() on actual changes coming from the
ClutterInputMethod/ClutterInputFocus. With the recent changes in the
interpretation of serials, it becomes more important now that the
compositor acknowledges every .commit done by the client, in order to
keep them feeding future IM state updates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2365>
Compensate the protocol statelessness with our ClutterInputFocus
statefulness. This becomes more necessary now, since sending
consecutive .done() events is now considered acceptable behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2365>
MetaCursorRendererNative only updates the cursor state when the
underlying texture changes. The cursor scale and transform do not
trigger updates. This results in wrong cursor orientations on rotated
displays. Use both texture changes and scale and transformation changes
to figure out when to update the cursor state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2363>
When switching between the existence and not of a stage ClutterGrab, we
would correctly attempt to synchronize key focus from the perspective of
the Wayland clients.
But this synchronization should do its own checks about existing stage
grabs before determining a client window has key focus or not.
Add that check, so that grabs correctly unfocus the keyboard in Wayland
clients, in addition to pointers and touch.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2194
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2366>
