Right now we store touch serials on their according MetaWaylandTouchInfo
entries. These entries are gone as soon as the touchpoint ended though, and
it's not unlikely that clients will respond to that touch-end event after we
removed the touchpoint.
In this case we currently can't match the client provided serial to any of
our known touch sequences, which causes xdg_popup grabs that get requested
shortly after the touch-end to fail.
Let's be a bit more gentle on clients here and store the latest touch-down
serial on the MetaWaylandTouch, so that it continues to be around after the
touch-end and we can match the serial of the xdg_popup_grab() as expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2946>
In the rare event that hotplugs destroy and then create a new EGLContext
with the exactly the same ID, this ensures we will forget the old program
which presumably wouldn't work in the new context. It will be recreated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>
The EGL context can only import and blit an EGLImage if the
backing DMA buffer has a format modifier combination that is advertised
as supported and not marked as "external_only".
When the context can't blit the imported image, we can still paint using
it GL_OES_EGL_image_external using the texture target
GL_TEXTURE_EXTERNAL_OES.
However, treat drivers who doesn't support modifiers at all as if they
do support blitting, if the modifier is 'linear', to avoid regressions.
[jadahl: Make shader path a fallback to allow hardware to utilize copy
engines via blitting]
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6221
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2247
Related: https://launchpad.net/bugs/1970291
now only falls back if modifiers are supported, and they mark linear as
export only.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>
This is a critical part of any OpenGL program. Mesa allowed us to get
away without it and provided a sane default of the full buffer, but
Nvidia seems to default to an empty/zero viewport so would refuse to
paint any pixels.
In the OpenGL ES 2.0 spec this is ambiguous:
> In the initial state, w and h are set to the width and height,
> respectively, of the window into which the GL is to do its rendering.
because the first "window" used is EGL_NO_SURFACE in
init_secondary_gpu_data_gpu. It has no width or height.
In the OpenGL ES 3.0 spec the ambiguity is somewhat resolved:
> If the default framebuffer is bound but no default framebuffer is
> associated with the GL context (see chapter 4), then w and h are
> initially set to zero.
but not entirely resolved because neither spec says whether
EGL_NO_SURFACE should be treated as zero dimensions (Nvidia) or ignored
and not counted as the first "window" (Mesa).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>
As mentioned in the OES_EGL_image_external spec, there is no implicit
sync between the EGLImage producer and consumer. And in this code path
we don't have meta_drm_buffer_gbm_new_lock_front on the primary GPU to
do it for us either. So synchronization has to be done manually or else
the secondary GPU is likely to get an unfinished image.
This problem has only been observed when the secondary GPU is using the
Nvidia proprietary driver.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>
When the monitors change meta_window_update_for_monitors_changed is
called which is responsible for updating window->monitor. It however can
go through the entire window placement and constraint machinery before
it's able to do so. In this period window->monitor points to the old
MetaMonitor where the monitor number doesn't reflect the index into the
MonitorManager anymore.
Avoid relying on the window->monitor->number and go through the Monitor
directly.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3402
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3691>
In every other device and circumstance, we update the logical focus
(i.e. the surface that would be focused, if no other circumstances
applied) but let the MetaWaylandInput figure out the surface that
should be effectively focused, if at all. This is where we apply the
actual compositor state (e.g. grabs) and result in an effective focus
window.
The only exception to this is `meta_wayland_seat_set_input_focus()`
where the logical focus for keyboards and related devices is set, but
also applied as the effective surface.
We should do the same as everywhere else, and let MetaWaylandInput
focus determine whether the logical focus is also the effective focus.
These replaced set_focus() internal calls will happen through the
default MetaWaylandEventInterface.focus implementation in MetaWaylandSeat.
This resulted in keyboard focus being set on windows in circumstances
it ought not to, like in the overview. Actual key events were never
sent in these circumstances, but changes to modifier state could.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7528
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3704>
If a modal dialog (i.e. with a "revolves around center of parent window" policy)
becomes fullscreen, we cannot neatly honor both the modal dialog going fullscreen
and the window staying around the center of its parent.
In order to make fullscreening work in this situation, allow fullscreen modal
dialogs to "snap out" of the parent. This rule will become again effective after
the window is unfullscreened.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3425
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3695>
By ignoring obcured surfaces we can generalize the single-pixel-buffer
background check to work with arbitrary surface trees, as long as the
two top ones are the background and content surfaces.
As a nice side effect of this, clients like Firefox now usually take the
shorter `meta_window_is_fullscreen (window) && n_visible_surface_actors == 1`
route.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3699>
Move the code out of cogl_onscreen_egl_swap_buffers_with_damage, and
call the new function from callers of the former.
v2:
* Use early return if the cogl context doesn't support timestamp
queries. (Sebastian Wick)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3689>
`mtk_rectangle_new()` allocates the object dynamically,
but in the "contains-point" test case the allocated object
was not freed. Fix that by creating the object on the stack.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3679>
When the compositor inserts two waits in a frame, such as f606a4424a5afc,
the second insertion shouldn't break the ring's state machine as easily
as it does. We can instead merge the two GL waits into one by simply moving
the GL fence to the latest insertion. Each insertion still does its own X11
sync though.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3384
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3685>
Avoids using a static and make sure things are properly freed by
using g_autoptr. Also take the opportunity to add some missing NULL
initialization for auto-pointers variables
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3687>
In consistence with the code style, and in order to fix build errors
with older clang:
../src/backends/native/meta-onscreen-native.c:521:7: error: expected expression
521 | graphene_rect_t src_rect;
| ^
../src/backends/native/meta-onscreen-native.c:529:39: error: use of undeclared identifier 'src_rect'; did you mean 'dst_rect'?
529 | &src_rect);
| ^~~~~~~~
| dst_rect
../src/backends/native/meta-onscreen-native.c:522:20: note: 'dst_rect' declared here
522 | MtkRectangle dst_rect;
| ^
And warnings with newer clang:
../src/backends/native/meta-onscreen-native.c:521:7: warning: label followed by a declaration is a C23 extension [-Wc23-extensions]
521 | graphene_rect_t src_rect;
| ^
This should allow the build for coverity to succeed again.
Fixes: adc776d0d7 ("crtc/kms: Pass on src and dst rects to primary plane assignments")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3686>
This implements the explicit sync protocol linux-drm-syncobj-v1. This
works by importing a DRM syncobj timeline and importing/exporting fds
to/from the sync points on the timeline corresponding to buffer acquire
and release. We take fds for sync points provided during a surface
commit and use them to delay transaction application, and fetch fds
from Cogl to signal when we are done using a particular buffer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3300>
This adds the explicit sync wayland protocol to the list of build
dependencies.
This adds a copy of the linux-drm-syncobj protocol that we will use
privately for builds. This avoids the pain of requiring wayland-protocols
1.34 for distros. This commit can be reverted once we want to use
linux-drm-syncobj from the system wayland-protocols.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3300>
On big endian architectures the mapping of drm formats to cogl
formats is significantly trimmed compared to on little endian
architectures.
meta_wayland_init_shm tries a bunch of formats, including some
that just aren't mapped on e.g. s390x.
The code asserts the mapping will exist, however, leading to
crashes when Xwayland starts.
This commit makes failure to find a mapping non-fatal.
Suggested by Jonas Ådahl.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3672>
When logging in from gdm to gnome, the main plane is deactivated, and
leads to the screen going blank before gnome is able to enable it
again.
Using the new CloseFB ioctl, allows to keep the gdm login screen
displayed until gnome-shell replace it.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3659>
This also gets rid of the MetaFrameSyncMode enum and instead issues a
VRR update when the requested state differs from the CRTC state.
Fixes: fee33299 ("onscreen/native: Allow requesting frame synchronization")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3646>
This includes checking the vrr_capable property on the connector as well
as the VRR_ENABLE property on any CRTC the connector might get assigned
to. Also takes into account when a GPU is tagged for broken VRR support.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3646>
As we are getting close to have a Wayland-only build, guard those usages
so we don't 'regress'.
Once Kiosk figures it use case, we can revert both this commit and the
previous one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3652>
This reverts commit 917526ee9da8a1bdadda56ddfbc5050a34f45c4e.
As it is currently used by GNOME Kiosk, until upstream figures out
how to replace that code path, let us revert the commit
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3652>
When multiple configure requests sent to the wayland client within a sort period, maximized windows may end up in wrong position and cover struts. To avoid this, queue a resize when the resize event sent by the wayland client results a changed size or position to ensure that the final size and position will be always right.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3601>
Using `meta_wayland_single_pixel_buffer_from_buffer()` can fail if
the buffer resource is already gone. Given that we release the buffer
immediately, that is actually expected - but the client this was tested
with did/does not do so.
This made the single pixel black bar optimization fail for
GstWaylandsink, while working for the mpv Wayland backend.
Access the object directly, which is both faster and works as long as
the buffer is alive.
Fixes: ed50cbbfe4 (window-actor/wayland: Update scanout candidate check)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3662>
The gnome-shell magnifier listens to the `visibility-changed` signal
and calls meta_cursor_tracker_set_pointer_visible(false) when the
cursor became visible.
This leads to a reentrance in meta_cursor_tracker_set_pointer_visible()
and clutter_seat_uninhibit_unfocus() gets called twice, once from the
meta_cursor_tracker_set_pointer_visible(false) by the magnifier and then
the original meta_cursor_tracker_set_pointer_visible(true) continues,
after the first call has set is_showing to false again. This breaks the
inhibitor counting and the ability to use the cursor while using the
magnifier.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3661>
Near window destruction, there might be cases where the surface
actor does no longer have a surface, yet it's still in the stage
and eligible for picking. In that situation looking for modal
dialogs attached to this surface will evidently fail, so avoid
this check on a NULL surface.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3332
Fixes: 93a9e7f3f ("core: Move code ignoring events on windows with modals to Wayland")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3660>
Since commit e30eb788916d `ClutterFrameClock` assumes that a valid CPU time
implies timestamp query support, which is also checked in
`cogl_onscreen_egl_swap_buffers_with_damage()`.
Unconditionally setting the CPU time on direct scanout meant that the
compositing path would be stuck on the last (direct scanout optimized)
result on GL implementations without timestamp query support since.
be0aa2976e (clutter/frame-clock: Avoid rapidly toggling dynamic max render time)
Fix that by explicitly marking the gpu rendering duration as valid when
querying the GPU timestamps is supported and check for it ClutterFrameClock.
Fixes: 56580ea7c9 ("backends/native: Assume zero rendering time for direct scanout buffers")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3655>
