This adds a new commandline option, --ready-fd, to send a notification
when sway is ready to run.
This allows a process supervisor to notice sway's startup is complete
which allows, for example, the session manager to start Wayland
programs in the right order. Without this signal, users have to go
through horrible hacks to order services.
For example, I've been using `NotifyAccess=all` in the `sway.service`
file and `exec systemd-notify --ready` in my sway config to emulate
this. Problem is it's racy and error-prone.
A particularly nasty bug triggered by `NotifyAccess=all` is when
`podman` starts and then terminates a container. In that context,
`conmon(8)` ends up notifying systemd it's the session master and
takes over thee `MainPID` field in systemd. When it dies, systemd
believes the session is over and proceeds to kill the entire
session. This is explained in more details in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039857
This might not actually be the right place to do this in the sway
startup sequence, that said. We call `server_run` right after, and
maybe somewhere below that would be a better place. But `server_run`
only calls `wl_display_run` and that's part of the core wayland
library, so that seems a little too far down. I'm not sure Wayland
itself is a place to do this, so for now I'm scratching my own itch
and doing this in Sway itself.
Note that this approach was taken instead of using the proper
`sd_notify` library call, as that approach was refused in #7659. The
`--ready-fd` approach was accepted in swaywm/swaylock#281 so it is
hoped it will be seen as acceptable here.
An alternative implementation would be to instead check the
`NOTIFY_SOCKET` environment variable and use that, if present. That
variable is used by systemd and at least the s6 supervisor to receive
readiness notifications, so it might be less disruptive.
Since output layout is destroyed when the wayland display is destroyed
we run into a destroy listener order problem: Either the display starts
destroying the outputs first, in which case we're good: The existing
handling will clean up. However, things go wrong if the display decides
to destroy the output layout first. In this case, sway will hold
invalid references to the output layout as part of each output so that
when it finally goes to destroy them, sway will dereference destroyed
output layout bits.
Ref: https://github.com/swaywm/sway/pull/6844#issuecomment-1843599513
`gcc-14` added a new warning around dangerous use of `strncpy()` withi
known overflow:
../sway/config.c: In function 'do_var_replacement':
../sway/config.c:983:33: error: '__builtin___strncpy_chk' specified bound depends on the length of the source argument [-Werror=stringop-truncation]
983 | strncpy(newptr, var->value, vvlen);
| ^
../sway/config.c:971:45: note: length computed here
971 | int vvlen = strlen(var->value);
| ^~~~~~~~~~~~~~~~~~
It's a bit fishy to rely on truncating behaviour of `strncpy()`. The
change uses `memcpy()` as more explicit way to express copy of `vvlen`
bytes.
Remove any existing executed criteria items at unmap time. If a window
gets unmapped but not destroyed, we want to reapply 'for_window'
criteria. Fixes#6905.
This reverts commit afde6369
"seat: avoid unneeded reloading xcursor theme".
Always avoiding to reload the xcursor theme prevents reloading the
cursor even when this is desired. Instead seat_configure_xcursor
can determine whether a full reload is necessary.
To stay with the spirit of the reverted change, cursors are only fully
reloaded, if the theme has changed.
Fixes#6931
`gcc-14` added a new `-Walloc-size` warning that makes sure that size of
an individual element matches size of a pointed type:
https://gcc.gnu.org/PR71219
`sway` triggers it on `calloc()` calls where member size is used as
`1` (instead of member count):
swaynag/config.c:169:65: error: allocation of insufficient size '1'
for type 'struct swaynag_button' with size '48' [-Werror=alloc-size]
169 | struct swaynag_button *button = calloc(sizeof(struct swaynag_button), 1);
3d5ae9813d added logic to change the
underlying wlr_toplevel size for floating containers, but it does it
even if the container has no actual coordinates yet. This doesn't really
make sense to update the toplevel size in this case since there's many
things that could affect the initial coordinates (sway commands,
fullscreen state, etc.). Skip this by doing a crude check to see if the
current container state has any width.
Previous behavior was that only if resolution and refresh rate match
exactly, the mode was accepted. As fallback, the mode with the highest
refresh rate and the same resolution was chosen.
New behavior is that the mode with the closest match for the refresh
rate is used with a limit of up to 1Hz. The fallback behavior stays the same.
Additionally, the logging was made more verbose.
