When trying to run sway(1) under tmux, instead of directly on virtual terminal, it appears to start up fine, but pressing windows-enter to run a terminal results in a crash instead. This is recent 14-CURRENT on amd64, sway 1.8.1 from packages.
Requires vt(4) to implement K_OFF, so input can be processed by evdev(4) alone. libseat uses K_RAW on FreeBSD as a workaround which makes Sway emit garbage on console while tmux interprets control characters from garbage and triggers SIGQUIT. Workaround: Run "stty quit undef" before Sway See also: https://github.com/torvalds/linux/commit/9fc3de9c8356
A fix would require either to change FreeBSD kernel, change libseat workaround or change tmux. Patches against libseat should be sent upstream unless you want to document incompatibility via sysutils/seatd/files/pkg-message.in I use tmux myself but start Sway before then debug nested Sway started from tmux. For apps within tmux to be aware of existing Wayland session proxy environ(7) from parent terminal e.g., $ tmux set -g update-environment "DISPLAY WAYLAND_DISPLAY XDG_RUNTIME_DIR XDG_SESSION_TYPE XCURSOR_SIZE XCURSOR_THEME DBUS_SESSION_BUS_ADDRESS SWAYSOCK I3SOCK"
FWIW, Xorg since ports 4b9c697c260c (UDEV only supports evdev) and Sway before ports 78457167564c open a new VT unused by getty(8) to dump garbage to. libseat probably follows Xorg -sharevts behavior to support multiseat with -Dlibseat-logind but -Dlibseat-seatd (used on FreeBSD) doesn't support multiseat yet per https://lists.sr.ht/~kennylevinsen/seatd-devel/%3C5838998b-326f-1e0b-29a1-57ac09d137c6%40beroal.in.ua%3E
Reopening as it obviously is a bug, just not necessarily in sway itself. Why exactly do we need libseat/seatd for?
(In reply to Edward Tomasz Napierala from comment #4) > Why exactly do we need libseat/seatd for? $ pkg info -D seatd [...] libseat is used to get DRM master and input devices for non-root users. On Wayland this is only necessary when starting a compositor under KMS console (e.g., /dev/ttyv0 backed by /dev/dri/card0). Nested sessions like "Wayland on X11" or "Wayland on Wayland" don't need extra configuration. [...] See also https://man.sr.ht/~kennylevinsen/seatd/ and https://wayland-book.com/seat.html Note, multi-seat isn't yet supported by LIBSEAT_BACKEND=seatd per https://lists.sr.ht/~kennylevinsen/seatd-devel/%3C5838998b-326f-1e0b-29a1-57ac09d137c6%40beroal.in.ua%3E
Thanks, I think I get this part now. But why do we need a separate privileged daemon for? Just to work around the file permissions for the DRM device?
For privelege separation: reduce the attack surface for a local user to gain root or deter an unsandboxed[1] web browser exploit from exfiltrating live[2] data of the local user. [1] Currently, no browser on FreeBSD uses Capsicum sandboxing. Jails are too coarse thus can be escaped via X11/Wayland protocols unless the display server also runs inside. Wayland has inter-client isolation by default but the actual security requires limiting priveleged protocols which Sway doesn't implement yet (several WIPs exist). [2] Anything encrypted under $HOME like password manager contents, SSH keys (with non-empty passphrase).
Without libseat almost every wlroots consumer in ports used to require setuid bit (plus extra code to drop root permissions shortly after start). Other Wayland compositors (e.g., plasma5-kwin) delegate permissions via consolekit2 or not supported as (e)logind is non-portable. Xorg requires setuid bit as privelege separation is *not implemented* on FreeBSD unlike Linux (via (e)logind) or OpenBSD. Try running benchmarks/tokei against xorg-server + xf86-* drivers vs. sway + wlroots vs. seatd to despair at how much SLOC is run under root on a regular X11-based FreeBSD desktop. K_RAW is an implementation detail of libseat: VT binding is likely constrained by trying to support both single-seat seatd and multi-seat (e)logind. Any display server (Xorg, Sway, Arcan) that uses evdev requires K_OFF to disable duplicate input (on console vs. within display server), even if running under single user mode with full root permissions. See also https://github.com/michaelforney/swc/commit/374e92246a19 for an example Wayland compositor that doesn't use evdev. wscons has similar uAPI to syscons/vt, so KD_XLATE is used under both KD_TEXT and KD_GRAPHICS. Obviously, not practical as the Wayland ecosystem assumes evdev.
(In reply to Edward Tomasz Napierala from comment #4) > Reopening as it obviously is a bug, just not necessarily in sway itself. "Not a bug" (aka INVALID) implies an upstream issue. If you reopen (refuse to engage upstream) then it's a FreeBSD bug. I can't fix it, so changed Assignee and Component.
Val, do you know if anyone has tried to implement K_OFF?
(In reply to Jan Beich from comment #10) No, I’m not aware of any such work already existing, but I’m definitely going to look into it.