The sad state of screen sharing on desktop Linux
anthony.som.codes
anthony.som.codes
Screen sharing works OK on Linux under X11. I can't remember the last time that was a problem. I was definitely doing it on a daily basis back when KDE was somewhere at a 3.x release, so before 2008. At least single-monitor setups work fine, I can't say I've tried it on multi-monitor setups in a very long time. When I did (that was so long ago my two monitors were bulky CRTs) it was OK but who knows, maybe it got broken in the meantime.
I mean yes, once in a blue moon I run into a system that has a weird glitch, but that's just as true with Windows and TeamViewer. Every once in a while you run into a machine that just won't budge and you need to ask Google. That's true on any OS.
(Before you tell me how you've had no problem with Wayland on your Thinkpad running Fedora 87 or Arch, yes, I get that. Making it work on everyone's laptop, and getting it to do what everyone needs, is a real hurdle in software development, and Wayland isn't even halfway there when it comes to this particular hurdle).
Afaik they don't want programs to see each others pixels or input for security reasons (but thereby also breaking your own control over programs) so the following useful things will never be possible by design except with specific solutions on case by case basis (so: brittle)
Screenshots, video capturing, automating mouse and keyboard input (autoclicking), screen sharing, ssh with graphics, clipboard in scripts, ...
Or are those things planned anyway?
https://github.com/swaywm/sway/releases
Wayland/wl-roots compatible screen-recorder: https://github.com/ammen99/wf-recorder
(FWIW, X11's approach to program isolation isn't ideal for everything, either. The same things that make it so convenient to automate mouse and keyboard input make it very hard to write a good screen locker, for example.)
Whether or not we'll see free (as in freedom and beer) compositors that conveniently implement all these things is a whole different story. A lot of XFree86's (and later Xorg's) feature set was developed by well-paid teams of experienced engineers, who benefited from a lot of work done by other well-paid teams on other platforms, and the architecture and licensing of the whole thing meant that everyone could benefit from their work. That's not really the case with Wayland. There's actually a lot of work, and a lot of money being poured into Wayland compositors. Lots of car infotainment systems run one, for example, and Wayland support has been pretty much a standard requirement for virtually every BSP I've worked on in the last four years. But most of that work is very system-specific, platform-specific, and its substantial part -- the code -- never gets upstreamed, because "upstream" is just a protocol spec. A lot of the Wayland protocol has been standardized that way, but it's still up to every compositor to implement it.
There's some hope due to projects like wlroots and Drew de Vault, its lead developer, is one of those people who seem like they can pull anything off. (Oh yeah: https://drewdevault.com/donate/ ). But -- unlike twenty years ago -- there's very little commercial backing for Linux on the desktop. I don't know if the FOSS community will be able to keep up with these things.
In theory that is correct. In practice, the Wayland protocol fails to address the required access control policy interfaces necessary for a modern Desktop to work. A Desktop is not a phone interface or a car entertainment system. Resource sharing that enables basic things like push-to-talk, remote work or full screen streaming are absolutely essential for a Desktop computing environment. Wayland developers push such functionality down as a particular "implementation detail" of a Wayland compositor, which is a huge mistake. Donating to braindead projects like wlroots will not solve the problem at all. Access control policy needs to be made part of the core protocol ASAP or Wayland will have no chance to succeed in any meaningful way in the future.
This is pretty much how X11 was built, too, by the way.
Maybe then Wayland should change "how Wayland developement works" because after 10 years of developement the results are disappointing to say the least. Projects like the Arcan display server show that even a single dude writing stuff in his spare time can easily be more productive.
It helped that there were a bunch of big players sinking lots of money into it, and the documentation was good enough that it was easy to get started -- way easier than it is with Wayland. So after 1993 or so things really started picking up speed. But Xfree cca. 1994 wasn't great.
The development of early X11 didn't work very well at all. Even Keith Packard himself says so [1].
The difference is that there isn't much commercial involvement on the desktop side. SGI, DEC, HP, Sun, IBM, and later Red Hat & friends, sank quite some money into X's development, and a non-zero amount of that money ended up going into a particular implementation (XFree, later Xorg) and in developing desktop solutions on top of it.
Most of that money stream is flowing towards other things than desktops now. Desktop Wayland development is largely a hobby effort (there are some exceptions, but nowhere near as many as in the heyday of X11, and not all of these efforts apply throughout the Wayland "universe").
That may eventually change as Xorg's maintenance will eventually stop, since no one really wants to do that anymore...
* Very few actually interesting programs run natively on it * As such the push to improve is largely political * Leading to low effort commitment outside the orgs that push it * Which deters developers for actually porting stuff to it
As such you end up with half baked PoCs that doesn't incentivize anybody to move them forward while X is still working better by far.
In short, there is no compelling reason for anybody to switch platforms. It's a solution looking for a problem.
What is true is that you don't want any random app to also log everything for security reasons. Instead it will have to ask for permission first.
We have resorted to custom tooling that uses VNC via the company VPN, which works decently with better quality.
A workaround would be to launch a second Xorg instance and point Chrome and the app you want to share at that server.
One of them is Pipewire, which is shaping up to be the replacement for things like Pulseaudio and JACK - it's a daemon and tooling for slinging audio and video streams around between processes.
The other is xdg-desktop-portal - designed for use with Flatpak, it has now become a set of standard dbus APIs for interacting with your desktop manager and window manager on any Linux system. Specifically, org.freedesktop.portal.ScreenCast[0] gives you a Pipewire handle to the screen, possibly after asking for permission. This is supported in recent Firefox versions.
There are xdg-desktop-portal implementations for GNOME, KDE, and wlroots-based compositors, although the wlroots implementation only supports screenshots so far, and does not yet implement screencasts.
[0] https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
The following all work perfectly on my 3 monutor setup:
* google meet
* skype for linux
* slack
* a standard, from tutorial, webrtc screen share and chat
I also use turboVNC to do control between my own devices (it has decent graphics support).
I can't see what those three huge players are missing that the author needs. They've tried two smaller players and are decrying it as a platform issue. Plenty of other non hacker suggestions in this thread as well.
I thought it was GenZ's version of Ventrilo and Teamspeak
Creators have really begun to actively use it to manage and engage with their fan-bases, and I bet there are some companies that use it as a slack alternative.
This isn't even mentioning the wide variety of bots and integrations for Discord, or how private text chats can enable/switch to audio or video communication.
You can cheat it by starting the session with a single monitor activated, xrandr-ing the other one active after you start sharing, but that shouldn't be required.
The single screen sharing application I've had success with on Linux+XOrg and multimonitor is Zoom. No other application properly allows me to share just one screen.
Well, this blog post barely scratches the surface.
The Linux userspace display stack is currently undergoing a big overhaul, following the changes that happened in the kernel a few years ago (DRI3, KMS, atomic modesetting, etc).
All of this made Wayland possible. That, plus the fact that apps rasterize their surfaces themselves nowadays (GPU-accelerated trough OpenGL/Vulkan).
So, here comes Wayland with a new security model: you can't spy on other windows, so you cannot hack together a desktop sharing solution. A proper, cross-desktop solution is actually being worked on: pipewire[1].
Pipewire aims to replace both pulseaudio and jack for audio, and bring video in as well. So you will be able to direct which video feed goes where, use the same webcam for multiple applications, and have applications take a video feed, transform it, and plug it elsewhere. You can see where this is fitting with desktop sharing: one feed per window, one feed per screen, one feed for the whole desktop, plus variants. Want to overlay a webcam? No problem. Everything is backed by Gstreamer for realtime hardware-accelerated video encoding/decoding.
And the icing on the cake: Flatpak spearheaded the development of "portals"[2]: cross-desktop interfaces for individual programs to ask the user when accessing restricted resources (like a microphone, or a folder on your computer).
So, what's needed here is:
* Finish up pipewire and have it shipped on most distributions (should be installed in fedora 31, optional for sound in 32, default for sound in 33)
* Have compositors talk to pipewire [3]
* Have browsers and other software talk to pipewire [4]
* ???
* Profit
Good progress is being made on these points, except maybe the last? I expect support to start working out-of-the-box in some distros/browser/compositor combinations in 2020. Actually, support seems further along than I thought it was. But it seems that wlroots-based compositor haven't yet decided to support the xdg screensharing portal, and rely instead on a custom wayland extension. I wouldn't be surprised if such a portal is implemented for those.
The main issue here is everyone waiting on everyone else before enabling/implementing it. But it looks like we're 80% there, and it just needs to be enabled in some cases (and pipewire installed). Then it will trickle down to most distros and electrons apps.
However, I don't think legacy X apps will be able to continue sharing the desktop (they can still be shared by wayland capture programs, or capture the desktop if they implement the new interface). I guess pipewire might be able to create a virtual webcam for these, though.
Valve might be working on their own stack with their "Gamescope" wayland compositor[5], for their streaming solution.
And in the end, this should work much better, with hardware encoding, actual security, zero copy, etc. Hopefully there won't be a "next big thing" that breaks everything in just a few years.
[1] https://wiki.archlinux.org/index.php/PipeWire
[2] https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
[2] https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
[3] http://jgrulich.cz/2018/03/06/screen-sharing-in-plasma-wayla...
[3] https://jgrulich.cz/2018/07/04/how-to-enable-and-use-screen-...
[3] https://wiki.gnome.org/Projects/Mutter/RemoteDesktop
[3] https://www.reddit.com/r/linux/comments/8le7rm/first_steps_f...
[3] https://github.com/emersion/xdg-desktop-portal-wlr/issues/1
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1496359 (looks disabled by default at compile time)
[4] https://bugs.chromium.org/p/chromium/issues/detail?id=682122 (pipewire disabled in chrome://flags until v81 due to waiting on https://github.com/flatpak/xdg-desktop-portal-gtk/issues/204 "dialog hell" it seems)
[4] zoom currently uses a gnome-specific screenshot API as a workaround: https://www.reddit.com/r/swaywm/comments/dr8yld/zoom_screens...
[5] https://www.gamingonlinux.com/articles/valve-give-a-little-m...
Compared to when Windows overhauled its entire display server, network, and sound driver architecture back in Vista, Wayland's pace is downright glacial. I suppose one can expect it will be ready for prime time by 2030, just in time for the next paradigm to make it obsolete.
> still people revert to X11 to get things done
To me, that's the reason right here: X11 still works. Microsoft has more control over its software (as you can't fork and maintain it if you don't like where it's going).
If you want a more apt comparison, transitioning to Wayland is blazing fast compared to going to how long it takes for IPv6 to gain marketshare. Or for everyone to transition to electric vehicles. Once again, dynamics are different since the old tech still works. At least with Wayland, some advantages are immediately tangible compared to the IPv6 transition.
A friend of mine would likely describe it as potential wells with some energy barriers (ecosystem not mature) to overcome :)
Wayland has gained some momentum lately, in no small part thanks to sway. As a result, I feel the XDG initiative and cross-desktop coordination is stronger nowadays, so further evolutions of the Linux desktop could happen faster. In any case, I encourage you to give Wayland a go, and report/fix bugs :)
I've been using sway as my daily driver for 2 years now; one of the rare things I have to fire up X11 for sometimes is Steam remote play or screen sharing.
“That can’t be true because there are literally dozens of applications that can do Z, just not the ones your using.”
At best you can say that companies making popular apps don’t bother with good Linux support which has pretty much always been true.
TeamViewer is good, but ohmy is it expensive if you want to use it for commercial purposes. I've evaluated it for family support, and it's certainly robust -- they're not joking about the claims of very cross platform. But I haven't tested it with multiple monitors on either side.
I haven't run Zoom on any of my computers, and after last year's revelations I'm unlikely to feel I should.
x11vnc looks neat and seems to be relatively popular, but I've never had to dive into it.
Compare VMware Workstation, which costs non-trivial monies, and typically breaks in difficult-to-fix ways every few months if you're on bleeding edge kernels, and unfixable ways no matter what you're doing after a couple of years, requiring more monies to upgrade for a functionally identical experience.
As other commenters say, latest Fedora has Wayland and Pipewire properly configured and by enabling a flag in Chrome/Chromium (search by "pipewire") it will run smoothly and allow you to choose which screen to share.
Anyway compared to what technically it's possible (i.e. some clicks heard and there and it works), it's not really a acceptable solution.
Half my team uses Mac, the other half Linux and one Windows guy. Zoom works pretty well for calls, but I'd like something better for pairing.
Basic screen sharing does work as you said.
Really? Every time I've tried, I just end up hurting my neck so I'm pretty used to single screen and switching between the terminal and the browser.
Slack, zoom, Hangouts all work too.
So maybe the problem is discord.
That will appear soon enough, I guess?