local_error in meta_egl_query_device_string() is using g_autoptr,
meaning that it was getting freed after g_propagate_error(). This then
would result in error->message becoming invalid, causing crashes when
logging the error message later on.
Fixes: 8234f5bc7 ("egl: Return success status from meta_egl_query_device_string")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3758>
Because `meta_kms_impl_device_simple_initable_init` is called in the
middle of `meta_kms_device_new`, the crtcs list for `MetaKmsDevice`
has not been populated yet. And thus the loop to detect missing
cursor planes and create fake ones never iterated. But the crtcs list
does already exist in `MetaKmsImplDevice` so iterate over that instead.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3264
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3676>
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>
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>
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>
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>
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>
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>
Some clients - notably the Gstreamer vapostproc element when using Intel
GPUs - only support BGRA, not BGRx. We already assume that we can
support this format for window screen casts, and even in case of failure
we now have a re-negotiation fallback in place. Thus it's pretty safe to
support it for all screen cast types.
The possible duplication in case of window screen casts doesn't seem to
be a problem for either Pipewire or existing clients like OBS.
Note that the implementation lays the foundation to make it easy to add
more formats in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3617>
For each libinput scroll event we generate two clutter events
(continuous and discrete), one of them marked as emulated. libei
explicitly specifies that emulation of scrolling must be done in the
client (if desired) so drop the emulated one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3637>
This is used as the minimum refresh rate in the variable refresh rate
range.
This value is expected to be found in the DisplayPort and eDP EDID of
every monitor that supports variable refresh rate.
It is also found in the HDMI EDID of some monitors that support
variable (FreeSync), but most likely not all of them. The rest require
parsing the AMD vendor extension which libdisplay-info doesn't
support.
No fallback is implemented for cases where libdisplay-info support is
disabled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3576>
Frame synchronization is enabled for a view as long as it's
applicable to be enabled. It is considered applicable if it's both
requested for the onscreen and if the onscreen uses a CRTC which is
configured with a variable refresh rate mode.
When frame synchronization is enabled, it enables both the the variable
scheduling mode of ClutterFrameClock and the variable refresh rate
property for the CRTC.
Changes in the frame synchronization mode are applied asynchronously,
before the next frame is drawn.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154>
