With the addition of a non-surface node type, it was unclear how such
nodes should interact with scene_node_surface_at(). For example, if the
topmost node at the given point is a RECT, should the function treat
that node as transparent and continue searching, or as opaque and return
(probably) NULL?
Instead, replace the function with one returning a scene_node, which
will allow for more consistent behavior across different node types.
Compositors can downcast scene_surface nodes via the now-public
wlr_scene_surface_from_node() if they need access to the surface itself.
RECT is a solid-colored rectangle, useful for simple borders or other
decoration. This can be rendered directly using the wlr_renderer,
without needing to create a surface.
For consistency with the rest of the scene-graph API, prevent detaching
a subtree by giving NULL for the new parent, and don't allow ROOT nodes
to be grafted into another tree.
If nodes are arranged in a tree rather than at a single level, then it
makes sense that there should be a way to move them to a completely
different parent in addition to moving up or down among siblings.
This allows compositors to easily enable or disable a scene-graph node.
This can be used to show/hide a surface when the xdg_surface is
mapped/unmapped.
A new wlr_scene API has been added, following the design ideas from [1].
The new API contains the minimal set of features required to make the
API useful. The goal is to design a solid fundation and add more
features in the future.
[1]: https://github.com/swaywm/wlroots/issues/1826#issuecomment-564601757
If a subsurface is being placed below a subsurface right above it, this
should be a noop. However, `node` pointed to the subsurface that was
moved, which resulted in `subsurface->parent_pending_link` being
inserted into itself, breaking parent's pending subsurface list.
This commit separates finding the requested node and getting it's `prev`
field, fixing the issue.
Similar to commit 85757665e6 ("backend/drm: Check if output is enabled
before sending frame event"), check if the output is still enabled
before sending the frame event. This fixes the bug not only for the DRM
backend, but for wayland and X11 as well.
The protocol specifies that all requests (aside from destroy) are
ignored after the compositor sends the closed event. Therefore,
destroying the wlroots object and rendering the resource inert
when sending the closed event keeps things simpler for wlroots and
compositors.
This wlr_surface_state field was a special case because we don't
want to save the whole current state: for instance, the wlr_buffer
must not be saved or else wouldn't get released soon enough.
Let's just inline the state fields we need instead.
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
Simon Ser
Devin J. Pohly
Kirill Primak
Rouven Czerwinski
Isaac Freund
Tudor Brindus
Quantum
Simon Zeni
zccrs
Yuya Nishihara