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.
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
Output layout changes originate from the centralized modeset
infrastructure and request_state which already takes care of arranging
and updating outputs as needed.
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.
7e69a7076f ("Drop wl_drm") has dropped wl_drm, however a lot of
software wasn't quite ready for this (Xwayland, libva, amdvlk).
Keep wl_drm disabled by default to pressure the wl_drm phase-out,
but add a -Dlegacy-wl-drm flag for users to restore the previous
behavior in the meantime.
References: https://github.com/swaywm/sway/issues/7897
When removing outputs, it is possible to end up in a situation where
none of the session lock client's surfaces have keyboard focus,
resulting in it not receiving keyboard events. Track the focused
surface and update it as needed on surface destroy.
This ensures that those surprised by the deprecation of SUID operation
receive an error rather than accidentally having sway run as root.
This detection will be removed in a future release.
Try to gain SCHED_RR (round-robin) realtime scheduling privileges before
starting the server. This requires CAP_SYS_NICE on Linux systems.
We additionally register a pthread_atfork callback which resets the
scheduling class back to SCHED_OTHER (the Linux system default).
Due to CAP_SYS_NICE, setting RLIMIT_RTPRIO has no effect on the process
as documented within man 7 sched (from Linux):
Privileged (CAP_SYS_NICE) threads ignore the RLIMIT_RTPRIO limit;
as with older kernels, they can make arbitrary changes to
scheduling policy and priority. See getrlimit(2) for further
information on RLIMIT_RTPRIO
Note that this requires the sway distribution packagers to set the
CAP_SYS_NICE capability on the sway binary.
Supersedes #6992
Wayland compositors handle many file descriptors: client
connections, DMA-BUFs, sync_files, wl_data_device pipes, and so
on. Bump the limit to the max.
Closes: https://github.com/swaywm/sway/issues/6285