Hacker News Reader

Comment by linuxdaemon | Hacker News Reader

I am forced to use ms teams for work. Every time I attempted to share my desktop, teams would crash. I thought it was just because teams sucks. As it turns out, it seems to be that running under wayland was actually causing it. Everything works fine under x.org. After I was running with x.org for a couple days, I realized there are quite a few little oddities that I just lived with and didn't realize it was because wayland was actually messing things up.

View on HN

Teams is an Electron app (like Skype, Signal, VS Code, Atom, etc), which is based on Chromium. Chromium doesn't have Wayland support yet so those run via XWayland. Things should get better once Chromium supports Wayland properly (soon, as it finally entered beta in 2020-09):

https://www.phoronix.com/scan.php?page=news_item&px=Chrome-8...

Electron running on Wayland natively isn't relevant to its ability to screen-share. Even if it were running on Wayland it wouldn't be able to screen-share just based on that alone, because having a Wayland window doesn't have anything to do with screen sharing.

Native applications these days have the option to use pipewire and xdg-desktop-portal for screen-sharing, and it doesn't matter whether they use that from a Wayland window or an Xwayland window. Both Firefox (under Wayland) and Chromium (under Xwayland) use this method today.

Unfortunately Teams does not use that method and instead calls an X function directly, which crashes, as I wrote in the sibling comment.

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.

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.

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.

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!

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.

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.

I had the exact same problem - as others have already said, its a problem with electron not having Wayland support. I solved it in two different ways:

- An unofficial Teams app (https://github.com/IsmaelMartinez/teams-for-linux) which works great - screen sharing works without problems, no crashing, and native notifications!.

- Use teams in qutebrowser: the dev (The-Compiler) added support for screensharing and it works great. Just like the unofficial app above, it also has native notifications, not the weird popup notifications of the official app.

Reply on news.ycombinator.com