Hacker News Reader

Comment by Fabricio20 | Hacker News Reader

I believe this is not entirely Zoom's fault, I've heard a few horror stories with Wayland and screensharing over the last few years. Particularly when I once tried using OBS Studio and it just didn't work on Wayland. I also remember screenshare from things like Google Meet or Discord only being able to share other chromium tabs and not able to share the desktop or any specific applications.

This whole story sounds to me like some engineer at Zoom was tasked with fixing "linux" back in 2020 and after having several issues similar to what I described (possibly unable to capture other applications?) they decided that quickly screenshotting the screen was a good enough fix. Sadly linux still represents a minority of users so this issue was probably not prioritized as necessary.

View on HN

its entirely zoom's fault. the apis they should be using have been well known and in use for years before they used the improper APIs.

chrome's (and by extension every electron app) issues stem from the fact it had not updated to use the screencasting APIs. afaik they've been updated.

abusing APIs isn't the right way to go here. and zoom is entirely at fault for it. they should have used the correct (and known) apis and worked with upstreams to get the support in place. then they could have properly pointed to upstream and said 'it won't work until these issues are fixed' and provided resources to fix them.

as a result now they are in a shit position of having a completely broken app when the APIs in question do work. I know because I've built a screencasting program on top of them to cast my desktop to chromecast.

Zoom is not as big a company as people think... They're just hustling very hard relative to the sudden explosion of use of their tools.

I'd be willing to wager money that their development process involved attempting to use the correct API, finding that it either failed on a key executive's machine or the developers' own machines (possibly because of one bad driver/hardware/os configuration) but because it didn't work for single key player, they had to invent a work around with a worse solution that worked on the spanning set of architectures they needed it to work on.

> In January 2020, Zoom had over 2,500 employees, with 1,396 in the United States and 1,136 in international locations. It is reported that 700 employees within a subsidiary work in China and develop Zoom software.

https://en.wikipedia.org/wiki/Zoom_Video_Communications#Work...

And Zoom is using that headcount to support 55 billion hours of videoconferencing a year. In contrast, YouTube is supporting only six times that much video watched annually with 40 times Zoom's staff.

"Small" is relative, but Zoom is punching above its weight for the size of its userbase and the load on its services.

Testing on the desktops you claim to support isn't a relative question, it's an absolute question. You can do it - or at least an approximation of it that covers the major facets like Xorg vs Wayland - with 25 employees, let alone 2500.

Even Chrome/Chromium, the web browser with the most developer attention period, has not enabled the pipewire screen sharing support by default.

If you can only share chrome and some apps, that's because you're running Chrome/Discord/Slack/etc in XWayland, hence only having access to other XWayland apps. Chromium (hence Electron apps) still hasn't made the switch to defaulting to wayland when available, you need a few CLI flags to get proper sharing.

You have heard these stories because there were different APIs floating around, some specific to particular compositor families. The author is offering the generic API that should work with all of them.

That's kinda a macrocosm for why Wayland still sucks, though. It always starts with a far-too-small scope, saying "we don't want to retread Xorg's mistakes", after which developers create 15 Competing Standards to replace Xorg functionality, and then the Wayland devs realize that if they don't put their foot down then 90% of the Linux desktop will have a subpar experience. It's a brutal, never-ending treadmill for users and developers alike.

Seems like hyperbole. In this case, there were maybe 3 competing screenshot/screen share methods. None of them were billed as standard. Without the core Wayland devs having to get involved, or even any protocol extensions needing to be made, all of the major desktop environments and even wlroots standardized on a single D-Bus API for the functionality. That API is now a few years old. Yeah it took a while to get adopted/implemented, and Zoom probably has higher priorities. But I do not think X would have magically made the situation better, except by having gone through the process a decade (or more?) ago.

Nobody said the X->Wayland transition would be easy or even straightforward. Only that X has key architectural issues inherent to the protocol and a clean break was needed to make further efficiency and quality gains.

To be fair: It's not only screensharing, it's also screenshots and desktop overlays (important for shells and such).

As well as global keyboard shortcuts, compositing effects, efficient framebuffer rendering, xWayland functionality, configuration-agnostic multidisplay support and input polling.

I'll let you decide for yourself if that's hyperbole, but I think I'm comfortable sticking with Xorg for now.

OBS works fine for me on Wayland through pipewire.

The recommended session manager for pipewire is called WirePlumber. Not something I would think of it I were to look for it on my own. It didn't even exist a couple months back, and about 6months ago pipewire hardly worked on my laptop.

It's great that OBS works fine for you, but it's really odd that Wayland has been around for over a decade and some things people would consider basic functionality has only recently started working.

I for one hope there is something new coming where the core developers aren't so far detached from reality.

Here's my two cents: What even IS pipewire? I know what the compositor is because I've been given the choice of either X or Wayland in the past so I had to learn what they are. I've heard of pipewire in the past but I have no clue what it is, where does it fit in the display stack, etc.. Same for the linux audio stack.

I don't expect final users to know how to do these though. They want to download OBS and it needs to just work. I'm not sure how hard it would be to implement both in the case of Zoom as to support all setups but I'd assume it's not that trivial, and given other comments above where Wayland seems to have had more than one API for capture you can see where some of these issues come from.

This explained pipewire pretty well to me: https://www.youtube.com/watch?v=HxEXMHcwtlI

The short answer is that pipewire reimplements pulseaudio and jack, keeping compatability with both at the same time.

OBS working well on Wayland is AFAICT just in the last year. Pipewire is also just landing in the last 6 months - the most recent Fedora release is the first to use it by default.

On distro with rolling release, I would say pipewire has been working fine since at least January 2021.

Reply on news.ycombinator.com