There's a lot of assumption around Wayland handling based on the value of "$DESKTOP_SESSION". This is relevant for xdg portals that make screensharing and the like possible.
In the end it's mainly Electron/Chromium things that may need some launch arguments to truly do Wayland. Anything GTK/Qt has been inherent.
This is with WebEx which I think uses WebRTC; it got funny when I disabled too much fingerprinting [in my browser].
I've managed without specific-app-sharing by using workspaces
OBS worked okay the last I toyed with it, IIRC using Pipewire for the capturing.
OBS works fine from what I've heard but must admit I don't use it myself.
I have tried using chrome (stable and unstable) and OBS. OBS uses pipewire to capture (which I believe in turn talks wayland xdg-desktop-portal). I think chromium works the same way (I have the chrome flag "enable-webrtc-pipewire-capturer" turned on). There doesn't seem to be a way to share a single specific window.
There is so much half-cocked or old information out there it is hard to find the right place to look. At the end of the day I'm not sure if xdg-desktop-portal, wlroots, or pipewire need to be improved.
I am using sway + wlroots + xdg-desktop-portal-wlr on my system.
- global keybindings (e.g. I would like variations on super+space with extra modifiers to trigger different behaviours in an application launcher, Kupfer)
- remote control (x2x) --- I use this for essentially seamless kvm between different machines driving adjacent monitors
- I have no choice but to use Zoom screen sharing for work
2. Check out Waypipe, it works really well and supports all application types unlike X11 forwarding. It's more like VNC but easy.
3. Last I checked Zoom screen sharing does work via the browser. The only feature I remember missing was screen control. Same experience with MS Teams too.
(Personally I don't think this is a problem: if the attacker can run programs it's game-over already; just replace "su", "sudo", "firefox", or whatnot with your wrapper script which logs stuff, add ~/.local/bin to PATH by frobbing with shell rc, and presto)
Still missing bspwm, lemonbar and dmenu (bmenu/fuzzel, maybe). For those who care, Steam is also a pain point, from what I've heard.
Games may find some benefit from gamescope: https://wiki.archlinux.org/title/Gamescope
On reflection, almost all of my problems are to do with audio; pipewire, and it's interaction with pulse, alsa, jack and so on - being a 0.1% "pro-audio" user I probably have needs that the average Wayland user doesn't see.
It will get better and I will try again.
The pipewire audio stack replaces pulse and jack, it doesn't play well with Jack and Pulse running on the side. It does work well but from what I understand the pro audio use cases, mainly low latency will be a focus for the version 1.0: https://www.phoronix.com/news/PipeWire-1.0-Release-Plan
Is there a way to streams steam games from a wayland session?
Is it possible to make stacked transparent windows show what is behind them in sway, like we have with i3 and a compositor ?
For this I think I need remote access to a logged out session, which as of my last check is impossible. (It's also poorly supported by gnome on x though)
Maybe I was too literal. The problem isn't executing the reboot command. The problem is logging in remotely to a computer that hasn't been logged into locally since it booted.
In particular the problem is that if I'm going to be remote for an extended period of time I have to ensure that nothing could interrupt the local session, and there's no fix if it does.