Slack Screensharing (Gnome-Wayland)

SebTM · November 16, 2023, 5:16pm

Hey,

I tried everything that came to my mind / combinations but I can’t get Slack sharing the entire screen working. Initial status:

I figured out, Slack runs by default in xwayland. I tested this using xlsclients. I can see in the selector:

“Entire Screen” - which is just a black square and if I share it even the cursor which is displayed is not moving
Other Programs like “1Password” or “codium” with preview and sharing them works

I started with:

nixos-23.05, with pulseaudio (because it’s the default with gnome enabled by the nixos-module)
switched to pipewire
read in a github-issue that it would work on unstable so rebuild my system on nixpkgs-unstable
tried updating slack (by overlay verifying it via “Help → About Slack”)
running different combinations of NIXOS_OZONE_WL or --ozone-platform=wayland, --enable-features=UseOzonePlatform, --ozone-platform-hint=auto, --enable-features=WaylandWindowDecorations, --enable-features=WebRTCPipeWireCapturer (or combination of features)
tried running xdg.portal.wlr.enable under gnome, which seems like not compatible at all

Observation: Starting Slack itself under wayland (so it does not show up under xlsclients anymore when running) leads to only full-screen seeing displayed in the selection but still just a black screen.

Screen-sharing in Firefox/Chrome works both (I would say from the beginning but I’m uncertain when I tested it the first time, at least after pipewire switch I would suspect) using gUM Test Page for testing.

Appreciate any help/ideas/recommendations (except stop using slack which is sadly not my choice )

APCodes · November 16, 2023, 6:11pm

Okay, this might just be a tricky thing with Wayland + Xwayland. I’ve had these issues myself for quite some time with several apps. It’d be really nice finding a durable solution.

So the Slack client (which I don’t use on a regular basis) works in XWayland. As long as this the case you can expect it to be nicely interoperable with other XWayland apps, but not with native Wayland ones. Neither with full desktop sharing. That has just been my experience.

Now I don’t qute understand why you run Pulseaudio instead of Pipewire.

Just searching around a little bit I found that there might be a potential workaround for this using Pipewire:

So basically you have to pass the --enable-features=WebRTCPipeWireCapturer %U to the Slack client when launching it. Not quite sure what the %U means though…

I’d be happy to know back from you if this actually works. And maybe it is also something that works with other apps? I suppose the --enable-features=WebRTCPipeWireCapturer might just be passed to any app build with electron.

SebTM · November 16, 2023, 7:18pm

Hey, sorry was just a mistake when I wrote the steps down (corrected now) - I switched to pipewire as first action when discovered gnome came with pulseaudio. (I switched from sway to gnome recently because of multiple permanent issues - e.g. docking - and moved from pulseaudio to pipewire when switching from x11/i3 to wayland/sway)

As you can see in the further steps the suggested solution was one of the multiple I tested (on 23.05 and unstable). Additionally I missed one observation in my initial post:

All Apps where screensharing is working (like chromium, firefox) trigger the sharing dialog (I suspect is part of xdg-desktop-portal-gnome) to select window/screen:

which slack does not. The more I think about it, maybe they only support/have a custom implementation for xdg-desktop-portal-wlr/wlroot?

I understand that sharing both native wayland-apps and xwayland-apps without some extra helper/software¹ will not work out. My idea is more getting back the previous status-quo on sway where I could share my full screen which had the advantage (at least how I remember it) that it was irrelevant if the apps were native wayland or running in xwayland.

github.com

luispabon/sway-dotfiles/blob/1a255c86a65e9f3059bac0eea137875b22a5e787/scripts/sway-screenshare.sh

#!/usr/bin/env bash
set -x

geometry(){
	windowGeometries=$(
		# `height - 1` is there because of: https://github.com/ammen99/wf-recorder/pull/56 (I could remove it if it's merged, maybe)
		swaymsg -t get_workspaces -r | jq -r '.[] | select(.focused) | .rect | "\(.x),\(.y) \(.width)x\(.height - 1)"'; \
		swaymsg -t get_outputs -r | jq -r '.[] | select(.active) | .rect | "\(.x),\(.y) \(.width)x\(.height)"'
	)
	geometry=$(slurp -b "#45858820" -c "#45858880" -w 3 -d <<< "$windowGeometries") || exit $?
	echo $geometry
}

# Ensure we're not using the wayland backend on SDL
unset SDL_VIDEODRIVER

geometry=$(geometry) || exit $?
wf-recorder -c rawvideo --geometry="$geometry" -m sdl -f pipe:wayland-mirror

# Alternative method via ffplay

This file has been truncated. show original

Interesting script I found here, from Line 18 (-m sdl -f pipe:wayland-mirror) it appears to me that it would in general be possible to send a video-stream to the pipewire “channel” (not sure if it’s the correct word) to maybe get it showing up in the app? Sadly gnome is doing their own thing in mutter (gnome-shell) and not using/implementing wlroots (or at least the different extensions like wlr-screencopy-unstable-v1) why wf-recorder does not work under gnome. There appears to be a screen recorder built-in in gnome that’s working, but I couldn’t figure out how to it’s called/how to open it from a shell so far and if it would be possible to stream the output somewhere except files.

Edit: Another thing I came across (unverified) is a user claiming slack is preventing from enabling WebRTCPipeWireCapturer in newer versions e.g. 4.35.121 directly through the app.asar including a integrity-check of the file.

¹ that hopefully never has to exist, so the end-result will be wayland as standard

SebTM · November 16, 2023, 7:32pm

https://forums.slackcommunity.com/s/question/0D53a00009BSEGACA5/when-will-slack-support-wayland-screen-sharing-does-anyone-have-workarounds-or-hacks-to-make-it-work?language=en_US

It’s a slack issue they don’t get under control since months (!) it seems as first the app was crashing (I pushed the update for that to nixpkgs) completely, now it works for some users and others not. Downgrading to 4.29.149 solves it - but might be not the best option (have to check change log about security-fixes like webp)

Update: 4.34.115 seems to work for me as well, but I get the gnome-sharing dialog from the screenshot above about 3 times but then it works and shows all apps on the desktop.

TLATER · November 16, 2023, 7:56pm

Just as a side note, you can sidestep all these electron issues (upstream only recently really started supporting wayland with experimental flags, and it will take years for all apps built with it to adapt since they’re always out of date and care little for enabling Linux-specific features even when they update) by just using browsers instead.

It’s all just websites repackaged into electron anyway, that only use electron because they want mute shortcuts (which can be easily emulated with xdotool-alikes, or wayland compositor features).

If you like not having a URL bar, you can build your own SSB with just a .desktop: https://github.com/TLATER/dotfiles/blob/e633196dca42d96f42f9aa9016fa8d307959232f/home-modules/firefox-webapp.nix

Or use ferdi.

That way you get to use browsers on their latest patch releases, don’t need to run 20 browsers that each eat gigabytes of memory independently, get to use add-ons, and you’re not necessarily forced to use chromium.

Really w3c should just sit down and standardize the minor things chat applications end up using electron for and bring back the ssb initiative, but hey.

APCodes · November 17, 2023, 10:35am

Hey that reminds me of using this stuff on FreeBSD!

But yes, that is a good way to go. So is Ferdium / Ferdi. Thanks for reminding me of that one!

SebTM · November 18, 2023, 11:53am

@TLATER Thanks

I was aware that electron-apps are wrapper for web-apps but never thought about/looked into building a simple wrapper with my local browser. I used ferdi in the past and wasn’t that happy with it but I consider giving it another try before diving into doing custom-stuff again

SebTM · November 22, 2023, 8:53pm

Slack really disabled the feature even partially working without announcement in newer versions:
https://github.com/flathub/com.slack.Slack/issues/101#issuecomment-1808323806

This is my current working overlay even I have to confirm multiple-times to share it works and better/less work for now but I will still be locking into alterantives by time:

slack = pkgs.slack.overrideAttrs (oldAttrs: rec {
  version = "4.35.126";
  src = pkgs.fetchurl {
    url =
      "https://downloads.slack-edge.com/releases/linux/${version}/prod/x64/slack-desktop-${version}-amd64.deb";
    sha256 = "sha256-ldFASntF8ygu657WXwk/XlpHzB+S9x8SjAOjjDKsvCs=";
  };

  fixupPhase = ''
    sed -i -e 's/,"WebRTCPipeWireCapturer"/,"LebRTCPipeWireCapturer"/' $out/lib/slack/resources/app.asar

    rm $out/bin/slack
    makeWrapper $out/lib/slack/slack $out/bin/slack \
      --prefix XDG_DATA_DIRS : $GSETTINGS_SCHEMAS_PATH \
      --suffix PATH : ${lib.makeBinPath [ pkgs.xdg-utils ]} \
      --add-flags "--ozone-platform-hint=auto --enable-features=WaylandWindowDecorations,WebRTCPipeWireCapturer"
  '';
});

futile · December 19, 2023, 12:19pm

This works for me (commented out the manual version and src, but they are still 4.35.126 for me anyways), thanks a lot!!

SebTM · May 25, 2024, 10:57am

FYI: Slack re-enabled screensharing in a recent update again by default so no need for the overlay anymore - even though it odes not fix the issue on gnome that I have to select/confirm the screen to share twice (at least on wayland)

Verified it working for me with latest slack-version from unstable.

Source: Screen sharing on Wayland · Issue #101 · flathub/com.slack.Slack · GitHub