Zoomtopia is here. Unlock the transformative power of generative AI, helping you connect, collaborate, and Work Happy with AI Companion.
Register nowEmpowering you to increase productivity, improve team effectiveness, and enhance skills.
Learn moreKeep your Zoom app up to date to access the latest features.
Download Center Download the Zoom appDownload hi-res images and animations to elevate your next Zoom meeting.
Browse Backgrounds Zoom Virtual BackgroundsEmpowering you to increase productivity, improve team effectiveness, and enhance skills.
Zoom AI Companion2021-11-04 09:57 AM - edited 2021-11-07 12:25 PM
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.
Solved! Go to Solution.
2022-07-14 08:51 AM - edited 2022-08-04 02:16 AM
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!
2021-12-28 10:54 PM
I just tried screen shared from vivaldi web browser(Chrome based) and it works! For now can be used as a ugly and annoying alternative. 😡
2021-12-30 10:11 AM
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.
2022-01-03 03:40 PM
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
2022-01-20 09:24 AM
Do you have any updates on wayland and zoom screensharing compatibility ?
2022-01-06 08:42 AM
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
2022-01-06 09:19 AM
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.
2022-01-09 08:35 AM
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 🙂
2022-03-23 05:07 AM
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
2022-03-23 05:41 AM
Very well stated!
2022-03-23 09:43 AM
@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.
2022-01-12 01:50 AM
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.
2022-01-13 07:49 AM
Please fix it Zoom!
2022-01-14 04:14 AM
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.
2022-01-19 01:08 PM
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.
2022-01-20 03:19 PM
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.
2022-01-19 01:20 PM - edited 2022-01-19 01:21 PM
Sorry, duplicate reply...
2022-01-21 01:30 PM - edited 2022-01-21 01:42 PM
Chiming in to report same issues with Slackware x86 and x64 Current and OpenSUSE 😞 - please add wayland support! Thanks
2022-01-22 04:34 AM
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.
2022-01-22 05:35 AM
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.
2022-01-22 03:27 PM
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.
2022-01-24 05:06 PM
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
2022-01-24 05:09 PM
I note that release has been delayed, an optimist could derive something from that I suppose
2022-01-25 07:21 AM - edited 2022-01-25 07:52 AM
@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
2022-01-24 08:13 AM
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.
2022-01-24 11:29 AM - edited 2022-01-24 05:20 PM
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.
2022-01-25 09:57 AM
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.
2022-01-25 12:38 PM
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?
2022-01-25 01:22 PM
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.
2022-01-25 01:36 PM
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
2022-01-28 04:15 AM - edited 2022-01-28 08:23 AM
@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.
2022-01-28 07:55 AM
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.
2022-01-28 08:41 AM
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.
2022-01-28 11:20 AM
@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.
2022-01-28 12:42 PM
@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.
2022-02-01 03:06 PM
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
2022-02-01 06:34 PM
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?
2022-02-01 06:52 PM
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.
2022-02-08 05:45 PM
Yes, we have already got this solution and are integrating it into zoom. but the specific release version has not been determined yet.
Thanks
2022-02-08 06:22 PM
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
2022-02-08 06:50 AM
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.