'xwayland disable' is not necessary to run programs natively under Wayland
I'm afraid the statement is not totally true. Under one circumstance, which is when GUI libraries env variables properly set. Maybe a bug?. I've noticed on sway log that
xwayland.c function of isn't called if and only if
xwayland disable is set.
This is a GTK+ bug. It tries to connect to Xwayland even if it only uses Wayland. I've no idea why, it would be nice to report this to the GTK+ devs and figure out how to fix it.
If you don't disable Xwayland and have it uninstalled, you'll have an invalid `DISPLAY` set.
Keeping XWayland enabled is good for programs that don't work otherwise
It depends on user choice. I think having a wiki section on how to disable xwayland may benefit those who want to avoid X.Org.
hidepid can prevent people from executing Sway as an unprivileged user
It took me some time to understand that and there seems to be unresolved topics around the web from people who I bet had the same problem (e.g. here). Shouldn't we mention that here? Note that it's different from what Xorg does, for which the systemd-logind drop-in recommended in Security#hidepid is enough (I wrote about that in more detail here).
- "Can" prevent? Under which circumstances does it actually prevent? -- Lahwaacz (talk) 21:31, 10 August 2019 (UTC)