wl_fixed_t is a 32-bit data type, but our doubles are 64-bit. This meant
that two doubles that would map to the same wl_fixed_t could compare
unequal, and send a duplicate motion event.
Refs swaywm/sway#4632.
The protocol allows compositors to not send any keymap to Wayland
clients. Handle a keymap-less keyboard correctly by sending
WL_KEYBOARD_KEYMAP_FORMAT_NO_KEYMAP instead of erroring out in the
mmap call.
When enabling an output, skip the empty buffer allocation if the
backend accepts modesets without a buffer.
This fixes mode-setting with the noop backend.
According to the viewport protocol, upon wp_viewport::destroy():
> The associated wl_surface's crop and scale state is removed.
> The change is applied on the next wl_surface.commit.
Therefore, wp_viewport_destroy(viewport) should remove all viewport state.
Currently, wlroots does not remove the crop and scale state. Instead, a
client must do:
wl_fixed_t clear = wl_fixed_from_int(-1);
wp_viewport_set_source(viewport, clear, clear, clear, clear);
wp_viewport_set_destination(viewport, -1, -1);
wp_viewport_destroy(viewport);
This commit adds the necessary logic into viewport_destroy and makes
wlroots comply with the protocol.
Sometimes we allocate a buffer with modifiers but then fail to
perform a modeset with it. This can happen on Intel because of
bandwidth limitations. To mitigate this issue, it's possible to
re-allocate the buffer with modifiers.
Add the logic to do so in wlr_output.
Adds `wlr_buffer_resource_interface` and `wlr_buffer_register_resource_interface`,
which allows a user to register a way to create a wlr_buffer from a specific
wl_resource.
The first time wlr_buffer_from_resource is called with a wl_buffer
resource that originates from wl_shm, create a new
wlr_shm_client_buffer as usual. If wlr_buffer_from_resource is called
multiple times, re-use the existing wlr_shm_client_buffer.
This commit changes how the wlr_shm_client_buffer lifetime is managed:
previously it was destroyed as soon as the wlr_buffer was released.
With this commit it's destroyed when the wl_buffer resource is.
Apart from de-duplicating wlr_shm_client_buffer creations, this allows
to easily track when a wlr_shm_client_buffer is re-used. This is useful
for the renderer and the backends, e.g. the Pixman renderer can keep
using the same Pixman image if the buffer is re-used. In the future,
this will also allow to re-use resources in the Wayland and X11 backends
(remote wl_buffer objects for Wayland, pixmaps for X11).
When wlr_output manages its own swap-chain, there's no need to
hook into the backend to grab DMA-BUFs. Instead, maintain a
wlr_output.front_buffer field with the latest committed buffer.
This function doesn't need the wl_resource anymore.
In the failure paths, wlr_buffer_unlock in surface_apply_damage
will take care of sending wl_buffer.release.
We often juggle between wlr_buffer and wlr_client_buffer variables.
Use a consistent naming: "buffer" for wlr_buffer and "client_buffer"
for wlr_client_buffer.
`wlr_client_buffer_import` is splitted in two distincts function:
- wlr_buffer_from_resource, which transforms a wl_resource into
a wlr_buffer
- wlr_client_buffer_create, which creates a wlr_client_buffer
from a wlr_buffer by creating a texture from it and copying its
wl_resource
[1] and [2] have introduced new wl_array usage in wlroots, but
contains a mistake: wl_array_for_each iterates over pointers to
the wl_array entries, not over entries themselves.
Fix all wl_array_for_each call sites. Name the variables "ptr"
to avoid confusion.
Found via ASan:
==148752==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x602000214111 in thread T0
#0 0x7f6ff2235f19 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:127
#1 0x7f6ff1c04004 in wlr_tablet_destroy ../subprojects/wlroots/types/wlr_tablet_tool.c:24
#2 0x7f6ff1b8463c in wlr_input_device_destroy ../subprojects/wlroots/types/wlr_input_device.c:51
#3 0x7f6ff1ab9941 in backend_destroy ../subprojects/wlroots/backend/wayland/backend.c:306
#4 0x7f6ff1a68323 in wlr_backend_destroy ../subprojects/wlroots/backend/backend.c:57
#5 0x7f6ff1ab36b4 in multi_backend_destroy ../subprojects/wlroots/backend/multi/backend.c:57
#6 0x7f6ff1ab417c in handle_display_destroy ../subprojects/wlroots/backend/multi/backend.c:124
#7 0x7f6ff106184e in wl_display_destroy (/usr/lib/libwayland-server.so.0+0x884e)
#8 0x55cd1a77c9e5 in server_fini ../sway/server.c:218
#9 0x55cd1a77893f in main ../sway/main.c:400
#10 0x7f6ff04bdb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#11 0x55cd1a73a7ad in _start (/home/simon/src/sway/build/sway/sway+0x33a7ad)
0x602000214111 is located 1 bytes inside of 16-byte region [0x602000214110,0x602000214120)
freed by thread T0 here:
#0 0x7f6ff2235f19 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:127
#1 0x7f6ff1c04004 in wlr_tablet_destroy ../subprojects/wlroots/types/wlr_tablet_tool.c:24
#2 0x7f6ff1b8463c in wlr_input_device_destroy ../subprojects/wlroots/types/wlr_input_device.c:51
#3 0x7f6ff1ab9941 in backend_destroy ../subprojects/wlroots/backend/wayland/backend.c:306
#4 0x7f6ff1a68323 in wlr_backend_destroy ../subprojects/wlroots/backend/backend.c:57
#5 0x7f6ff1ab36b4 in multi_backend_destroy ../subprojects/wlroots/backend/multi/backend.c:57
#6 0x7f6ff1ab417c in handle_display_destroy ../subprojects/wlroots/backend/multi/backend.c:124
#7 0x7f6ff106184e in wl_display_destroy (/usr/lib/libwayland-server.so.0+0x884e)
previously allocated by thread T0 here:
#0 0x7f6ff2236279 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7f6ff1066d03 in wl_array_add (/usr/lib/libwayland-server.so.0+0xdd03)
[1]: https://github.com/swaywm/wlroots/pull/3002
[2]: https://github.com/swaywm/wlroots/pull/3004
The wl_touch.frame event is used to group multiple touch events
together. Instead of sending it immediately after each touch event,
rely on the backend to send it (and on the compositor to relay it).
This is a breaking change because compositors now need to manually
send touch frame events instead of relying on wlr_seat to do it.
When wlr_output.swapchain is used instead of the backend's, the
buffer_type will be set to SCANOUT even if wlr_output_attach_render
has been called. This tricks wlr_output_damage into thinking the
whole output needs to be repainted.
Workaround this issue by forcing buffer_type to RENDER when the
output has a back-buffer set.
Will clean all of that up when removing the precommit event handler
altogether.
This commit fixes damage tracking on the Wayland, X11 and headless
backends.
Right now we rely entirely on implicit sync for synchronizing
access to GPU buffers. Implicit sync works by setting
synchronization points on the buffer in writers, and letting
readers wait on these sync points before accessing the buffer.
With OpenGL, sync points are created using functions such as
eglSwapBuffers or glFlush. If none of these special functions
are called, no sync point will be created and readers will
potentially access a buffer that hasn't finished rendering yet.
In the context of wlroots, OpenGL is the writer and the backend
(KMS or parent Wayland/X11 session) is the reader. After we're
done rendering a frame, and before passing that frame to the
backend, we need to call glFlush.
glFlush is called when the buffer is detached from the renderer.
This is a task done by output_clear_back_buffer. So let's call
this function before invoking the impl->commit hook, instead of
calling it after.
All of this is maybe a little tricky to get right with the
current renderer_bind_buffer API. The new
wlr_renderer_begin_with_buffer API is much better, because glFlush
is called on wlr_renderer_end, so it's more intuitive.
Closes: https://github.com/swaywm/wlroots/issues/3020
Everything needs to go through the unified wlr_buffer interface
now.
If necessary, there are two ways support for
EGL_WL_bind_wayland_display could be restored by compositors:
- Either by using GBM to convert back EGL Wayland buffers to
DMA-BUFs, then wrap the DMA-BUF into a wlr_buffer.
- Or by wrapping the EGL Wayland buffer into a special wlr_buffer
that doesn't implement any wlr_buffer_impl hook, and special-case
that buffer type in the renderer.
This allows renderers to choose between implementing the old
wlr_renderer_impl.texture_from_wl_drm hook, or opt for the new
wlr_drm stub. The stub has the advantage of not requiring any
special support code: stubbed wl_drm buffers look exactly like
DMA-BUFs from linux-dmabuf-unstable-v1.
This will allow us to remove all of our EGL wl_drm support code
and remove some weird stuff we need just for wl_drm support. In
particular, wl_drm buffers coming from the EGL implementation
can't easily be wrapped into a wlr_buffer properly.
We were bumping the pending sequence number after emitting the
commit event, so commit handlers were seeing inconsistent state
where current.seq == pending.seq. This prevents commit handlers
from immediately locking the pending state.
Fix this by bumping the pending sequence number before firing the
commit event.
There are still many situations where the buffer scale is not
divisible by scale. The fix will require a tad more work, so
let's just log the client error for now and continue handling
the surface commit as usual.
Closes: https://github.com/swaywm/sway/issues/6352
On commit failure, we need to unbind the back buffer from the
renderer.
This fixes assertions triggered on commits following a failed commit
where the compositor called wlr_output_attach_render.
Introduce wlr_shm_client_buffer, which provides a wlr_buffer wrapper
around wl_shm_buffer.
Because the client can destroy the wl_buffer while we still are using
it, we need to do some libwayland tricks to still be able to continue
accessing its underlying storage. We need to reference the wl_shm_pool
and save the data pointer.
This new API allows buffer implementations to know when a user is
actively accessing the buffer's underlying storage. This is
important for the upcoming client-backed wlr_buffer implementation.
Prior to this commit, subsurfaces could only be placed above their
parent. Any place_{above,below} request involving the parent would
fail with a protocol error.
However the Wayland protocol allows using the parent surface in the
place_{above,below} requests, and allows subsurfaces to be placed
below their parent.
Weston's implementation adds a dummy wl_list node in the subsurface
list. However this is potentially dangerous: iterating the list
requires making sure the dummy wl_list node is checked for, otherwise
memory corruption will happen.
Instead, split the list in two: one for subsurfaces above the parent,
the other for subsurfaces below.
Tested with wleird's subsurfaces demo client.
Closes: https://github.com/swaywm/wlroots/issues/1865
There isn't always a good time to prune old tokens. Compositors
which only implement a "give focus on activation" logic can prune
tokens on focus change. However other compositors might want to
implement other semantics, e.g. "mark urgent on activation". In this
case a focus change shouldn't invalidate other tokens.
Additionally, some tokens aren't necessarily tied to a seat.
To avoid ending up with an ever-growing list of tokens, add a timeout.
Instead of passing a wlr_texture to the backend, directly pass a
wlr_buffer. Use get_cursor_size and get_cursor_formats to create
a wlr_buffer that can be used as a cursor.
We don't want to pass a wlr_texture because we want to remove as
many rendering bits from the backend as possible.
According to libinput, release events are generated when device is unplugged,
and libinput copies this behavior for device removal. Let's do the same for
our virtual keyboard.
8f846a41fa
This is another attempt to fix#2034 and the following sway issue:
https://github.com/swaywm/sway/issues/6254
Note that we have other key repeating issues in sway, which aren't addressed
by this patch. Since the virtual keyboard itself isn't destroyed when the
keyboard grab is destroyed, we'll probably need some trick to reset the state
of the corresponding virtual keyboard when the grab is released.
https://github.com/swaywm/sway/issues/6095https://github.com/swaywm/sway/issues/6193
Previously, the same struct was used for linux-dmabuf-v1 params
and buffer. This made the whole logic a little bit awkward, because
a wlr_dmabuf_v1_buffer could either be still being constructed, or
be a complete buffer.
Introduce a separate wlr_linux_buffer_params_v1 struct for buffer
params still being constructed. Once the params are complete (ie.
once the create request is sent), the params struct is destroyed
and the buffer struct is created.
This will help with [1] as well.
[1]: https://github.com/swaywm/wlroots/issues/2664
Drop wlr_dmabuf_v1_buffer_from_params_resource and
wlr_linux_dmabuf_v1_from_resource. Contrary to wl_buffer, these
resources are internal linux-dmabuf-v1 implementation details and
should not be shared with other interfaces.
Use 128-bit hexadecimal string tokens generated with /dev/urandom
instead of UUIDs for xdg-foreign handles, removing the libuuid
dependency. Update readme and CI. Closes#2830.
build: remove xdg-foreign feature
With no external dependencies required, there's no reason not to always
build it. Remove WLR_HAS_XDG_FOREIGN as well.
Some clients (like Xwayland) will fallback to wl_drm if the compositor
doesn't explicitly advertise support for implicit modifiers, even when
the compositor supports explicit modifiers. This behavior sounds correct
from a protocol point of view.
The original motivation is the following crash:
#0 0x00007f0ddeddeef5 in raise () at /usr/lib/libc.so.6
#1 0x00007f0ddedc8862 in abort () at /usr/lib/libc.so.6
#2 0x00007f0ddedc8747 in _nl_load_domain.cold () at /usr/lib/libc.so.6
#3 0x00007f0ddedd7646 in () at /usr/lib/libc.so.6
#4 0x00007f0de033f8de in gles2_get_renderer_in_context (wlr_renderer=0x612000003640) at ../subprojects/wlroots/render/gles2/renderer.c:38
#5 0x00007f0de0341675 in gles2_begin (wlr_renderer=0x612000003640, width=3840, height=2160) at ../subprojects/wlroots/render/gles2/renderer.c:186
#6 0x00007f0de033b100 in wlr_renderer_begin (r=0x612000003640, width=3840, height=2160) at ../subprojects/wlroots/render/wlr_renderer.c:56
#7 0x00007f0de03466ed in gles2_blit_dmabuf (wlr_renderer=0x612000003640, dst_attr=0x60b000150148, src_attr=0x7fff9f9bfde0) at ../subprojects/wlroots/render/gles2/renderer.c:591
#8 0x00007f0de033d717 in wlr_renderer_blit_dmabuf (r=0x612000003640, dst=0x60b000150148, src=0x7fff9f9bfde0) at ../subprojects/wlroots/render/wlr_renderer.c:210
#9 0x00007f0de04cbc3b in frame_handle_output_commit (listener=0x611000220bc8, data=0x7fff9f9c0050) at ../subprojects/wlroots/types/wlr_screencopy_v1.c:303
The GLES2 renderer assumes it'll have a wlr_buffer to render to.
Instead of accomodating for the edge-case of rendering without a
wlr_buffer, drop wlr_renderer_blit_dmabuf calls and instead use
wlr_renderer_bind_buffer just like the rest of the wlr_renderer users.
wlr_renderer_blit_dmabuf is now unused in wlroots.
The upside is that the new blit_dmabuf function in screencopy is
renderer-agnostic.
Compute only the transform matrix in the output. The projection matrix
will be calculated inside the gles2 renderer when we start rendering.
The goal is to help the pixman rendering process.
Store the previously focused surface in `state->focused` as well as in
`state->original` when starting an implicit grab. That way at the end
of an implicit grab, the detection whether the grab started and ended
on the same surface works as intended, even if the original surface was
never left at all.
Since output_destroy() calls wl_list_remove() on the output's link,
the manager must still be valid. This is the same bug fixed in bf926e3
but with a different interface.
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.
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 function will allow compositors to implement input handling in a
way consistent with rendering more easily.
Calling wlr_layer_surface_v1_surface_at() and checking if the result is
a wlr_xdg_popup is flawed as there may be subsurfaces in the popup tree.
This function will allow compositors to implement input handling in a
way consistent with rendering more easily.
Calling wlr_xdg_surface_surface_at() and checking if the result is a
wlr_xdg_popup is flawed as there may be subsurfaces in the popup tree.
Since device_destroy() calls wl_list_remove() on the device's link,
the manager must still be valid. However if the manager is destroyed
before the seat as the wl_display destroy handlers are called, devices
listening for the seat to be destroyed will access free'd memory in
wl_list_remove().
Since device_destroy() calls wl_list_remove() on the device's link,
the manager must still be valid. However if the manager is destroyed
before the seat as the wl_display destroy handlers are called, devices
listening for the seat to be destroyed will access free'd memory in
wl_list_remove().
- The DRM backend initially doesn't have a frame scheduled initially.
However the compositor is expected to set a mode to start the
rendering loop (frame_pending is set to true in drm_crtc_pageflip).
- The headless and X11 backends have a timer to schedule frames, so they
ignore this hint completely.
- The Wayland backend renders a fake frame to start the rendering loop.
It's the only case where a frame is pending on init, move the
assumption there.
The DRM backend adds custom modes to wlr_output.modes
Currently modes that are added after the first occurence of
wlr_output_configuration_head_v1 are not added to wlr_output_head.mode_resources.
