Closed David96 closed 1 year ago
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, thanks for your help!
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 (force_mod_linear
should do the same).
If you provide a TRACE
log of xdpw, this might help to see how the negotiaion is happening and which allocation codepath we are hitting.
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 What I find suspicious is that all pipewire events seem to have a size of 9, I would have expected this property to tell the buffer size which should be slightly bigger.
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. Glancing at your log, there is no negotiation happening. Is this xdpw from master, or did you path a force implicit into it?
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
pw-cli enum-params <port id> 3
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: shm_only_clients.txt
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.
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)...
I can reproduce that.
Prop: key Spa:Pod:Object:Param:Format:Video:modifier (131074), flags 00000008
This is wrong. The flag should be 18 (hex value): (1<<4) is DONT_FIXATE
and (1<<3) MANDATORY
. The DONT_FIXATE
flag is missing.
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 https://github.com/emersion/xdg-desktop-portal-wlr/commit/5799adeb57c8ccefaa21d483b9a027095c893b6d. 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 :sweat_smile:
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 :facepalm:
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 :facepalm:
Nice!
... sigh
Feel free to use https://github.com/emersion/xdg-desktop-portal-wlr/pull/156 with cropmode=pipewire
Feel free to use #156 with
cropmode=pipewire
I confirm that it works (Zoom Flatpak) with the PR applied and the following config:
[screencast]
chooser_type = none
cropmode = pipewire
region = 0,0:1920x1080
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. Configuration, I've tried different combinations, but nothing changed.
[screencast]
chooser_type = none
region = 0,0:2256x1504
cropmode = pipewire
xdg-desktop-portal-wlr -r -l DEBUG
logs:
2022/08/16 18:16:27 [INFO] - dbus: create session method invoked
2022/08/16 18:16:27 [INFO] - dbus: request_handle: /org/freedesktop/portal/desktop/request/1_169/zoomcast10
2022/08/16 18:16:27 [INFO] - dbus: session_handle: /org/freedesktop/portal/desktop/session/1_169/zoomcast4
2022/08/16 18:16:27 [INFO] - dbus: app_id: us.zoom.Zoom
2022/08/16 18:16:27 [INFO] - dbus: select sources method invoked
2022/08/16 18:16:27 [INFO] - dbus: request_handle: /org/freedesktop/portal/desktop/request/1_169/zoomcast11
2022/08/16 18:16:27 [INFO] - dbus: session_handle: /org/freedesktop/portal/desktop/session/1_169/zoomcast4
2022/08/16 18:16:27 [INFO] - dbus: app_id: us.zoom.Zoom
2022/08/16 18:16:27 [INFO] - dbus: option types:3
2022/08/16 18:16:27 [INFO] - dbus: option multiple: 0
2022/08/16 18:16:27 [INFO] - dbus: option cursor_mode:2
2022/08/16 18:16:27 [DEBUG] - dbus: select sources: found matching session /org/freedesktop/portal/desktop/session/1_169/zoomcast4
2022/08/16 18:16:27 [INFO] - wlroots: capturable output: Unknown model: 0x095F: id: 41 name: eDP-1
2022/08/16 18:16:27 [INFO] - xdpw: screencast instance 0x55645dba96e0 has 1 references
2022/08/16 18:16:27 [INFO] - xdpw: 1 active screencast instances
2022/08/16 18:16:27 [INFO] - wlroots: output: eDP-1
2022/08/16 18:16:27 [INFO] - dbus: start method invoked
2022/08/16 18:16:27 [INFO] - dbus: request_handle: /org/freedesktop/portal/desktop/request/1_169/zoomcast12
2022/08/16 18:16:27 [INFO] - dbus: session_handle: /org/freedesktop/portal/desktop/session/1_169/zoomcast4
2022/08/16 18:16:27 [INFO] - dbus: app_id: us.zoom.Zoom
2022/08/16 18:16:27 [INFO] - dbus: parent_window:
2022/08/16 18:16:27 [DEBUG] - dbus: start: found matching session /org/freedesktop/portal/desktop/session/1_169/zoomcast4
2022/08/16 18:16:27 [INFO] - wlroots: num_modififiers 7
2022/08/16 18:16:27 [INFO] - pipewire: stream state changed to "connecting"
2022/08/16 18:16:27 [INFO] - pipewire: node id is -1
2022/08/16 18:16:27 [INFO] - pipewire: stream state changed to "paused"
2022/08/16 18:16:27 [INFO] - pipewire: node id is 63
2022/08/16 18:16:27 [DEBUG] - dbus: start: returning node 63
2022/08/16 18:16:27 [DEBUG] - pipewire: Format negotiated:
2022/08/16 18:16:27 [DEBUG] - pipewire: buffer_type: 1 (8)
2022/08/16 18:16:27 [DEBUG] - pipewire: format: 8
2022/08/16 18:16:27 [DEBUG] - pipewire: modifier: 72057594037927935
2022/08/16 18:16:27 [DEBUG] - pipewire: size: (2256, 1504)
2022/08/16 18:16:27 [DEBUG] - pipewire: max_framerate: (59 / 1)
2022/08/16 18:16:27 [DEBUG] - pipewire: add buffer event handle
2022/08/16 18:16:27 [DEBUG] - pipewire: add buffer event handle
2022/08/16 18:16:27 [INFO] - pipewire: stream state changed to "streaming"
2022/08/16 18:16:27 [INFO] - pipewire: node id is 63
2022/08/16 18:16:32 [DEBUG] - fps_limit: average FPS in the last 5.14 seconds: 18.09
2022/08/16 18:16:36 [INFO] - pipewire: stream state changed to "paused"
2022/08/16 18:16:36 [INFO] - pipewire: node id is 63
2022/08/16 18:16:36 [INFO] - dbus: session closed
2022/08/16 18:16:36 [DEBUG] - dbus: destroying session 0x55645dba6cc0
2022/08/16 18:16:36 [DEBUG] - xdpw: screencast instance 0x55645dba96e0 now has 0 references
2022/08/16 18:16:36 [DEBUG] - xdpw: destroying cast instance
2022/08/16 18:16:36 [DEBUG] - pipewire: destroying stream
2022/08/16 18:16:36 [DEBUG] - pipewire: remove buffer event handle
2022/08/16 18:16:36 [DEBUG] - pipewire: remove buffer event handle
2022/08/16 18:16:36 [INFO] - pipewire: stream state changed to "unconnected"
2022/08/16 18:16:36 [INFO] - pipewire: node id is -1
Have you tried setting force_mod_linear?
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)? Btw. you only have on GPU right?
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:
interface: 'zxdg_output_manager_v1', version: 3, name: 8
xdg_output_v1
output: 42
name: 'DP-1'
description: 'Dell Inc. DELL U2717D 67YGV67BBUNL (DP-1 via DP)'
logical_x: 2256, logical_y: 0
logical_width: 2560, logical_height: 1440
xdg_output_v1
output: 41
name: 'eDP-1'
description: 'Unknown 0x095F 0x00000000 (eDP-1)'
logical_x: 0, logical_y: 0
logical_width: 2256, logical_height: 1504
Correct, only one gpu, which is a Intel Xe:
❯ lspci | grep -i vga
00:02.0 VGA compatible controller: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01)
Thanks for answering, I guess we can't expect much from zoom :)
Ok, I was setting force_mod_linear = true
instead of force_mod_linear = 1
:facepalm:
Setting force_mod_linear correctly solves the issue for me!
Edit.: To be clearer, both methods work for me with force_mod_linear = 1
in the config.
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'll try to reach out to other portal developers to write some documentation on what PipeWire features are seen as mandatory and which should be optional.
I had the same stride issue which I was also able to fix with force_mod_linear. Zoom still seems to only update at about 5 fps or something which is maddening, and there is a mini "display" which shows only the top left section of the screen, and it seems to not handle the orientation of a vertical monitor correctly... but it works! I'll dig further into the docs and find some workarounds for anything I can, but would like to thank everyone in this issue for the help.
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.
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