5 ms·

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 tr

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.

jatone 5y ago
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.
- shadowgovt 5y ago
  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.
  - computerfriend 5y ago
    > 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#Workforce https://en.wikipedia.org/wiki/Zoom_Video_Communications#Work...
    - shadowgovt 5y ago
      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.
      - pie_flavor 5y ago
        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.
      - deleted 5y ago
        [deleted]
- CameronNemo 5y ago
  Even Chrome/Chromium, the web browser with the most developer attention period, has not enabled the pipewire screen sharing support by default.
fanatic2pope 5y ago
OBS works fine for me on Wayland through pipewire.
- rjzzleep 5y ago
  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.
- Fabricio20 5y ago
  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.
  - rmurri 5y ago
    This explained pipewire pretty well to me: https://www.youtube.com/watch?v=HxEXMHcwtlI 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.
- phkahler 5y ago
  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.
tuetuopay 5y ago
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.
solarkraft 5y ago
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.
- smoldesu 5y ago
  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.
  - CameronNemo 5y ago
    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.
    - solarkraft 5y ago
      To be fair: It's not only screensharing, it's also screenshots and desktop overlays (important for shells and such).
      - smoldesu 5y ago
        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.

jatone 5y ago

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.

shadowgovt 5y ago
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.
- computerfriend 5y ago
  > 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#Workforce https://en.wikipedia.org/wiki/Zoom_Video_Communications#Work...
  - shadowgovt 5y ago
    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.
    - pie_flavor 5y ago
      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.
    - deleted 5y ago
      [deleted]
CameronNemo 5y ago
Even Chrome/Chromium, the web browser with the most developer attention period, has not enabled the pipewire screen sharing support by default.

fanatic2pope 5y ago

OBS works fine for me on Wayland through pipewire.

rjzzleep 5y ago
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.
Fabricio20 5y ago
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.
- rmurri 5y ago
  This explained pipewire pretty well to me: https://www.youtube.com/watch?v=HxEXMHcwtlI 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.
phkahler 5y ago
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.

tuetuopay 5y ago

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.

solarkraft 5y ago

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.

smoldesu 5y ago
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.
- CameronNemo 5y ago
  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.
  - solarkraft 5y ago
    To be fair: It's not only screensharing, it's also screenshots and desktop overlays (important for shells and such).
    - smoldesu 5y ago
      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.