We want to call the outputs updated signal when an output scale or transform
changes. Otherwise helpers like the scene surface helpers will not be
notified of scale changes and not pass them to clients.
Since commit 5567aefb, fixed modes haven't been automatically generated
for custom modes, so the output management implementation needs to be
able to handle them directly. To avoid polluting the mode list, only a
single custom mode can be listed at a time and will be removed when a
fixed mode is set.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3744
We can just assume CLOCK_MONOTONIC everywhere.
Simplifies the backend API, and fixes clock mismatches when multiple
backends are used together with different clocks.
TOKEN_STRLEN is not actually the strlen() of the token. It's the
size taken by the token included the final zero byte.
Change the name to make this clearer, and remove unnecessary +1's.
A layer-shell surface can be unmapped if wlr_layer_shell_v1 is
destroyed or the client has committed a NULL buffer. Let's use the
previously introduced wlr_surface.unmap_commit to handle the latter
case instead; this is more consistent with the xdg_surface
implementation logic, where using the hook is more trouble than it's
worth.
Additionally, this commit adds an unconditional surface reset on
destroy, so popups are properly cleaned up even if originally created
with an unmapped layer-shell surface as a parent. Doing so with the
role unmap hook would either result in possibly resetting the surface
twice, which is suboptimal, or having an awkward
`if (mapped) { unmap() } else { reset() }` check.
This flag can be used to figure out whether a particular commit has
unmapped the surface. Private state for now in case we find a better
way to track this.
The name "allow_artifacts" and associated description is very vague, and
theoretically allow for tearing behavior. Clarify that we only intend to
mean artifacts related to output configuration (e.g., modesets).
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3740
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.
