> Lack of support for the BSD lineages is a failure.
Not true. FreeBSD and OpenBSD have had various wlroots compositors such as Sway available for some time. e.g [1] Some people have even been experimenting with KDE-wayland on FreeBSD since 2021.
Wayland support on any OS is not binary because there is no single layer like Xorg. It's a matter of individual compositors and their components being ported to the OS, which is a matter of popularity, and the BSDs are always at a disadvantage in that respect, so they lag behind, same as other software. Nevertheless, they are definitely gaining support. Then again this distinction is only technical, for functional support new DEs/WMs would always have needed to be ported regardless of display architecture, the only case it would not is for an Xorg drop-in, which defeats the purpose.
> Lack of screenshots/screencasts is a failure.
... but there are many functional screencapture apps, and even browser support, I use this pretty much every week. I think you might be operating on out of date info. I'd highly recommend giving it another try, the Wayland ecosystem has come quite far over the last decade.
Wayland unfortunately is a mess that is hard to implement so we get a balkanized situation where not only everything often boils down to Big Important Process in the middle (that actually integrates more things than X.Org used to), the set of features it supports are way more balkanized and most importantly, specific to that one Big Important Process as they can't be viably separated out.
And even then you have to deal with a mix because you have to work through two different unsynced possibly broken in weird ways connections (Wayland + D-Bus).
This results in how last week I couldn't screenshare under Wayland, and had zero chances to figure it out - and to make it worse since I had some important state and no time to play with reboots, I couldn't fix it.
XOrg was predominantly used as a useless middleman between a compositor and a window manager communicating with each other. Just because the wayland compositor is “one big important process” doesn’t mean that the whole architecture is more complicated.
Multiple IPCs make the whole stuff way more complex, there is a reason why we have a big monolith as browsers and not some `curl | htmlRender | jsInterpreter` Rube Goldberg machine — the unix philosophy is not the pan ultimate design, it works in some cases and is utterly broken in others.
X11 != the lowest common denominator implementation of X11. Nor was everyone using it with big heavy compositors (honestly, the only reason I used a compositor for years was intel removing sync circuitry from their iGPUs).
And Wayland did not stop requiring multiple IPCs, in fact it mandates them as several features require passing data by secondary channels, not just for Portals et al - some don't even have any described way to reliably pass the information that I have seen (like how to pass around cookie to let one application activate window of another? Or maybe the spec is such a mess that I'm looking at completely wrong place when I tried to fix ability to reliably switch between applications without extending compositor).
And yes, the architecture is more complicated in practice, otherwise it might have reached parity with what X11 did after as many years - like input method support. Unfortunately it's so broken that you have multiple versions of it in practice, it requires extra IPC in practice, and at least in my experience just does not work.
I'm using Debian so I can't say how well this applies to FreeBSD:
You need to have `xdg-desktop-portal-wlr` or equivalent package installed (should be depended upon by sway package really), and also the gtk one for some other stuff wlroots doesn't implement like notifications I think (don't worry it doesn't drag in all of gnome).
This is technically the only thing you should need to do beyond picking a wayland compatible screen capture program or browser - However it's possible the dbus variables are broken if you wrote your own sway config from scratch (guilty)... Depending on your OS, the default config should do this automatically, on Debian it includes /etc/sway/config.d/50-systemd-user.conf, I can't say for FreeBSD. So point is if your config omits the dbus-update-activation-environment command, you probably need to include it in your config.
Those environment variables are set by sway, but this line imports them into dbus (is my limited understanding) so that programs call the correct xdg portal backend.
Not true. FreeBSD and OpenBSD have had various wlroots compositors such as Sway available for some time. e.g [1] Some people have even been experimenting with KDE-wayland on FreeBSD since 2021.
Wayland support on any OS is not binary because there is no single layer like Xorg. It's a matter of individual compositors and their components being ported to the OS, which is a matter of popularity, and the BSDs are always at a disadvantage in that respect, so they lag behind, same as other software. Nevertheless, they are definitely gaining support. Then again this distinction is only technical, for functional support new DEs/WMs would always have needed to be ported regardless of display architecture, the only case it would not is for an Xorg drop-in, which defeats the purpose.
> Lack of screenshots/screencasts is a failure.
... but there are many functional screencapture apps, and even browser support, I use this pretty much every week. I think you might be operating on out of date info. I'd highly recommend giving it another try, the Wayland ecosystem has come quite far over the last decade.
[1] https://docs.freebsd.org/en/books/handbook/wayland/