d991961ae changed this code from client rect to buffer rect to account
for the fact that for SSD windows the decorations are now included in
the bounding region, but it kept the variable name as client_area and
the comment was also still referring to the client rect.
Fixes: d991961ae ("x11: Use input region from frame window for decorated windows")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3697>
When updating the input region we check whether the input shape reported
by XShape matches the bounding region of a window to determine when it
was not set by the client. We would then use a NULL input region instead
which always matches the full size of the window. The code however was
using the client rect for this comparison, which does not include the
window frame. Since d991961a the frame is considered part of the input
region.
This meant that for SSD windows where the input region would match the
bounding region, we would not detect that and fail to set the input
region to NULL, but instead set it to the reported input shape.
Usually this would not be the case due to the GTK frame window having
shadows and a resize region, but in the presence of an issue that causes
GTK to wrongly detect _GTK_FRAME_EXTENTS as not supported, GTK would not
draw shadows or set an input shape. And due to GTK not updating its
input shape, there would be no further calls to
meta_window_x11_update_input_region() after the initial one.
The input region would therefore remain at the fixed size from the
initial call. This was causing windows to become click-through outside
of the region corresponding to their initial size after being resized.
Fixes: d991961ae ("x11: Use input region from frame window for decorated windows")
Related: https://gitlab.gnome.org/GNOME/gtk/-/issues/6558
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3404
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3697>
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>
