In general wl_signal isn't well-suited for Sway: Sway doesn't need
any modularity, and signals make it trickier to track down exactly
what happens down the stack.
Replace Sway's output disable signal with a simple list tracking
for the only user.
This reverts commit e28e6484e8.
This change tried to remove nodes from all points of reference to allow
immediate destruction. However, it missed things like the children lists
cloned by transaction states of parent nodes.
Adding all that extra cleanup would not be in the spirit of a PR
claiming to simplify teardown. Let's wait for someone to come up with a
cleaner approach instead.
Fixes: https://github.com/swaywm/sway/pull/8738
A sway_node may end up being referenced in either a queued transaction,
pending transaction or as a dirty node. To manage this, the transaction
system has been responsible for destroying containers, workspaces and
outputs at the end of their last referenced transaction.
This significantly complicates the teardown flow of surfaces and
outputs. Instead, remove the node from transactions and dirty lists so
that the callsite can remove and free the node immediately.
The render_workspace_button and render_binding_mode_indicator functions are
almost the same. This commit extracts the common rendering code into a new
render_box function.
workspace_output_get_highest_available took an output to exclude as
argument, meant to avoid accidentally reselecting an output we are
evacuating workspaces from.
Outputs are now removed from the list before we evacuate, making
exclusion unnecessary. Remove the argument.
This ensures these functions are always called (even when a library
such as wlroots or libc perform the fork) and removes the need to
manually call them.
In [1] we re-introduced a debug flag to enable wl_drm. Time has
passed and Xwayland + VA-API + amdvlk now all support
linux-dmabuf-v1.
[1]: https://github.com/swaywm/sway/pull/7916
Destroying the wlr_renderer in a callback to its own renderer_lost event
is unsafe due to wl_signal_emit*() still accessing it after it was
destroyed.
Delegate recreation of renderer to an idle callback and ensure that only
one such idle callback is scheduled at a time by storing the returned
event source.
Change begin_destroy to remove event listeners before the final destroy,
since otherwise event listeners would be removed twice, which crashes.
This fixes a crash in wlroots listener checks. See #8509.
sway_input_method_relay can be destroyed from two sources, either the
seat is destroyed or the manager protocol objects are destroyed due
compositor exit.
This fixes a crash in wlroots listener checks. See #8509.
The behavior of handlers registered with signal(3p) is not well-defined
for signals delivered more than once, as laid out in the man page.
We should replace our use of signal with sigaction, but for SIGCHLD
specifically we can also just skip the signals altogether by setting the
handler to SIG_IGN which causes child reaping to not be required.
Fixes: https://github.com/swaywm/sway/pull/8567
IPC clients generally expect executed commands to have taken effect when
the command completes, while delayed modeset means that it can take
several milliseconds more before e.g. an output is enabled.
However, modesetting on every output command in the IPC call could on
systems with already slow modesetting behavior lead to an unresponsive
system for a not insignificant period of time.
To strike a balance, force modeset once all the commands of this IPC
call have executed if a modeset is pending.
Some commands require outputs to be enabled. These commands are deferred
to allow outputs to be discovered, but the delayed modeset might only
run some time later.
Force a modeset to occur before running deferred commands.
Fixes: https://github.com/swaywm/sway/issues/8433
GUD devices uses RGB565 by default for performance reasons. Allow
specifying render_bit_depth 6 to pick this format. The definition works
out if you consider the maximum number of bits per channel instead of
the average.
Arranging lock surfaces rely on the sway_output width and height being
updated, but these are only updated after the commit has been completed
and all commit listeners have executed. This means that the lock
surfaces will not be appropriately scaled to match a change in output
dimensions, and may reveal what is under the lock background.
Replace the implicit arrange through the output commit listener with an
explicit arrange after the output configuration is finalized.
This might have regressed by other transition away from output commit
listeners for other arrange tasks, but even then it would have
erroneously relied on signalling order.
Instead of using a single finalized output config per output, accept a
regular list of output configs like the one ultimately stored for
configuration purposes. This allows the output management code to test
an augmented configuration while still using the same output config
logic, without having to mutate the stored configuration.
This in turn allows us to make a few APIs private. A bug note about an
existing issue with derade to off is added as well.
Output layout changes originate from the centralized modeset
infrastructure and request_state which already takes care of arranging
and updating outputs as needed.
The reasoning for using a commit handler is to ensure that all paths for
output changes are correctly handled. With the centralized modeset
infrastructure in place, we can move the logic there. This allows us to
be smarter and avoid extraneous arranges, output manager updates and
transaction commits.
The side-effect is a minor duplication for the special-case
request_state, but the shared path will be relied upon further in future
commits to justify this duplication.
The only reason it's included there is for a declaration of
struct sway_server, but we can just forward-declare it.
This avoids rebuilding almost all of Sway when touching server.h.
All other server.h includes are from source files, not headers.
Regular Wayland clients shouldn't care about the position or size
of outputs. Hide xdg_output from unprivileged clients to make sure
they're not doing shenanigans with this information.
Instead of having a build-time option to enable/disable xwayland
support, just use the wlroots build config: enable xwayland in
Sway if it was enabled when building wlroots. I don't see any
use-case for disabling xwayland in Sway when enabled in wlroots:
Sway doesn't pull in any additional dependency (just pulls in
dependencies that wlroots already needs). We have a config command
to disable xwayland at runtime anyways.
This makes it so xwayland behaves the same way as other features
such as libinput backend and session support. This also reduces
the build matrix (less combinations of build options).
I think we originally introduced the xwayland option when we didn't
have a good way to figure out the wlroots build config from the
Sway build system.
The original sway output config implementation enabled one output at a
time, testing modes, render formats and VRR support as it went along.
While this sort of fallback is easy to do, it has the downside of not
considering the effect of neighbor outputs on the configuration
viability.
With backend-wide commits, we can now better consider the effect of
neighbor outputs, but to handle the fact that we commit all outputs at
once we need to perform a more elaborate search of viable
configurations.
Implement a recursive configuration search for when the primary
configuration failed to apply.
