There were a couple of problems with this:
1. The behavior is unexpected. Typically objects in wlroots won't
also destroy objects that they depend on. For instance, wlr_scene_output
will not destroy the wlr_output when it's destroyed. It shouldn't be any
different for scene layouts.
2. This fixes a crash where because wlr_output_layout and wlr_scene_output
are both addons to wlr_output, we might get into a situation where
wl_list_for_each_safe might malfunction. See [1]
This means that the compositor needs to manually destroy the output
when they destroy the layout, hence ~breaking. Compositors can just
call `wlr_scene_output_destroy()` if they want to destroy both at the
same time.
[1] https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4358#note_2106260
This reverts commit 1a731596c5.
Co-authored-by: Kirill Primak <vyivel@eclair.cafe>
It makes little sense to have a catch-all grab vaildation function,
considering that e.g. tablet tool implicit grabs are possible as well.
Besides, the function has always returned true anyway.
Since headless and wayland-without-presentation-feedback were firing
present inside their commit impls, present was getting fired before
commit, which is cursed. Defer this with an idle timer so that commit
handlers can run before present handlers.
This fixes a crash in the case where the last cursor was a client surface
cursor but then transitioned into a server managed xcursor that isn't
available. Because the logic would return early before, we would continue
to reference a texture pointer belonging to a client surface but would
otherwise disassociate with it (we wouldn't clear the cursor if the surface
is destroyed) resulting an an eventual UAF.
Let's just make the cursor invisible if we don't know what to show. It's
compositor policy if they want to show a default.
Co-authored-by: Scott Moreau <oreaus@gmail.com>
Fixes: #3686
If the underlying surface is destroyed, but the client has not yet
destroyed the server decoration object, and then tries to call
request_mode() on it, the compositor will crash, because the
wlr_server_decoration struct has been freed, and the wl_resource's
user_data member has been NULLed out.
Yes, this is certainly an error for the client to do that, but I
shouldn't be able to write a buggy (or malicious) Wayland app that can
take down the entire compositor.
wlr_renderer_read_pixels does not need to be called inside a render
pass; rather, it only needs to have the correct buffer bound to
the renderer. This commit optimizes the implementation of
frame_shm_copy(...) by only binding the source buffer instead of
starting a no-op render pass with it.
These states would be set if output_init is invoked with a enabled state.
This would make frame_pending == true which means wlroots will ignore
any further frame events and the compositor will appear dead.
Up until now, frame/present events were only triggered when the
user submitted a buffer. Change the wlr_output API so that these
events are triggered when any commit is applied on an enabled
output.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3708
It's still not possible to commit while a page flip is pending in DRM,
but we don't need to enforce that here and allowing it through the
common interface can be useful for other backends.
This decouples commits from frame scheduling, which is going to make the
new frame schedulers easier to implement.
When setting a custom mode current_mode will not be reset. That means
that next time the compositor tries to reset back from the custom mode,
it will compare against the stale current_mode and unset
WLR_OUTPUT_STATE_MODE erroneously.
We can just use a regular assignment instead. This is more
type-safe since there is no need to provide the struct size.
The remaining memcpy() calls perform array copies or copies from
void pointers (which may be unaligned).
When a wlr_output add to wlr_output_layout, wlr_cursor will create
wlr_buffer of xcursor for the wlr_output, this behavior depends
wlr_renderer of wlr_output, using assert to ensure renderer is
initialized before wlr_output_layout_add and wlr_cursor_set_buffer/
wlr_cursor_set_xcursor.
Opaque region is a optimization hint, (bugs outstanding) it will not
change the output contents, therefore damage does not need to be submitted.
However, we still need to update the visibility state of the other
nodes in the tree. To do this call scene_update_region() by ourselves
but not `scene_node_update()` which will damage the outputs.
