Screen sharing on Linux: The state of things
I’m a developer, and sometimes I want to show something I’m making to my friends. Screen sharing on Linux sucks. It works pretty decently if the following two things are true:
- You have only one monitor.
- You are using X11.
But, given the productivity boost felt when given extra screen real-estate, it’s not hard to imagine that a vast portion of developers have multiple monitors. Plus, I really want to use Wayland, but due to the difficulty in screen sharing and a bunch of other problems, I can’t retain the same workflows under a different display server.
When I’m talking to my friends, I’m (unforunately) using Discord. For those who don’t know, Discord is a bloated chat-and-voice application for Gamers™, and is where we begin simply because of how popular it is.
Discord added screen sharing functionality back in October 2018. It works amazingly well (even for low-latency, high-framerate things like games) as long as you’re using Windows.
Linux is so low-priority for Discord that a bug where Discord wouldn’t start for every Linux user still managed to find its way to the stable branch of the application. Even right now, my Discord client randomly segfaults on several of my Arch installs.
Anyway, for screen sharing on Linux, we find that it works but we can’t separate our two monitors:
This will become a running theme, as Discord’s electron client is using Chromium’s display capture API here.
My next port-of-call for collaboration is Jitsi Meet. This is an open-source, free video conferencing tool. It requires no account, and is almost perfect.
Except: Both Firefox and Chrome suffer from the same issue when trying to screenshare from a multi-head setup on Linux. They do not have the XRandR integration that allows you to choose an individual monitor, despite having the same functionality on other operating systems.
This is such a shame, but it pretty much discounts the entire landscape of web-based collaboration sites with screen sharing support.
When I want to show something, I can either:
- Share a single window, which can sometimes just share the entire screen anyway, or sometimes crash the entire chat application if I hide the window by switching to another workspace.
- Share outside of the chat application we’re using
nginx-rtmp lets anyone stream to any endpoint by default. With a tiny Flask application and a bit of configuration, we get that out of the way.
Secondly, latency: RTMP is not designed for a low-latency environment like screen-share collaboration. Plus, its roots are pretty shaky - Macromedia’s Flash-to-server video streaming is not really what we want.
Finally, convenience: To watch my screen, viewers have to open a video client, and point it at my RTMP URL. This is way more friction than just looking at the chat application that’s already open. Plus, most RTMP players have built-in delay, so we resort to weird
ffplay -nobuffer commands to get the latency down. This is really terrible ergonomics.
I have a few ideas to make the situation better:
- Somehow, OBS needs to hook up to a video streaming solution that has some form of low-latency player (with WebRTC?)
- Otherwise, we need a nice, low-latency RTMP player that can remember recently-viewed stream URLs.
- But, ideally: There should be patches for Firefox and Chromium could come that fix the issue of display capture when using multiple displays and/or Wayland. (I tried myself, but, man, compiling a browser is a lot of waiting.)
This is a plea to chat platforms and browser developers to improve the situation on Linux.