-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get Zoom to work #226
Comments
Hi, DmaBuf trasnport works by negotiating a common format-modifier pair. xdpw shouldn't use a modifier which was not announced by the zoom client. To check this please provide a pw-dump after the screencast was initialized (you may want to remove the info of all unrelated nodes, I need just the Node and the Port information of xdpw and zoom). Explicit modifiers are always better since we can't give any guarantee that the implicit one will work, but clients have to announce their capabilities correctly. In the meantime you could use firefox, or a develpment version of chromium, since a current bug was fixed and it will be in the 105 release. |
Hey, I think this is the relevant part of the dump:
Sadly I can't use a Browser since my university disabled the web client for some ominous security reasons… (which is quite ironic considering all the RCE bugs that were found in the Zoom client in the past) Edit: This is what a pw-dump when using Gnome (Zoom is working there) looks like:
I don't really see a lot of differences, maybe my initial guess of it being an issue with modifiers being implemented wrongly by Zoom was wrong. Btw. I'm pretty sure it's not a bug on your side, I'm just trying to get it to work somehow since Zoom is not exactly known for fixing this kind of stuff quickly... |
The difference of xdpw and gnome should be that gnome allocates implicit modifiers as linear ( If you provide a |
I already tried with and without force_mod_linear. To make things even stranger, now Zoom suddenly calls gbm_bo_import with GBM_BO_IMPORT_FD instead of GBM_BO_IMPORT_FD_MODIFIER therefore the theory of it hitting the ENOSYS of gbm being the issue doesn't seem to hold. I really don't know what changed to cause this behavior. The trace log can be found here: http://ix.io/449t Edit: ok, I know what changed: it depends on whether I use the Vulkan renderer of Sway or not. |
Please use the gl renderer for now, vulkan doesn't support implicit modifiers at all. |
This is from master, without any added patches. Wouldn't surprise me if Zoom just skips any format negotiation and simply doesn't work if it doesn't like the chosen format... |
Ok, sadly pw-dump doesn't print the flags attached to EnumFormat params, so please look for the id of the zoom Port in pw-dump and send the output of
Btw. are you using an Nvidia GPU? KDE folks noticed that implicit modifiers had some issues there. |
In the meantime you can try this patch: |
Oh maybe I should have mentioned: Zoom crashes when using SHM buffers (after xdg-desktop-portal shows a lot of pipewire out of buffers errors)... The output of enum-params:
I'm using AMD Vega 10 graphics, so no Nvidia here. And on Gnome Zoom works, so basically what I'm trying to do is figuring out what difference makes Zoom work on one and not the other. |
I can reproduce that.
This is wrong. The flag should be 18 (hex value): (1<<4) is I'm scared of what they do to have the shm transport crash... anyway to debug this further source code would be nice (probably a quick fix) ... sigh I remember that there was some version with portal support, which worked, maybe you can test different versions. |
Is there maybe some quick and dirty way to work around this issue? |
Try going back to this commit 5799ade. It's before explicit modifiers are implemented. |
If you want to go the "hacky" way: Use obs and v4l2-loopback. |
Sadly going back to before the explicit modifiers still doesn't work :/ The obs & v4l2-loopback was what I was doing the whole time, I was just very excited to be finally able to use the "right" way of screensharing 😅 Anyway, thanks a lot for your help! Not sure whether this issue should stay opened for others to see? |
Whoop whoop, I figured it out 🤦 The solution really is as stupid as it gets: Gnome sets the VideoCrop Metadata when sharing the whole screen. I bet you can guess where this is going… Apparently, if this property is not set, Zoom just shares nothing. Adding SPA_META_VideoCrop to the buffer and setting the size of the screen fixes screensharing 🤦 |
Nice! ... sigh |
Feel free to use #156 with |
I confirm that it works (Zoom Flatpak) with the PR applied and the following config:
Is there any performance loss compared to David96's workaround? |
I've tried both solutions and it works on my external display. But on my laptop display the image looks like bellow. OBS works just fine with both displays.
|
Have you tried setting force_mod_linear? |
Yep, this is one of combinations I've tried but the behavior is the same. |
Hmm... this looks like a stride mismatch. Chromium 104 has the same issue for me (Will be fixed in 105). It's interesting, that this works for your external monitor but not your internal one. Are you sure the crop region is correct for your internal display (and the used resolution from the compositor)? If it works in OBS, I'm sorry but I can't know what's causing the issue inside Zoom. |
Yep, you're right, I had a smaller resolution still in config file when I took the screenshot by mistake, but the behavior is the same when using the display resolution. One thing I realized is that I was using a 1.5 scale, but it seems the behavior is the same with 1.0 scale:
Correct, only one gpu, which is a Intel Xe:
Thanks for answering, I guess we can't expect much from zoom :) |
Ok, I was setting Edit.: To be clearer, both methods work for me with |
Fantastic! Since the issue is now elaborated and known, I would close this and pin it. If sth. new happens please reopen it again. |
I had the same stride issue which I was also able to fix with force_mod_linear. |
FYI: while the workarounds worked for me, I stopped using the app because it started crashing and having other issues, it turns out the zoom web app got a lot better (on chrome), so I'm using that instead. |
Is there any hope of getting zoom to work with xdg-desktop-portal-wlr? cropmode and region are not valid anymore... (there is also a typo in "section")
|
Found a workaround: https://github.com/David96/xdg-desktop-portal-wlr/commits/zoom-fix
Hey,
I'm not sure whether what I'm asking for makes sense at all since I can't claim to understand the whole DMABuf with modifiers/modifierless situation. So let me explain quickly my situation:
Since the last release Zoom kind of supports the Screencast API but sadly, nothing arrives at the screens of the participants when running with xdg-desktop-portal-wlr. I was able to confirm that Zoom runs into a ENOSYS when calling gbm_bo_import, probably this one: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gbm/backends/dri/gbm_dri.c#L1071 Now I don't quite understand how and why this happens but I think forcing it to modifierless DMABufs would result in a different code path without this error?
I played around a bit with
build_modifierlist
in pipewire_screencast.c but I'm not sure whether I actually got it to use a modifierless format.Is there any possibility to add something similar to force_mod_linear, like force_modifierless?
Another reason I think the issue is related to modifiers is that iiuc gnome uses modifierless DMABufs and there Zoom seems to work correctly.
Best regards
The text was updated successfully, but these errors were encountered: