[Arnavion]

Yes, Teams uses a function that is unsupported by Xwayland (XGetImage, if I remember the backtrace correctly), so it crashes. I worked around it with a rather convoluted setup that involves running Xephyr under Xwayland, then running Teams under Xephyr (via setting `DISPLAY`), and running vncviewer under Xephyr connected to a VNC server (wayvnc) sharing my screen on the parent wayland instance. Then I tell Teams to share the "whole screen" (ie the entire Xephyr window) and quickly maximize the vncviewer window (within the Xephyr window).

To be able to maximize vncviewer you do need a compositor running under Xephyr too. I picked i3 to be the most minimal. Again, i3 can be told to run in the Xephyr window by setting `DISPLAY`.

One caveat is that I still use Teams under Wayland to join calls for the audio, so this setup means I need two Teams instances to join the same call. This works for meetings but not for individual calls. Of course if you want to use the Xephyr'd Teams to do audio too there shouldn't be any problem; I just prefer having easy access to the Teams window to mute myself, etc instead of having to reach into the Xephyr window and unmaximize the vncviewer window.

People on the #sway IRC channel on Freenode suggested an alternative might be to use v4l2loopback to create a "camera" device that is sourced from the screen and then have Teams use it as a webcam, but I couldn't get v4l2 to work on my distro (it kept insisting my distro's ffmpeg couldn't encode video even though it could) so I didn't investigate further.

[michaelmrose]

I salute your creativity and tenacity but what the actual fuck the need for a rube goldberg setup in order to make an application work is ... unfortunate. If I did such a thing I would take one last look to take pride in my work before deleting the whole affair and installing an OS that isn't broken.

[Arnavion]

Well, I knew what I was signing up for when I decided to switch from X to Wayland, so I'm personally okay with it. It's the same with doing anything that isn't mainstream, such as my decision to use Linux in a workplace where a lot of stuff is Windows-first, and sometimes Windows-only. The best thing the iPhone did to the world was to make web applications more popular, and as long as Safari lags on web standards it pushes websites to not use Chromium-only features and give Firefox users like me a chance.

Anyway, a less convoluted setup might be to use the browser version of Teams in a browser where it allows you to screen-share, ie Chromium and not Firefox. IIRC when I tried it a few months ago people on the call said they could only see me broadcasting a black screen, but I know the browser is fine so it had to have been a Teams issue. Maybe it's fixed now.

Hopefully these applications will catch up soon. As another example, Zoom's native Electron application uses a GNOME-specific method of screen-sharing which doesn't work in non-GNOME DEs, but I've heard the browser version works fine.

[martinsb]

Re: black screen when using Teams from browser. Check you have environment variables set correctly: XDG_SESSION_TYPE=wayland and XDG_CURRENT_DESKTOP=sway. I set up them in my .zshrc before starting sway. This helped me to fix the black screen issue. Hope it helps you too!

[Arnavion]

If those env vars weren't set screen-sharing with xdpw would be broken as a whole because pipewire wouldn't invoke it, which wasn't the case. Other applications like that one python gstreamer script could access xdpw just fine, and Firefox and Chromium could screen-share in other websites (like Mozilla's gUM test page) just fine; the only one broken was Teams.

[tbr1]

The v4l2 trick "works", but usually the application will use a lossy video codec optimized for faces, not screens. wf-recorder to v4l2 as a poor-man's screenshare to Discord ends in a blurry mess. YMMV with Teams.