X11 clients expect a ConfigureNotify after a ConfigureRequest. If
the compositor/window manager chooses not to honor the request
(e.g. due to the window being maximized), XWayland will not send a
"real" ConfigureNotify event and the window manager is expected to
send a synthetic event instead. Otherwise, the X11 client is left
waiting and may not repaint its window properly.
For comparison, see Openbox's client_configure() or Weston's
weston_wm_window_send_configure_notify().
v2: Move logic to wlr_xwayland_surface_configure()
This is based on previous work [1] [2].
This new API allows compositors to display buffers without needing to
perform rendering operations. This API can be implemented on Wayland
using subsurfaces and on DRM using KMS planes.
Compared to [1], this approach leverages wlr_addon_set to let backends
attach their own private state to layers, removes the pending
state (necessary for interop with wlr_output_commit_state()) and
enum wlr_output_layer_state_field.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/1985
[2]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3447
Reverts commit c73e20628a.
This caused a regression in the GLES2 renderer because `egl->exts.EXT_device_drm` is set in
`egl_init_display()`, which is invoked after `get_egl_device_from_drm_fd()`. So the function will
always return `EGL_NO_DEVICE_EXT`.
This is needed for compositors that want to reserve space for
XWayland panels. Such a feature can be useful in a "transitional"
setup, where only the X11 window manager and compositor is replaced
but other components of an X11 desktop environment are still used.
This change simply reads the X11 property; the compositor is free
to ignore it. Thus, compositors that don't want to support such a
"transitional" feature are not impacted.
v2: Update xwayland_surface_associate()
The #sway-devel channel is now for Sway development only. #wlroots
is the new channel to use for wlroots.
We were using #sway-devel mostly for histerical raisins. Nowadays
many wlroots developers are not working on Sway.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3586
options->scanout_primary_output indicates an output on which scanout is desirable.
Set the missing SCANOUT flag.
Fixes: 0c966f102c ("linux-dmabuf-v1: add wlr_linux_dmabuf_feedback_v1_init_with_options()")
This patch allows surfaces without keyboard focus
but with pointer focus to receive valid tokens.
This can be relevant for applications using an older version of
the layershell protocol which only provided the choice between
no keyboard focus and exclusive keyboard focus.
Instead of destroying all seats, destroy a single one. We only need
to destroy all seats at one call-site (backend_destroy), but we'll
need to destroy a single seat elsewhere in the next commit.
The hardcoded fallback "/usr/share/hwdata/pnp.ids" was only a
temporary solution to get things working while distributions were
still working on shipping it.
During a modeset, the core wlr_output logic will allocate a buffer
with a new size and commit it. However if we still have a frame
callback pending we'd refuse to perform the commit. This is
inconsistent with the DRM backend, which performs a blocking
modeset.
This is visible when resizing the Wayland toplevel. The logs are
filled with "Skipping buffer swap", and the wlr_damage_ring's
bounds are not properly updated.
Fix this by destroying the pending frame wl_callback.
In output_ensure_buffer() we create a swapchain and attach an empty
buffer to the output if necessary. We do that during the first commit.
This is fine when the first commit enables the output, however this breaks
when the first commit disables the output. A commit which disables an
output and has a buffer attached is invalid (see output_basic_test()), and
makes the DRM backend crash:
00:00:00.780 [wlr] [backend/drm/drm.c:622] connector eDP-1: Turning off
../subprojects/wlroots/backend/drm/drm.c:652:44: runtime error: member access within null pointer of type 'struct wlr_drm_crtc'
AddressSanitizer:DEADLYSIGNAL
=================================================================
==2524==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f22e894afc1 bp 0x7ffe1d57c550 sp 0x7ffe1d57c420 T0)
==2524==The signal is caused by a READ memory access.
==2524==Hint: address points to the zero page.
#0 0x7f22e894afc1 in drm_connector_commit_state ../subprojects/wlroots/backend/drm/drm.c:652
#1 0x7f22e894b1f5 in drm_connector_commit ../subprojects/wlroots/backend/drm/drm.c:674
#2 0x7f22e89e8da9 in wlr_output_commit_state ../subprojects/wlroots/types/output/output.c:756
#3 0x555ab325624d in apply_output_config ../sway/config/output.c:517
#4 0x555ab31a1aa1 in handle_new_output ../sway/desktop/output.c:974
#5 0x7f22e9272f6d in wl_signal_emit_mutable (/usr/lib/libwayland-server.so.0+0x9f6d)
#6 0x7f22e899b012 in new_output_reemit ../subprojects/wlroots/backend/multi/backend.c:161
#7 0x7f22e9272f6d in wl_signal_emit_mutable (/usr/lib/libwayland-server.so.0+0x9f6d)
#8 0x7f22e895a153 in scan_drm_connectors ../subprojects/wlroots/backend/drm/drm.c:1488
#9 0x7f22e893c2e4 in backend_start ../subprojects/wlroots/backend/drm/backend.c:24
#10 0x7f22e892ed00 in wlr_backend_start ../subprojects/wlroots/backend/backend.c:56
#11 0x7f22e8999b83 in multi_backend_start ../subprojects/wlroots/backend/multi/backend.c:31
#12 0x7f22e892ed00 in wlr_backend_start ../subprojects/wlroots/backend/backend.c:56
#13 0x555ab317d5cc in server_start ../sway/server.c:316
#14 0x555ab317748d in main ../sway/main.c:400
#15 0x7f22e783c28f (/usr/lib/libc.so.6+0x2328f)
#16 0x7f22e783c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349)
#17 0x555ab3134c84 in _start (/home/simon/src/sway/build/sway/sway+0x377c84)
Fixes: 3be6658ee7 ("output: allocate swapchain on first commit")
Closes: https://github.com/swaywm/sway/issues/7373
Because wl_buffer.release is per-buffer and not per-commit, the
Wayland backend might create multiple struct wlr_wl_buffer per
struct wlr_buffer. As a result, the wlr_buffer_unlock() call inside
destroy_wl_buffer() can cause another struct wlr_wl_buffer to be
destroyed.
In backend_destroy() we were iterating the list of buffers with
wl_list_for_each_safe(), which is actually not safe in this case:
the next buffer is cached, but might be destroyed as a side-effect
of calling destroy_wl_buffer().
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3572
