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.
Only wlr_output_damage works in transformed coordinates,
wlr_output->damage is in output-buffer-local coordinates.
This essentially reverts 1ecc1b5 and fixes 1477401.
Rename wlr_renderer_get_dmabuf_formats to
wlr_renderer_get_dmabuf_texture_formats. This makes it clear the formats
are only suitable for creating wlr_textures.
wlr_surface_send_enter now stores outputs that have been entered.
Combined with a new 'bind' event on wlr_output, this allows us to delay
enter events as necessary until the respective wl_output global has been
bound.
Closes: https://github.com/swaywm/wlroots/issues/2466
xdg_popups can be destroyed by the compositor when closed. When this happens,
wlroots makes the xdg_popup surface inert and resets the xdg_surface role to
NONE.
Currently, wlroots sends a protocol error and asserts that an xdg_surface has
a role when committed. This is racy if at the same time the client commits an
xdg_popup and the compositor closes it. This patch removes the assertion and
ignores commits on xdg_surfaces without a role set.
We were previously exporting DMA-BUFs when receiving the capture_output
request, and sending a done event on wlr_output.events.precommit. Instead,
export and send done on wlr_output.events.commit.
The data of a head is only sent when it is enabled. While the head was disabled
data might have been changed. In this case clients were not informed about this
change. A later enable change that does not also update the other data must
still lead to the propagation of this data.
Since we do not know what other data was changed while the head was disabled
just send together with an enable change all current data.
The protocol requires clients to set opposing anchors when requesting
a width or height of 0.
The goal of this patch is not to break clients that rely on this
behavior but to improve the consistency of the layer shell ecosystem
through adherence to the protocol.
This brings the layer-shell api in line with that of xdg-shell and
avoids reimplementing this function in every compositor in order to
render layer shell popups correctly.
This event contains a `committed` bitfield, which allows callers to know
which output fields changed during the commit.
This allows users to setup a single atomic commit listener, instead of
setting up one listener for each event (mode, scale, transform, and so
on).
References: https://github.com/swaywm/wlroots/issues/2098
These states are distinct in the time period between the ack_configure
and the next commit on the surface. Splitting these states avoids the
following race for example:
- client starts at 1000x1000
- wlr_xdg_toplevel_set_size 500x500
- size is different -> configure sent
- client acks the configure
- wlr_xdg_toplevel_set_size 1000x1000
- compare_xdg_toplevel_state returns true since there is no pending
configure and the currently committed size is still 1000x1000
- no new configure is sent
- client commits at the size it last acked, 500x500
Because wlr_renderer_blit_dmabuf() undoes y-inversion on the source
buffer, it is incorrect to pass the y-inversion flag of the source
buffer to the user.
wlr_drag sets up keyboard, pointer and touch grabs, which block 'enter'
events (and thus focus changes). For the compositor to be able to update
focus (e.g. to focus the drop target) from the destroy handler, the
grabs must be released before the destroy event is signalled.
The output backend API is now mostly state-less thanks to the atomic
hooks (commit and test). There is one exception though: attach_render.
This function makes the rendering context current. However sometimes the
compositor might decide not to render after attach_render (e.g. when
there's nothing new to render to the back buffer). Thus
wlr_output_rollback has been introduced to revert the pending state.
Because the output backend API is mostly state-less, the only thing
wlr_output_impl.rollback needs to do is revert the current rendering
context. Rename the function to rollback_render to make this clear. Add
a check in the common wlr_output code to only call rollback_render when
attach_buffer has been previously called.
On the long term, we'll be able to remove attach_render and
rollback_render together.
During surface finalization we may not have received a new buffer,
resetting width and height in this case is wrong since we display the
old buffer in this case.
This is necessary for some grabs, which currently have no way of knowing
when the pointer/keyboard focus has left a surface. For example, without
this, a drag-and-drop grab can erroneously drop into a window that the
cursor is no longer over.
This is the plumbing needed to properly fix swaywm/sway#5220. The
existing fix, swaywm/sway#5222, relies on every grab's `enter()` hook
allowing a `NULL` surface. This is not guaranteed by the API and, in
fact, is not the case for the xdg-shell popup grab and results in a
crash when the cursor leaves a surface and does not immediately enter
another one while a popup is open (#2161).
This fix also adds an assertion to wlr_seat_pointer_notify_enter() that
ensures it's never called with a `NULL` surface. This will make Sway
crash much more until it fixes its usage of the API, so we should land
this at the same time as a fix in Sway (which I haven't posted yet).
This fixes a crash that happens when a client requests a frame on a
backend that does not implement export_dmabuf.
An assertion fails with the message:
sway: types/wlr_output.c:777: wlr_output_lock_attach_render: Assertion
`output->attach_render_locks > 0' failed.
This introduces the enter and leave events for wlr_keyboard_group.
The enter event is emitted when a keyboard is added to the group while a
key is pressed that is not pressed by any other keyboard in the group.
The data is a wl_array of the pressed key codes unique to the keyboard
that should now be considered pressed.
Similarly the leave event is emitted when a keyboard is removed from the
group while at least one key is pressed that is not pressed by any other
keyboard in the group. The data is a wl_array of the pressed key codes
unique to the keyboard that should now be considered released.
The purpose of these events are to allow the compositor to update its
state to avoid corruption. Additionally, for the leave event, the
focused surface may have been notified of a key press for some or all of
the key codes and needs to be notified of a key release to avoid state
corruption.
These were previously emitted as normal key events, but they are not
normal key events. There is no actual key press or release associated
with the events. It's purely for state keeping purposes. Emitting them
as separate events allows the compositor to handle them differently.
Since these are purely for state keeping purposes and are not associated
with an actual key being pressed or released, bindings should not be
triggered as a result of these events.
We should throw a protocol error if the relevant capability has never
existed when get_(pointer|keyboard|touch) is called. Otherwise, it
should succeed, even if the capability is not currently present.
This follows the spec, and avoids possible races with the client when
capabilities are lost.
Closes: https://github.com/swaywm/wlroots/issues/2227
When calling assert(0) instead of returning a value, -Wreturn-type
warnings are triggered because assertions can be disabled. Replace these
assertions with abort().
This is currently inconsistent with the rest of the library and a bit of
a footgun for new compositors. However, this breaks the API in a very
unfortunate way for existing compositors.
This is necessary so that sway can determine when to start emulating
pointer events -- it shouldn't start doing so during an implicit grab,
even if the pen is over a surface that doesn't bind tablet input.
Refs swaywm/sway#5302.
In the case that only one axis received an event, rotating the input can
cause the change to actually happen on the other axis, as far as clients
are concerned.
This commit updates the axes flags to be consistent post-rotation.
Fixesswaywm/sway#4776.
A client requesting frames in the ready callback may miss frames that
happen while it is waiting to receive the event or sending the request.
If that happens, the client will have an outdated frame for an
indefinite period. A new frame might not be scheduled for a very long
time.
With this change, clients will receive new frames immediately upon
request.
Check for a NULL keyboard_state.keyboard value in
seat_client_create_keyboard() before trying to use it, as is done in
other functions like seat_client_send_repeat_info(). Prevents a segfault
in certain situations on keyboard removal, as seen in the sway issue.
Closes: https://github.com/swaywm/sway/issues/5205
Closes: https://github.com/swaywm/wlroots/issues/2073
GCC is complaining about a maybe-uninitialized variable when doing a
release build. Even if that can't actually happen because all enum
values are handled, add an abort call to silence the warning.