Screen share on Wayland does not work about webcord

[genevieve-me]

What window manager or DE? Do you have the appropriate XDG Desktop Portal enabled? Are you using pipewire?

[Merikrotti]

Same issue, though infinite loading after selecting window/screen. DE KDE Plasma and XDG is KDE. Debian 12.

It did work fine before, though for a month now hasn't worked. Not using xwayland video bridge either.

Didn't bother making an issue, since I thought it was just me. With X11 it works.

EDIT:
Tried Flatpak versions, same issue. Though, now after starting the stream multiple times it started working. That's weird?
Before, when it worked properly, the portal popped up twice. Now only once, maybe that's related.

Does anyone have any instructions where I can find the logs for this? I would be happy to post them.

[lluisaliano]

I am having the same issue. It used to work a few weeks ago but now it isn't, but after trying some times I can get it to work.

[Merikrotti]

I have isolated it to never working if you watch someone else's stream and start yours. For whatever reason, the flatpak versions don't work no matter what I've tried, the deb version does. Otherwise, starting the stream twice does the trick.

Now the only issue I have, is the stream blasting my ears randomly for around 0.1 seconds that is clearly my own audio.

[delacemane]

same issue no matter if using AppImage or flatpak. void linux, hyprland, xdg-desktop-portal-hyprland, pipewire and wireplumber are running, discord website screen share works fine. didnt managed to get it work.(sorry if bad english)

[snoopcatt]

What window manager or DE? Do you have the appropriate XDG Desktop Portal enabled? Are you using pipewire?

I am using GNOME4, XDG Desktop Portal enabled, permissions granted, and yes, I am using pipewire.
After downgrading to version 4.6.1, everything just works with the very same configuration. So it is definitely a bug.
Unfortunately, Webcord 4.6.1 does not support selecting streaming quality, but maybe I'll be able to backport 1080p support myself, idk.

upd: maybe this is a bug in new version of bundled Electron itself, because it stopped working after devs bumped Electron version to v28 (webcord v4.7+), but I can't test it because Webcord is the only one Electron application in my system.

upd2: since newer official versions of Discord has the very same issue with «infinite loading», I assume it's upstream bug. a big request to those who care: please, report bug to Electron upstream, if it is still not fixed/not exists.

[gonedownfr]

[Setup: ArchLinux + Hyprland + Pipewire/Wireplumber + xdg-desktop-portal-hyprland]

same issue here, but as a workaround for everyone that needs to:

You can use OBS as a virtual camera while selecting your screen/window as a source, and instead of screen share on Webcord/Discord, just select the OBS camera.
If the Virtual camera button is not available in OBS, it means you need to install v4l2loopback-dkms. This is a kernel module needed to create virtual video devices. AND you need the corrisponding kernel headers: e.g. if you have linux kernel you need linux-headers (dkms package needed too, but that should be auto installed i think).

On launch OBS will automatically try to load the module and the button should appear, if not, load it yourself. (and keep in mind kernel modules will be unloaded on reboot so if you want to make it permanent ykwtd)

[talleyhoe]

Swapped my setup over to sway from i3 recently. Trying to only go with wayland native solutions. I also never had much success with discord or webcord screen sharing under X, but that's besides the point.

Problem: When I click screen share nothing happens in the gui

Launched Webcord via terminal and got back this error

[14885:0505/045435.953991:ERROR:shared_x_display.cc(39)] Unable to open display
[14885:0505/045435.955745:ERROR:screen_capture_portal_interface.cc(48)] Failed to request session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
[14885:0505/045435.955761:ERROR:base_capturer_pipewire.cc(81)] ScreenCastPortal failed: 3
(node:14885) UnhandledPromiseRejectionWarning: Failed to get sources.
    at emitUnhandledRejectionWarning (node:internal/process/promises:203:15)
    at processPromiseRejections (node:internal/process/promises:297:13)
    at processTicksAndRejections (node:internal/process/task_queues:96:32)
(node:14885) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either bythrowing inside of an async function without a catch block, or by rejecting a promise which was not handledwith .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 4)

Running this with environment variable ELECTRON_OZONE_PLATFORM_HINT=auto
Yes my user is part of the video group and I'm running polkit

[SpacingBat3]

I think this issue is a duplicate of #513, there are mixed reports on how PipeWire screen share I suppose...
For me, even the whole DE or GUI crashed before, but I haven't checked if it works differently after Chromium/Electron update (I don't use Wayland daily).
For many errors, I would ensure if proper service and package is installed and working. Others I might not be able to fix on my side, those happen in Chromium during invocation of the portal so the one should check if that's handled correctly there if it happens only with Chromium-based software.

[talleyhoe]

I agree, do we have a version/build that we know works on wayland? My intuition tells me this might be fixable with permissions or an additional dependency

(don't want to clog up the other thread)

[SpacingBat3]

From what people have been reporting to me in general, screen share just works fine for some as long as they have proper portals configured properly (i.e. packages providing them installed, with proper (?) service for portals running in the background). Unless I will repro it, I doubt I can participate in any way at fixing it at all, or even pointing out for which Electron version or Chromium build it may work.

[talleyhoe]

Yup, finally got around to debugging this. It was an xdg-portal config error on my part (sorry)

For Others: There's multiple environment variables. See these resources
https://wiki.archlinux.org/title/XDG_Desktop_Portal
https://gitlab.archlinux.org/archlinux/packaging/packages/sway/-/blob/main/50-systemd-user.conf?ref_type=heads