Introducing the new Zoom Community Champion Program where we recognize our most engaged community members for their contributions.

Learn more and join
cancel
Showing results for 
Search instead for 
Did you mean: 

Wayland screen sharing broken with GNOME 41 on Fedora 35

intrlocutr
Participant

Hi,

 

I recently updated to Fedora 35 with GNOME 41. This GNOME release restricts the screenshot API which Zoom has used for screen sharing on Wayland, so the screen sharing functionality no longer works (see here on Ask Fedora).

 

I require screen sharing for school, and I'm sure many others have a similar requirement/system configuration. With Wayland increasingly becoming a de facto standard on Linux, it is crucial that Zoom support Wayland screen sharing.

1 ACCEPTED SOLUTION

It's not a bug in xdg-desktop-portal-wlr, so I'm not going to create a pull request to add code that does nothing (if the client is behaving correctly...). There's already work on supporting to share only a region of the screen (https://github.com/emersion/xdg-desktop-portal-wlr/pull/156) which should coincidentally also fix Zoom.

 

Simply running Zoom with "env XDG_CURRENT_DESKTOP=GNOME /usr/bin/zoom" should be enough to make Zoom think it's on Gnome while still keeping dbus working.

 

Edit: This should not be marked as solution! If any, https://community.zoom.com/t5/Meetings/Wayland-screen-sharing-broken-with-GNOME-41-on-Fedora-35/m-p/... provides a workaround for the issue, which has to be fixed by Zoom!

View solution in original post

379 REPLIES 379

stephdl
Listener

Just another Linux user who is asking mandatory feature., I would love to use zoom but now it is simply not possible to share my screen.
Go to xorg is not an acceptable  solution, wayland is the default xserver in many distros, ubuntu 22.04 LTS will use it obviously.

YaBoiB
Community Champion | Zoom Employee
Community Champion | Zoom Employee

Hello,
My name is Brandon. Thanks for joining the Zoom Community! Thank you all for your continued patience while we work on a solution to this issue. As I have stated previously on this thread, I will be sure to reach out with any updated information as soon as it is available to me. @All, please be patient as we work on a solution with the Zoom Engineers. I hope that every one of you had a joyous New Year!

 

Regards, 

Brandon

If this response was helpful for you, please do not forget to click on the accepted solutions button!

Do you have any updates on wayland and zoom screensharing compatibility ?

macdabby
Listener

looking for support here too, paid account if that helps 😄 

although i wish there were a workaround to temporarily disable whatever is blocking access to the api

there is a workaround, also not recommended, see the other comments above.

 

but the better workaround then making the api unsafe again:

 

join from the browser and share over that. by that you get a proper screensharing because all major browser implemented over 1 year ago what zoom still has to do.

jack_hq1
Listener

Hello,

I'm writing to ask if there are any updates to future releases with this bug fix. I know of personally 3 organizations who are waiting for a release so that they can continue using their machines for zoom conferencing (school lectures, business meetings, church services, etc) so even a rough timeline of when the critical bug is fixed would be much appreciated. Many thanks 🙂

 

 

Hello!

 

I have been watching this space actively for the last 3 months. It seems to me that up until now there has been no clear indication of even a timeline of when this bug will be fixed.

While this situation is not as bad Virtual Backgrounds (I was also part of the community who posted a feature request on the developer forum), someone has taken the time to create Write up of the problem (link attached)

This is in hopes that zoom will not just hopefully making a fix in this issue, but also to look into Zoom’s continued discrimination against Linux users, (at the very least putting us as second class citizens). I do understand that there are business priorities, and I don’t expect you guys to look into every bug that needs fixing. I only have issues with the underlying message you guys are putting out.

 

To my understanding, help has been offered even by one of the gnome developers, but until today this fix has been under ‘Active Development’ with no clear timeline on when this crucial bug will be fixed.  

If Zoom as an organisation has decided that supporting Linux distros as a first class citizen is not in your business priorities, I ask that this is clearly communicated, and that you guys clearly communicate that this is not a priority for now. 

If you guys actually do see the value in supporting linux clients, then I ask that you guys take clear actionable steps to assure us that we can continue using Zoom in our organisations. 

 

I do not wish to stop using zoom as I believe it’s a great platform to connect with my colleagues, friends and family. If there’s anything we can do as a community please communicate that because I believe we are more than willing to work together to make this product work!

 

Cheers

Very well stated!


@jack_hq1 wrote:

someone has taken the time to create Write up of the problem (link attached)


To quote that writeup…

 


Will Zoom look into why all of their support agents ignored clear descriptions of not only how but also why Zoom itself was broken? Will they start actively testing all supported desktop linux OSes—and ideally their beta releases to detect upcoming issues sooner? Will they form closer ties with the Free Software/Open Source community and benefit from all the effort that volunteers put into diagnostics and debugging? Will they actively monitor official channels for API deprecation? Will they hire any developers that use a modern GNU+Linux OS as their daily driver? At so many turns could this outcome have been avoided.

kano
Listener

 I am also affected by this, and have been from the beginning. I am running Sway which is a wl-roots based compositor for Wayland which has an implementation of the standard xdg-desktop-portal which zoom should be using in order to properly support every Linux use case in a single shot. It really bugs me to have to logout and log in to an (from my perspective) inferior desktop in order to participate in a zoom meeting. As I work in the academic space where Zoom is ubiquitous, at least in Sweden,  while at the same time having a large Linux user base this is problematic not only for me, but for many of my colleagues a cross many universities.

solymr
Listener

Please fix it Zoom!

muckid123
Listener

Is there any update or timeline? This thread is open for a while without any real updates and it seams like the issue itself is know for a lot longer than this thread is open.

 

ngompa_datto
Listener

Hello @YaBoiB,

 

I've filed tickets with Zoom about this issue since I first discovered the problem at the beginning of last year with Fedora Linux 34 with KDE Plasma using Wayland. In those tickets, I also provided the technical approach to solving the problem. When it also hit Fedora Linux 35 with GNOME using Wayland, I detailed it once again and asked for some more urgency to resolve the issue.

 

What was particularly galling is that the tickets were closed implying that my problem was solved, but it's quite obviously not. It sounds like it's being worked on now, though, so I'd really like to know when that will ship.

YaBoiB
Community Champion | Zoom Employee
Community Champion | Zoom Employee

Hello @ngompa_datto

 

 We will create a support ticket for you, and I will work with you on this issue. To all other users on this thread, if you already have a support ticket created and it is being worked on by a member of the Zoom Support Technical Support Engineers, please reference this thread to the agent to assist you on a one-on-one basis. Please know that this issue is still considered a high-priority case, and we are diligently working with the Zoom Engineering Team to find a solution. 

If this response was helpful for you, please do not forget to click on the accepted solutions button!

alpacaalpaca
Listener

Sorry,  duplicate reply...

waioefjwaeiofj
Listener

Chiming in to report same issues with Slackware x86 and x64 Current and OpenSUSE 😞 - please add wayland support!  Thanks

YaBoiB
Community Champion | Zoom Employee
Community Champion | Zoom Employee

Hello All, 

 

 Update on this issue. The latest Zoom Version is now working on Fedora 36. I do not have this version installed. I am relying on internal information for this resolution. Please install the latest Zoom Version for Fedora 36 and provide your feedback to this thread. 

 

Once again, thank you to all who have reported and provided valuable feedback. We at Zoom genuinely appreciate the feedback and assistance. Please continue to supply feedback to this thread. 

If this response was helpful for you, please do not forget to click on the accepted solutions button!

Fedora 36 is 3 months in the future and doesn't yet exist as a specific thing you can install

 

Assuming by latest you mean 5.9.1.1380 (which is what the website currently gives me) screencasting is still unavailable and looking at the bus Zoom is still making forbidden calls to private screenshot APIs (which of course fail) — So either your internal sources have something newer than we do, or they seem to be mistaken.

Good news, but confusing.  Please clarify which specific version you mean.  I'm assuming you mean the *next* release of Zoom, not the latest release.  I tried the latest release, 5.9.1 (1380), on Fedora36/rawhide and it doesn't work.

The release notes page doesn't mention anything about fixing the issue in the next release https://support.zoom.us/hc/en-us/articles/205759689-Release-notes-for-Linux

I note that release has been delayed, an optimist could derive something from that I suppose


@YaBoiB wrote:

The latest Zoom Version is now working on Fedora 36. […] Please install the latest Zoom Version for Fedora 36 and provide your feedback to this thread. 


I have just installed Version: 5.9.3 (1911). No change. Still PulseAudio warning. Still no displays or windows are detected.

EDIT: After upgrading the rest of the packages on my system, I did see multiple displays which could be shared. I assume this means Zoom targets some dependency that isn't met on a base F35 install, only F36. That means also that all earlier versions and distributions are left probably out of this fix. 🤦

If it's useful, here's the package comparison between when it didn't work (before/left) and when it did (after/right):

$ rpm-ostree db diff 4bb8301ce5639227589617b788943b1f95f93889407eec1ee63a762cb0a94c01 0a57bed3e1968eb3105ff8098569beb0449afeda7cd65285bd6308e1ec817b07 
ostree diff commit from: 4bb8301ce5639227589617b788943b1f95f93889407eec1ee63a762cb0a94c01
ostree diff commit to:   0a57bed3e1968eb3105ff8098569beb0449afeda7cd65285bd6308e1ec817b07
Upgraded:
  abattis-cantarell-fonts 0.301-3.fc35 -> 0.301-5.fc35
  audit 3.0.6-1.fc35 -> 3.0.7-1.fc35
  audit-libs 3.0.6-1.fc35 -> 3.0.7-1.fc35
  chrony 4.1-3.fc35 -> 4.2-1.fc35
  crun 1.4-1.fc35 -> 1.4.1-1.fc35
  cryptsetup 2.4.2-1.fc35 -> 2.4.3-1.fc35
  cryptsetup-libs 2.4.2-1.fc35 -> 2.4.3-1.fc35
  cups 1:2.3.3op2-11.fc35 -> 1:2.3.3op2-13.fc35
  cups-client 1:2.3.3op2-11.fc35 -> 1:2.3.3op2-13.fc35
  cups-filesystem 1:2.3.3op2-11.fc35 -> 1:2.3.3op2-13.fc35
  cups-filters 1.28.10-2.fc35 -> 1.28.11-1.fc35
  cups-filters-libs 1.28.10-2.fc35 -> 1.28.11-1.fc35
  cups-ipptool 1:2.3.3op2-11.fc35 -> 1:2.3.3op2-13.fc35
  cups-libs 1:2.3.3op2-11.fc35 -> 1:2.3.3op2-13.fc35
  distribution-gpg-keys 1.60-1.fc35 -> 1.61-1.fc35
  dnsmasq 2.86-3.fc35 -> 2.86-4.fc35
  ethtool 2:5.15-1.fc35 -> 2:5.16-1.fc35
  evolution-data-server 3.42.2-1.fc35 -> 3.42.3-1.fc35
  evolution-data-server-langpacks 3.42.2-1.fc35 -> 3.42.3-1.fc35
  expat 2.4.1-2.fc35 -> 2.4.3-1.fc35
  flatpak 1.12.2-1.fc35 -> 1.12.3-1.fc35
  flatpak-libs 1.12.2-1.fc35 -> 1.12.3-1.fc35
  flatpak-selinux 1.12.2-1.fc35 -> 1.12.3-1.fc35
  flatpak-session-helper 1.12.2-1.fc35 -> 1.12.3-1.fc35
  freetype 2.11.0-1.fc35 -> 2.11.0-2.fc35
  gstreamer1-plugins-bad-free 1.19.3-1.fc35 -> 1.19.3-4.fc35
  gupnp 1.4.1-1.fc35 -> 1.4.3-1.fc35
  gutenprint 5.3.4-5.fc35 -> 5.3.4-6.fc35
  gutenprint-cups 5.3.4-5.fc35 -> 5.3.4-6.fc35
  gutenprint-libs 5.3.4-5.fc35 -> 5.3.4-6.fc35
  harfbuzz 2.8.2-2.fc35 -> 2.9.1-1.fc35
  harfbuzz-icu 2.8.2-2.fc35 -> 2.9.1-1.fc35
  hplip 3.21.2-15.fc35 -> 3.21.12-1.fc35
  hplip-common 3.21.2-15.fc35 -> 3.21.12-1.fc35
  hplip-libs 3.21.2-15.fc35 -> 3.21.12-1.fc35
  ibus-m17n 1.4.8-1.fc35 -> 1.4.9-1.fc35
  ibus-typing-booster 2.15.11-1.fc35 -> 2.15.15-1.fc35
  initscripts-service 10.11-1.fc35 -> 10.13-1.fc35
  kernel 5.15.14-200.fc35 -> 5.15.16-200.fc35
  kernel-core 5.15.14-200.fc35 -> 5.15.16-200.fc35
  kernel-devel 5.15.14-200.fc35 -> 5.15.16-200.fc35
  kernel-modules 5.15.14-200.fc35 -> 5.15.16-200.fc35
  kernel-modules-extra 5.15.14-200.fc35 -> 5.15.16-200.fc35
  libibverbs 38.0-1.fc35 -> 38.1-2.fc35
  libical 3.0.12-1.fc35 -> 3.0.13-1.fc35
  libical-glib 3.0.12-1.fc35 -> 3.0.13-1.fc35
  libmetalink 0.1.3-15.fc35 -> 0.1.3-24.fc35
  libsane-hpaio 3.21.2-15.fc35 -> 3.21.12-1.fc35
  libwacom 1.12-1.fc35 -> 1.12.1-1.fc35
  libwacom-data 1.12-1.fc35 -> 1.12.1-1.fc35
  libwebp 1.2.1-3.fc35 -> 1.2.2-1.fc35
  libxcrypt 4.4.27-1.fc35 -> 4.4.27-2.fc35
  libxcrypt-compat 4.4.27-1.fc35 -> 4.4.27-2.fc35
  libxcrypt-devel 4.4.27-1.fc35 -> 4.4.27-2.fc35
  libzstd 1.5.1-6.fc35 -> 1.5.2-1.fc35
  mesa-dri-drivers 21.3.3-1.fc35 -> 21.3.4-3.fc35
  mesa-filesystem 21.3.3-1.fc35 -> 21.3.4-3.fc35
  mesa-libEGL 21.3.3-1.fc35 -> 21.3.4-3.fc35
  mesa-libGL 21.3.3-1.fc35 -> 21.3.4-3.fc35
  mesa-libgbm 21.3.3-1.fc35 -> 21.3.4-3.fc35
  mesa-libglapi 21.3.3-1.fc35 -> 21.3.4-3.fc35
  mesa-libxatracker 21.3.3-1.fc35 -> 21.3.4-3.fc35
  mesa-vulkan-drivers 21.3.3-1.fc35 -> 21.3.4-3.fc35
  mtr 2:0.94-4.fc35 -> 2:0.95-1.fc35
  pam 1.5.2-5.fc35 -> 1.5.2-7.fc35
  pcre2 10.37-4.fc35 -> 10.39-1.fc35
  pcre2-syntax 10.37-4.fc35 -> 10.39-1.fc35
  pcre2-utf16 10.37-4.fc35 -> 10.39-1.fc35
  pcre2-utf32 10.37-4.fc35 -> 10.39-1.fc35
  pipewire 0.3.43-1.fc35 -> 0.3.43-3.fc35
  pipewire-alsa 0.3.43-1.fc35 -> 0.3.43-3.fc35
  pipewire-gstreamer 0.3.43-1.fc35 -> 0.3.43-3.fc35
  pipewire-jack-audio-connection-kit 0.3.43-1.fc35 -> 0.3.43-3.fc35
  pipewire-libs 0.3.43-1.fc35 -> 0.3.43-3.fc35
  pipewire-pulseaudio 0.3.43-1.fc35 -> 0.3.43-3.fc35
  pipewire-utils 0.3.43-1.fc35 -> 0.3.43-3.fc35
  python-unversioned-command 3.10.1-2.fc35 -> 3.10.2-1.fc35
  python3 3.10.1-2.fc35 -> 3.10.2-1.fc35
  python3-audit 3.0.6-1.fc35 -> 3.0.7-1.fc35
  python3-libs 3.10.1-2.fc35 -> 3.10.2-1.fc35
  python3-rpm 4.17.0-1.fc35 -> 4.17.0-3.fc35
  qgnomeplatform 0.8.3-2.fc35 -> 0.8.4-1.fc35
  qt5-qtwayland 5.15.2-15.fc35 -> 5.15.2-17.fc35
  rpm 4.17.0-1.fc35 -> 4.17.0-3.fc35
  rpm-build-libs 4.17.0-1.fc35 -> 4.17.0-3.fc35
  rpm-libs 4.17.0-1.fc35 -> 4.17.0-3.fc35
  rpm-plugin-selinux 4.17.0-1.fc35 -> 4.17.0-3.fc35
  rpm-sign-libs 4.17.0-1.fc35 -> 4.17.0-3.fc35
  sane-backends 1.0.32-5.fc35 -> 1.1.1-1.fc35
  sane-backends-drivers-cameras 1.0.32-5.fc35 -> 1.1.1-1.fc35
  sane-backends-drivers-scanners 1.0.32-5.fc35 -> 1.1.1-1.fc35
  sane-backends-libs 1.0.32-5.fc35 -> 1.1.1-1.fc35
  selinux-policy 35.8-1.fc35 -> 35.11-1.fc35
  selinux-policy-targeted 35.8-1.fc35 -> 35.11-1.fc35
  shadow-utils 2:4.9-8.fc35 -> 2:4.9-9.fc35
  shadow-utils-subid 2:4.9-8.fc35 -> 2:4.9-9.fc35
  texlive-lib 9:20210325-40.fc35 -> 9:20210325-44.fc35
  thermald 2.4.6-3.fc35 -> 2.4.8-1.fc35
  virtualbox-guest-additions 6.1.30-1.fc35 -> 6.1.32-1.fc35
  webkit2gtk3 2.34.1-2.fc35 -> 2.34.4-2.fc35
  webkit2gtk3-jsc 2.34.1-2.fc35 -> 2.34.4-2.fc35
  wireplumber 0.4.5-3.fc35 -> 0.4.7-2.fc35
  wireplumber-libs 0.4.5-3.fc35 -> 0.4.7-2.fc35
Removed:
  chkconfig-1.19-1.fc35.x86_64
  initscripts-10.11-1.fc35.x86_64
Added:
  avahi-tools-0.8-14.fc35.x86_64
  cups-filters-braille-1.28.11-1.fc35.x86_64

 

adam-edwards
Listener

Just stopping by to add some representation to this issue. A fix would be lovely here. Haven't yet tried the workaround mentioned above, but my current workaround has been to talk people out of using zoom, and do Slack and Teams meetings instead 😉 though I'd like to get back to Zoom when it's an option.

 

@YaBoiB thanks for keeping an eye on this.

ReeceHart
Listener

I share all of the comments above about Zoom's handling of support for various flavors of Linux. IMO, Zoom's Linux support has always been pretty mediocre.

 

As a result, I switched to Google Meet wherever I could. Although Google Meet had performance issues early on, in the last six months or so it's become at least as good as Zoom, and screen sharing is more versatile (Chrome tab, any window, or entire screen). Not requiring a software installation is terrific. And, if you use Google calendar, the integration between them is extremely convenient. The biggest problems I've faced are 1) resistance to change, 2) screen sharing permissions often catch people unaware.

 

Microsoft Teams is also really good.

 

I'm not trying to spite Zoom. But I am saying that Zoom's unwillingness or inability to adapt to web video and to fix its broken sharing on Linux is quickly causing it to become a legacy product for me.

YaBoiB
Community Champion | Zoom Employee
Community Champion | Zoom Employee

Hello, 

 

 Let me clarify that Fedora 36 has not yet been officially released to date. We did testing, and this is working on Xorg. This issue is on our Roadmap for a future release and will be sorted out soon. My apologies for the confusion to anyone in this thread. That was not my intention. I intend to assist in finding a solution for all users in this thread and any users experiencing this issue. Again, I truly appreciate everyone who has replied to this thread and those who have helped in providing logs and experiences for this case. It is still a top priority for our team, and we thank you all for your patience while we sort this out. 

If this response was helpful for you, please do not forget to click on the accepted solutions button!

I am confused as to why you are using this thread to bring up XOrg support in Fedora 36 when the issue at hand in Wayland support... can you please clarify?

I don't think the statement applies to F36, specifically.  It means that, if you use Xorg instead of Wayland, then Zoom screen sharing works.  This is legacy behavior that "always" worked.  So, as a one of the two workarounds suggested by various posts in this thread for the current issue, you can switch to Xorg-based desktop (or GNOME on Xorg) to get screen sharing to work.  I know, this thread is pretty long.

Yeah I'm a bit unclear why we should be excited about Zoom supporting legacy graphics on an unreleased future system.

 

Especially when it would somewhat imply Zoom aren't making use of the appropriate XDG APIs, as they are agnostic and so it would work on Wayland not just X11 — even if, for some reason, need a bleeding-edge system.

 

Hopefully this is just a miscommunication and will all be cleared up shortly


@YaBoiB wrote:

The latest Zoom Version is now working on Fedora 36. […] Please install the latest Zoom Version for Fedora 36 and provide your feedback to this thread. 


These two messages are completely opposite.

 


@YaBoiB wrote:

We did testing, and this is working on Xorg. This issue is on our Roadmap for a future release and will be sorted out soon. 

The team should stop testing on a configuration that is not the default for the operating system in question. Like @Gene-Puppet and @zbrown said, it was already working on Xorg. That's like saying "This is fixed, we tested on MacOS". Why would you say this?

 

I have attached a screenshot of how the newly released Zoom operates. When I plugged in my microphone and Zoom detected it, the messages continued to flood my screen, preventing me from interacting with Zoom so I could not even exit gracefully.

Notice how it was said that the latest Zoom release was "working" on Fedora 36 (which isn't even out yet, but whatever). There is apparently a discrepancy between how Zoom defines "working" and how users define it. According to Zoom, the release is "working" if the program launches, but it is obviously not working from the users' perspective because we are still missing a key feature.

YaBoiB
Community Champion | Zoom Employee
Community Champion | Zoom Employee

Hello,
 Please understand that the information I am providing is coming from the Engineers directly, so it is not uncommon for them to possibly have a beta version of Fedora 36. I believe that you all would agree on this point. To note: I am not the Engineer testing this. I am simply acting as a liaison to attempt to solve this issue for the good of the customers of Zoom. That is my sole goal. I truly appreciate the positive feedback on this issue and the help that many have volunteered. It has not gone unnoticed. As soon as I have more information from the team, I will post it here. 

If this response was helpful for you, please do not forget to click on the accepted solutions button!


@YaBoiB wrote:
it is not uncommon for them to possibly have a beta version of Fedora 36.

I agree, I did not say anything negative about testing an early version of Fedora—I think that's a good thing and was recommending this type of testing earlier in discussion. If you read my message, I only point out Xorg:

 


@es-kyra wrote:

Like @Gene-Puppet and @zbrown said, it was already working on Xorg. That's like saying "This is fixed, we tested on MacOS". Why would you say this?


This is the main reason we are confused. Thank you for doing your best to communicate with the engineering team.


@YaBoiB wrote:

not uncommon for them to possibly have a beta version of Fedora 36. I believe that you all would agree on this point


Hate to be petty, but no not really 🙂

 

Fedora isn't Zoom's product, furthermore Fedora 36 doesn't hit beta for another month and doesn't even exist as a branch yet. Until the 8th of February your engineers simply can't be using Fedora 36 beta-or-otherwise. Of course they are probably referring to Fedora Rawhide, but that is somewhat distinct from "Fedora 36" and I'm not sure why Fedora 35 is insufficient in the first place.

 

Unfortunately your last few responses have been more confusing than "helpful", but thank you for your continued efforts. Hopefully "the team" have something more useful to say soon.

feaneron
Listener

Hi @YaBoiB 

 

My name is Georges Stavracas, and I'm one of the maintainers of GNOME Shell, xdg-desktop-portal, among others. It seems to me that the developers at Zoom are aware of this issue, and a solution seems to be on its way. This is exciting news.

 

However, I do notice that you reported that it "[...] is now working on Fedora 36". This concerns me. I do not know what checks are performed by the Zoom client, but based on this statement, I can make a few educated guesses, and these checks are probably wrong.

 

I'd like to offer help to your development team on this front. You can contact me, publicly or privately, under NDAs or not, under contracts or not, using the email that this account is registered with. I would absolutely love to help making Zoom work on Wayland, and potentially also Flatpak, like I did with other software like OBS Studio.

 

I have code under Public Domain that exemplifies the usage of the Screensharing portal. This code can be copied into proprietary applications, your developers should feel free to use it.

 

Please let me know what you think.

 

With respect,

Georges

Hey @feaneron, the Zoom client is written in C++ using Qt 5. Do you have any examples that use that instead of GTK 4 and C?

I do not. The relevant bits of the mentioned code (connecting to a PipeWire remote from a file descriptor, creating a PipeWire stream from a node, etc) are mostly independent of the toolkit though. OBS Studio implements the same routines purely in OpenGL, for example.

Yes, we have already got this solution and are integrating it into zoom.  but the specific release version has not been determined yet.

Thanks

Wonderful. As mentioned, feel free to reach out if you have any questions or problems interacting with the ScreenCast portal - some of the APIs there can be slightly tricky to get right; see referenced code above. If you find bugs in the portal, please report them at github.com/flatpak/xdg-desktop-portal.  

 

Best regards

YaBoiB
Community Champion | Zoom Employee
Community Champion | Zoom Employee

Hello @feaneron,

 

We are aware of the issue and aware of the solution, so although we appreciate your offer for help, our Engineers have it under control at this time. They plan on implementing the solution in a future version of Zoom. I do not have that version number to date. I will update everyone here when I have that information. Thank you for being so patient while we continue to work on this. 

If this response was helpful for you, please do not forget to click on the accepted solutions button!

Thank you, Brandon. Let's keep an eye on the next releases then. You've been maintaining a good, positive environment in this thread, that's appreciated, thank you for that.