The GBM device needs to be destroyed after the EGL display.
==50931==ERROR: AddressSanitizer: SEGV on unknown address 0x7fe40a000049 (pc 0x7fe446121d30 bp 0x60400001bbd0 sp 0x7ffc99c774d0 T0)
==50931==The signal is caused by a READ memory access.
#0 0x7fe446121d30 (/usr/lib/dri/radeonsi_dri.so+0x5f0d30)
#1 0x7fe4474717bd (/usr/lib/../lib/libEGL_mesa.so.0+0x177bd)
#2 0x7fe4474677d9 (/usr/lib/../lib/libEGL_mesa.so.0+0xd7d9)
#3 0x7fe44cca7b6f in wlr_egl_destroy ../subprojects/wlroots/render/egl.c:379
#4 0x7fe44ccc2626 in gles2_destroy ../subprojects/wlroots/render/gles2/renderer.c:705
#5 0x7fe44ccb5041 in wlr_renderer_destroy ../subprojects/wlroots/render/wlr_renderer.c:37
#6 0x7fe44cd17850 in backend_destroy ../subprojects/wlroots/backend/wayland/backend.c:296
#7 0x7fe44ccca4de in wlr_backend_destroy ../subprojects/wlroots/backend/backend.c:48
#8 0x7fe44cd11b21 in multi_backend_destroy ../subprojects/wlroots/backend/multi/backend.c:58
#9 0x7fe44cd125b0 in handle_display_destroy ../subprojects/wlroots/backend/multi/backend.c:125
#10 0x7fe44c315e0e (/usr/lib/libwayland-server.so.0+0x8e0e)
#11 0x7fe44c3165a6 in wl_display_destroy (/usr/lib/libwayland-server.so.0+0x95a6)
#12 0x55a2c8870683 in server_fini ../sway/server.c:203
#13 0x55a2c886cbf2 in main ../sway/main.c:436
#14 0x7fe44b77c151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)
#15 0x55a2c883172d in _start (/home/simon/src/sway/build/sway/sway+0x33472d)
Instead of requiring callers to manually make the EGL context current
before binding a buffer and unsetting it after unbinding a buffer, do
it inside wlr_renderer_bind_buffer.
This hides renderer-specific implementation details inside the
wlr_renderer interface. Non-GLES2 renderers may not use EGL.
This removes all EGL dependencies from the backends.
References: https://github.com/swaywm/wlroots/issues/2618
References: https://github.com/swaywm/wlroots/pull/2615#issuecomment-756687006
It can be surprising and unexpected that texture operations (such as
texture upload and import) change the current EGL context, especially
when it's done under-the-hood by wlroots in response to wl_surface
requests.
To prevent surprises, save and restore the previous EGL context.
It can be surprising that destroying a buffer changes the EGL context,
especially since this can be triggered from anywhere wlr_buffer_unlock
is called.
Prevent this from happening by saving and restoring the EGL context.
Value is now an enum with a new value ("on-demand") that compositors can use to allow "normal" keyboard focus semantics regardless of the layer the client surface is on. An error is sent for invalid keyboard interactivity values. The old behavior is retained for clients using the previous version of the protocol.
Also adjusted the layer-shell example program to use the new keyboard interactivity options.
Since 5b1b43c68c ("backend/drm: make wlr_drm_plane.{pending,queued,current}_fb
pointers"), current_fb can be NULL if there's no buffer. If current_fb
is not NULL, current_fb->wlr_buf is guaranteed to not be NULL.
Closes: https://github.com/swaywm/wlroots/issues/2634
This function is inferior to wlr_xdg_surface_for_each_popup_surface()
for rendering as it does not iterate over subsurfaces. Furthermore,
no compositor is known to use this to iterate popups for any purpose
other than rendering. Therefore remove the function, which may of course
be reintroduced at a later date if a use-case is found.
Instead of relying on output.pending.committed, use
wlr_output_event_commit to find out whether a buffer was committed.
Eventually output.pending will be cleared before the commit event is
emitted.
References: https://github.com/swaywm/wlroots/issues/2098
This is Mesa's legacy wl_drm protocol. It will eventually get replaced
with linux-dmabuf, however right now it's the only way to get the DRM
device used by the parent compositor.
Stop using wlr_drm_surface.{width,height} to figure out the size of a
gbm_bo. In the future we'll stop using wlr_drm_plane.surf, so these will
be zero. Instead, rely on gbm_bo_get_{width,height}.
Stop keeping track of buffers on the parent GPU when multi-GPU is used.
This removes support for export_dmabuf on secondary GPUs, but renderer
v6 will bring this back by managing the swapchains in wlr_output instead
of the backends.
Simon Ser
Simon Zeni
Daniel Kondor
Isaac Freund