Spoiler alert: the author of the article is using Wayland. Lots of things aren't working on Wayland yet. (I'm also being pretty handwavy here about Wayland. Wayland "the protocol" isn't a piece of software you use -- lots of problems are not specific to Wayland, but to a particular compositor).
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, ...
There's nothing inherently preventing any of these things from working on Wayland. I mean yes, the protocol (and its implementations) are meant to disallow programs from seeing each others pixels and input events by default and/or without authorization, which isn't a stupid idea at all. But you can certainly implement screenshots, video capturing, automatic input, screen sharing and whatever in Wayland compositors. I think Sway implements most of these things, in fact.
(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.
> There's nothing inherently preventing any of these things from working on Wayland.
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.
That's really not how Wayland development works. Except for resource management and data transfer (wl_compositor, wl_shm_pool etc.), pretty much everything in the "core" Wayland protocol has originated in compositor implementations that were then standardized. "Donating to braindead projects like wlroots" is exactly how this problem is going to be solved. There's no Wayland cabal where people just sit around a table writing specifications in the hope that they'll eventually get implemented somewhere.
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's a development model that worked reasonably well for the X protocol. Wayland isn't great now but it's not much worse than X was in 1994, after 10 years of development (and the first version of X11, which saw the light of day in 1987 or so, was pretty different from the early drafts of the X protocol). There was no ICCCM back then (ok, there was ICCCM 1.0 but that wasn't anywhere near great or universal), no session management, no xkb, no xdamage, no Xinerama, no hotplug, no glx, no randr...
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.
Most of the bad parts that Keith Packards covers are about the pre-X11 days. But yeah, Wayland is developed more or less like X11 was developed after the mid '90s or so.
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.
Google Hangouts on Firefox used to be able to share a single window on X11 (Ubuntu). It broke or was removed at some point, and we've moved over to Zoom at work since then (so I don't know the current state).
This one isn’t because of any inherent problem with Xorg but because Chrome doesn’t have the feature to select a specific client and instead is just capturing the root window always. Nothing is really preventing Chrome or any other app from doing this.
A workaround would be to launch a second Xorg instance and point Chrome and the app you want to share at that server.
To be clear - the state of screensharing on Wayland is fairly interesting, and integrates a handful of new components.
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.
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 add TeamViewer to your list but Skype doesn't work well anymore on Ubuntu 19.10. I can see only the top left part of the screen of the person I'm talking to. Resizing Skype doesn't help. Luckily none of my customers are using it anymore. MS managed to kill it by making it too business unfriendly. Everybody moved either to meet or slack or both.
It's actually a bit more like a hybrid of slack and ventrilo, but for fandoms and gaming. I primarily use discord for group chats and playing TTRPGs online. but I'm also in several podcast fan servers (official and unofficial) where a community of folks with common interests congregates.
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.
Google meet and slack have the same issue with multimonitor setups. It works great with a single monitor but not multiple. This is not just Wayland but X as well.
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.
It can share specific monitors, just not windows. This satisfies the authors stated gripe (though they may be able to do window specific shares with Discord)
TL;DR: make sure you have pipewire and xdg-desktop-portal installed, look up how to enable pipewire for your browser. It might help.
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.
You speak as though Wayland is some super new bleeding-edge tech that just needs some time to come around, but the reality is that it is over 10 years old and still people revert to X11 to get things done because of its issues.
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.
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.
I've had good success with krfb / krdc -- but on both sides of that it's been one monitor only.
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.
Debian - stable, testing, and unstable - consistently, if somewhat infrequently, over about 9 years.
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.
AnyDesk works flawlessly on Linux. It's used at my company for customer support, in a mix of Linux, Mac and Windows workstations. It supports multiple monitors and provides packages for major distros.
Could you use an external capture device like an elgato which is about $100
And use it with obs to transmit your screen?
Sorry speaking from ignorance about true nature of issue just a guess.
I wonder if anyone has tried using xpra for screen sharing. It does provide a watt to view the same application on multiple computers according to the documentation.
This is actually a good idea. You could then route the video signals from the application you want (including the real webcam) to the virtual webcam. THis should be possible with pipewire already, but I don't know yet of a proper GUI mixer?
Just don't try to annotate the screen (or let a viewer do it). I ended up with a blank screen over everything (even the task switcher) and no way to quit. Fortunately I had a keyboard shortcut to launch a new terminal, so used that then typed "killall zoom<enter>". It worked :D
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).