Broken screenshare in versions above 0.47.2

[ShyAssassin]

Versions above 0.47.2 breaks screen sharing functionality

Continuation of #9849
The original author of the issue seemed to have identified the problematic commit in the original issue

Hyprland version

0.48.1

Regression

yes

System Info and Hyprland Version

System/Version info

Hyprland 0.48.1 built from branch  at commit 29e2e59fdbab8ed2cc23a20e3c6043d5decb5cdc  ().
Date: 2025-03-28
Tag: v0.48.1, commits: 
built against:
 aquamarine 0.8.0
 hyprlang 0.6.0
 hyprutils 0.5.2
 hyprcursor 0.1.12
 hyprgraphics 0.1.2


no flags were set


System Information:
System name: Linux
Node name: miyabi
Release: 6.6.85
Version: #1-NixOS SMP PREEMPT_DYNAMIC Fri Mar 28 20:59:57 UTC 2025


GPU information: 
0c:00.0 VGA compatible controller [0300]: NVIDIA Corporation AD102 [GeForce RTX 4090] [10de:2684] (rev a1) (prog-if 00 [VGA controller])
NVRM version: NVIDIA UNIX x86_64 Kernel Module  565.77  Wed Nov 27 23:33:08 UTC 2024


os-release: ANSI_COLOR="1;34"
BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"
BUILD_ID="24.11.20250402.44a69ed"
CPE_NAME="cpe:/o:nixos:nixos:24.11"
DEFAULT_HOSTNAME=nixos
DOCUMENTATION_URL="https://nixos.org/learn.html"
HOME_URL="https://nixos.org/"
ID=nixos
ID_LIKE=""
IMAGE_ID=""
IMAGE_VERSION=""
LOGO="nix-snowflake"
NAME=NixOS
PRETTY_NAME="NixOS 24.11 (Vicuna)"
SUPPORT_END="2025-06-30"
SUPPORT_URL="https://nixos.org/community.html"
VARIANT=""
VARIANT_ID=""
VENDOR_NAME=NixOS
VENDOR_URL="https://nixos.org/"
VERSION="24.11 (Vicuna)"
VERSION_CODENAME=vicuna
VERSION_ID="24.11"


plugins:
  split-monitor-workspaces by Duckonaut ver 1.2.0

Description

Screen sharing from any app such as firefox or discord initializes the screen sharing but the image isnt updated and is stuck on the first frame.

How to reproduce

Install hyprland 0.48.1 and xdg-desktop-portal-hyprland 1.3.9
Open discord/vesktop or firefox on this page and start a screen capture
Screen share will start but will only transmit a singular frame

Additional info & File uploads

flake.nix
hyprland.nix
hyprland_config_dump.txt

[ikalco]

try hyprland-git, and if that doesn't work try setting render:explicit_sync_kms = false in your config

also if you are willing, try out my pr #9807, it probably fixes your issue

note:
I can't repro this but I've seen it a few times while messing with related code so it's definitely finicky

[ShyAssassin]

Switching to hyprland-git as of 8a8f394 does not fix it, screen sharing functionality is still not working displaying the same behavior of only transmitting one frame, setting render:explicit_sync_kms = false did not fix it either.
I did also try your pr #9807 but it did not fix the issue either.

[ikalco]

oops, actually try render:explicit_sync = false
I remembered the code wrong lol

also since my PR didn't work I'm willing to bet your screenshare is using shm instead of dmabuf
you might be able to check by looking at the logs of /usr/lib/xdg-desktop-portal-hyprland --verbose

[ShyAssassin]

setting render:explicit_sync = false while on hyprland-git or your PR does not fix the issue
Im pretty sure i am using dmabuf since i see the following (couldnt find any reference to shm in the logs)

[TRACE] [core] createGBMDevice: render node /dev/dri/renderD128
[TRACE] [core] dmabufFeedbackTrancheTargetDevice
[TRACE] [core] dmabufFeedbackTrancheFormats
[TRACE] [core] dmabufFeedbackTrancheDone
[TRACE] [core] dmabufFeedbackDone

[mlophez]

@ShyAssassin Thank you for opening the discussion.
I'll help with whatever I can.

[lukasl-dev]

I have also encountered this problem, as mentioned in another (different) issue #9732. However, @micartey and I found the commit c754d79 to be the cause. The preceding commit 8c97cb7 works fine.

I also tested commit e96b8ce, resulting in the same screen share issue.

[vaxerski]

would that mean all affected people are nix users? @fufexan for nix

[mlophez]

@vaxerski Screenshot works fine, it's sharescreen from browser, but capture from wl-recorder works well also.

[vaxerski]

is it possibly that dmabuf capture is broken? Can you try wl-screenrec? (IIRC it's gpu accel'd so it would test the theory, idk what "wl-recorder" is (you mean wf?))

[mlophez]

@vaxerski, sorry, yes the command is wf-recorder -f test.mp4 (records the screen and saves it to the file test.mp4)
I'll try with wl-screenrec later this afternoon to see if the issue comes from that.

[mlophez]

I test wl-screenrec -f test.mp4. It give me 0fps.

[vaxerski]

yeah, looks like dmabuf is broken then. It's likely 279b060

[ghost]

for me obs just seems to not respond, anyway @vaxerski this has 5 upvotes can it be promoted to an issue?

[vaxerski]

No, as the root cause has still not been identified. This is not actionable.

[vp1981]

Hello.
I tried the above link (gUM) and it worked: I clicked on the screen capture, moved the mouse and saw the screen, the wallpaper and the mouse pointer movement (tested in firefox nightly and qutebrowser).

I'm using Archlinux with the following software:

local/hyprland 0.48.1-4
local/firefox-nightly 139.0a1+20250408.1+hde204898c52a-1
local/qutebrowser-git 3.4.0+108+gef2ceccd2-1

[vaxerski]

@PlasmaPower 279b060 is your commit. Seems to break dmabuf screensharing for some people (frames never get done)

Any ideas?

[PlasmaPower]

Yeah but even then future timeline points should be signalled by normal rendering which would cause earlier points to be signalled as well

[ikalco]

thats why I thought the properly release rendered buffers pr would work,
cause it removes the monitor timeline stuff

[PlasmaPower]

If it's about the buffer release I'm not sure why this commit seems to be the issue. Also why does it break it when explicit sync is disabled? The codepath there should be the same as before.

[ikalco]

the pr adds a rendering done callback instead of using a waiter on the monitor timeline point

[PlasmaPower]

I was previously confused because, as noted elsewhere in the thread, there's two separate issues here. (1) some sort of nix packaging issue caused by another commit and (2) my explicit sync screencopy commit not working for some people, perhaps an intel specific issue, though I think so far we only have one maybe two people in this thread who can replicate it. That's why I was confused about disabling explicit sync not fixing it for some people, because they have (1) not (2).

[PlasmaPower]

I can't replicate this. Can someone who can replicate this upload (ideally trace) logs?

[PlasmaPower]

Also, @theogf what GPU vendor are you using and what driver version do you have?

[theogf]

I am having an nvidia card (GeForce GTX 1660 Ti) with driver nvidia-dkms 570.133.07-2 but I think Hyprland runs mostly on my integrated AMD Radeon graphics.
I am using the Hyprland version from AUR so give me some time to build master locally add the patch and report back.

[theogf]

I tried what I could but could not resolve the dependencies for the git version (some hypr*-git version seem to rely on hyprutils instead of hyprutils-git ? )

Otherwise I remove the render: explicit_sync - 0 and produced a trace, by starting Hyprland, opened google meet and tried to share my screen.

One of the last line says:

[ERR] CSyncTimeline::addWaiter: drmIoctl failed

trace.log

[PlasmaPower]

#10050 should fix this by falling back on the non-explicit-sync screencopy in that case

[mlophez]

@PlasmaPower with de fix above (#10050) screenshare works for me without render render:explicit_sync = 0.

Attach my logs.

hyprland.log

[ShyAssassin]

Has there been any progress on this for Nix users?
i just tried the latest version of hyprland from git and i still am unable to screenshare

[micartey]

No news, if you need screen share you can go back to the last working commit with:

nix flake update hyprland --override-input hyprland github:hyprwm/Hyprland/8c97cb7858e5d6c35d1a055930904346fb4248db

[NikSneMC]

No news, if you need screen share you can go back to the last working commit with:

nix flake update hyprland --override-input hyprland github:hyprwm/Hyprland/8c97cb7858e5d6c35d1a055930904346fb4248db

Sadly, it's still not working for me
hyprctl version output:

Hyprland 0.47.0 built from branch  at commit 8c97cb7858e5d6c35d1a055930904346fb4248db  ().
Date: 2025-03-13
Tag: v0.47.0, commits: 
built against:
 aquamarine 0.7.2
 hyprlang 0.6.0
 hyprutils 0.5.1
 hyprcursor 0.1.11
 hyprgraphics 0.1.2


no flags were set

[duesabati]

Hi everyone I don't know if it can help, but I got the same issue here with a freshly installed arch linux and Hyprland (non git) also I'm on Nvidia I really did not touch anything beside following the guides if you need me to show any diagnostic commands I am available

[duesabati]

~ a small followup

Since this is my work machine I had to fix it / workaround it, unfortunately I can't say what worked but roughly what I've done is:

1. Disable Nvidia by following the Arch wiki.
2. Removed the bitrate 10 option that was suggested as a fix for it
3. I have made sure that all pipewire related stuff were working properly
4. I have made sure that all xdg-desktop-* related stuff were working properly

At the time of writing I'm on version 0.48.1

[ShyAssassin]

as of hyprland 0.49.0 this issue is still present

[lukasl-dev]

I can confirm this (NixOS)

[deadYokai]

have same issue, pipewire screencapture just don't works, trying dmabuf crashes obs, and scpy have artifacts

[ShyAssassin]

for what it is worth under 0.47.2 where screen share does work for me using dmabuf also crashed OBS.

[rszyma]

have same issue, pipewire screencapture just don't works, trying dmabuf crashes obs, and scpy have artifacts

I have managed to fix scpy artifacts by setting bitdepth,8 (which is the default btw). Also in OBS need to tick Flip red and blue option in scpy properties.

I was previously getting the same scpy artifacts as you on bitdepth,10. But it was working before on bitdepth,10 I swear (I'll bisect later, maybe).

[d-hain]

I wanted to try bisecting myself but it works when running in debug mode using:

nix run .#hyprland-debug

just not on my normal (NixOS) system using the Hyprland flake.

With both of those I am running a51e639.

[lukasl-dev]

I've noticed some warnings in my Hyprland logs:

[LOG] [CWLDataOfferResource] Offer 347369c0 asks to send data from source 3499e3f
[WARN] [../src/protocols/core/DataDevice.cpp:58] Offer was never accepted, sending accept first
[LOG] [CWLDataOfferResource] Offer 347369c0 asks to send data from source 3499e3f
[WARN] [../src/protocols/core/DataDevice.cpp:58] Offer was never accepted, sending accept first

However, I'm not sure whether they are related to this issue, given that I'm not familiar with the Hyprland code base / protocols.

[ShyAssassin]

@vaxerski although the issue has not been root caused can this be moved to issues?
it seems to affect the majority of nix users

[fufexan]

There's surely something you all have in your configs that triggers this. That needs to be found out before we move further.

[lukasl-dev]

Maybe, but I can't imagine a thing because it worked flawlessly before updating Hyprland to the newest version.

To be fair, @micartey and I share a very similar config, so it's likely the case.

If you or someone else wants to take a look or compare their configs, mine is open source: https://github.com/lukasl-dev/nixos

• Hyprland Home-Manager
• Hyprland NixOS
• Nvidia
• Mesa

[spikespaz]

This happens for me on 0.47.1, which is older than the problematic version that others found. All of my monitors explicitly set bitdepth = 8. Unlike what others have reported, OBS works fine.

Hyprland 0.47.1 built from branch  at commit 75dff7205f6d2bd437abfb4196f700abee92581a  ().
Date: 2025-01-29
Tag: v0.47.1, commits:
built against:
 aquamarine 0.7.1
 hyprlang 0.6.0
 hyprutils 0.4.0
 hyprcursor 0.1.11
 hyprgraphics 0.1.1


no flags were set

To build Hyprland from the tagged commit, I had to:

    package = (pkgs.hyprland.override {
      aquamarine = pkgs.aquamarine.overrideAttrs (self: super: {
        nativeBuildInputs = super.nativeBuildInputs ++ [ pkgs.libgbm ];
      });
    }).overrideAttrs (self: super: {
      nativeBuildInputs = super.nativeBuildInputs ++ [ pkgs.libgbm ];
    });

I find it worth mentioning this libgbm because it's a difference, but probably unrelated.

[vp1981]

Dunno what is going on with nix, but I have the gUM test working fine in firefox-nightly and hyprland (-git) (archlinux).

I think it would be helpful if (nix?) users who have problems with the gUM test would explicitly report exactly what software they are using and what hardware they have.

For example, on the test host I have:

$ pacman -Qs linux-zen
local/linux-zen 6.14.7.zen1-1
    The Linux ZEN kernel and modules
local/linux-zen-headers 6.14.7.zen1-1
    Headers and scripts for building modules for the Linux ZEN kernel


$ sudo lspci -vvv | grep 'VGA '
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA controller])
$ lsmod | grep i915
i915                 4988928  63
i2c_algo_bit           24576  1 i915
drm_buddy              24576  1 i915
video                  81920  1 i915
ttm                   118784  1 i915
drm_display_helper    286720  1 i915
cec                   106496  2 drm_display_helper,i915
intel_gtt              28672  2 intel_agp,i915


$ hyprctl version
Hyprland 0.49.0 built from branch main at commit eb3b38d40baca5c05ddbc1507b3d3f02a0ccb164  (eventLoop: fixup event source callbacks).
Date: Sun May 18 23:27:30 2025
Tag: v0.49.0-29-geb3b38d40, commits: 6127
built against:
 aquamarine 0.8.0
 hyprlang 0.6.3
 hyprutils 0.7.1
 hyprcursor 0.1.12
 hyprgraphics 0.1.3


no flags were set


$ pacman -Qs hypr
local/hyprcursor-git 0.1.12+2+gac903e80-2
    The hyprland cursor format, library and utilities
local/hyprgraphics-git 0.1.3+1+g60754910-3
    Hyprland graphics / resource utilities
local/hypridle-git 0.1.6+4+gecf2a364-1
    Hyprland's idle daemon
local/hyprland-git 0.49.0+29+geb3b38d4-1
    Hyprland is an independent, highly customizable, dynamic tiling Wayland compositor that doesn't sacrifice on its looks
local/hyprland-per-window-layout 2.13-1
    Per window keyboard layout (language) for Hyprland wayland compositor
local/hyprland-protocols-git 0.6.4+0+g3a5c2bda-1
    Wayland protocol extensions for Hyprland
local/hyprland-qt-support-git 0.1.0+8+g073c52be-2
    A qml style provider for hypr* qt apps
local/hyprland-qtutils-git 0.1.4+0+g4be1d324-3
    Hyprland QT/qml utility apps
local/hyprlang-git 0.6.3+1+g163c83b3-1
    The official implementation library for the hypr config language
local/hyprlock-git 0.8.2+5+gf7f0c9c6-2
    Hyprland's GPU-accelerated screen locking utility
local/hyprpaper-git 0.7.5+1+g99213a18-2
    A blazing fast wayland wallpaper utility with IPC controls
local/hyprpicker-git 0.4.5+4+g500c4618-1
    A wlroots-compatible Wayland color picker that does not suck
local/hyprpolkitagent 0.1.2-7
    Simple polkit authentication agent for Hyprland, written in QT/QML
local/hyprsunset-git 0.2.0+2+g2a8ef76c-2
    An application to enable a blue-light filter on Hyprland
local/hyprutils-git 0.7.1+0+g674ea573-1
    Hyprland utilities library used across the ecosystem
local/hyprwayland-scanner-git 0.4.4+3+ge511882b-1
    A Hyprland implementation of wayland-scanner, in and for C++
local/pyprland-git 2.4.5+26+g8b028be-1
    Easy scratchpads, menus, smart monitor placement and more hyprland tweaks
local/xdg-desktop-portal-hyprland-git 1.3.9+6+g76bbf1a6-4
    xdg-desktop-portal backend for Hyprland

[micartey]

Hardware-wise, this is irrelevant.

The only interesting information would be if everyone having this issue has NVIDIA GPUs, but this is also taken from far, far away as we didn't update our drivers and thus the issue is not with NVIDIA when it worked before.

With the commit I bisected we have all the information what change did break stuff and the only cause I can come up with is maybe us using Hyprland through flake and thus being always on latest commit when we update.

I can confirm it works on pkgs stable, but the version is from end of November and who knows if many more people will have issues when they update their channel to 25.05.

If not and using the version in nix pkgs works, then the issue is with this projects flake.

[fxzzi]

For extra information here, I'd like to say I'm running NixOS Unstable, with Nvidia, and screensharing is working as it always has for me. Do with this info what you will.

[lukasl-dev]

@fxzzi could you share your config?

[fxzzi]

@fxzzi could you share your config?

https://gitlab.com/fazzi/nixohess

Everything here.

[lukasl-dev]

Thanks. I couldn't find anything conspicuous, sadly. :/

[deadYokai]

recompiling xdg-desktop-portal-hyprland-git, works for me at least

[spikespaz]

What commit?

[deadYokai]

What commit?

I just recompiled and it works

76bbf1a

[lukasl-dev]

I'm on 18377d2

Not sure what part exactly fixed this, but I've upgraded to channel 25.05 and removed my custom xdg portal config, and it seems to work now. After upgrading, Nix told me that there's a conflict between my xdg portal config and hyprland portal config, which I resolved by removing mine.

[spikespaz]

What did your configuration look like? This is what I am using on Home Manager's side:

  xdg.portal = {
    enable = true;
    extraPortals = with pkgs; [
      xdg-desktop-portal-hyprland
      xdg-desktop-portal-gtk
      kdePackages.xdg-desktop-portal-kde
    ];
    configPackages = [ config.wayland.windowManager.hyprland.package ];
    config.hyprland = {
      default = [ "hyprland" "gtk" ];
      "org.freedesktop.impl.portal.FileChooser" = "kde";
      "org.freedesktop.impl.portal.Print" = "kde";
    };
  };

[fxzzi]

I would try not to configure any of these, comment out this entire block.

The xdg portal configuration was made redundant at some point in Hyprland, I dont have any of this portal config and mine works fine.

[lukasl-dev]

@spikespaz Sorry for the late response. It looked pretty similar to your current one.

Here's are my previous xdg portal config:

https://github.com/lukasl-dev/nixos/blob/1ad34786c0312e72716e760f577fa2ce442d8aef/home/desktop/xdg.nix#L44-L58

I don't have much time at the moment, so I decided to just comment it out until I have more time to experiment.

[spikespaz]

Preventing perfectly valid configurations for multiple portals should be considered a bug. I want to use different portals for some method calls.

Is everyone here a NixOS user, or is this a problem on other systems as well?

[LOSEARDES77]

I have a problem where discord and browser for example in google meet, screen share is not working but in obs or wf-recorder works flawlessly.
I am in Arch, i thought this was an nvidia issue but i think its a pipewire issue.
I have also tries -git but it is not working either.
I have render::explicit_sync = false in my config too but it didnt change anything.

System info:

Hyprland 0.49.0 built from branch  at commit 9958d297641b5c84dcff93f9039d80a5ad37ab00  (version: bump to 0.49.0).
Date: Thu May 8 20:15:18 2025
Tag: v0.49.0, commits: 6098
built against:
 aquamarine 0.8.0
 hyprlang 0.6.3
 hyprutils 0.7.1
 hyprcursor 0.1.12
 hyprgraphics 0.1.3


no flags were set


System Information:
System name: Linux
Node name: loseardes77-laptop
Release: 6.14.9-arch1-1
Version: #1 SMP PREEMPT_DYNAMIC Thu, 29 May 2025 21:42:15 +0000


GPU information: 
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation AD106M [GeForce RTX 4070 Max-Q / Mobile] [10de:2860] (rev a1) (prog-if 00 [VGA controller])
06:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Phoenix3 [1002:1900] (rev c5) (prog-if 00 [VGA controller])
NVRM version: NVIDIA UNIX x86_64 Kernel Module  570.123.14  Sun May 11 03:02:14 UTC 2025


os-release: NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo


plugins:

Log of
WAYLAND_DEBUG=1 /usr/lib/xdg-desktop-portal-hyprland --verbose
log.txt

if you need any more logs ping me

[LOSEARDES77]

I have also gotten this logs from pipewire when screen sharing and wireplumber. wireplumber logs don't grow when starting screen share on discord.

pipewire.log

wireplumber.log

[mmi333]

After spending too much time on this, the fix for me was simply changing bitdepth from 10 to 8 in monitor rules.

monitor = eDP-2, preferred, auto, auto, bitdepth, 8

This fix was apparently working as far back as 8 months ago (I found it here ).

Funnily enough, the reason I set it to 10 in the first place was because screen sharing wasn't working and I spent too much time trying to get it to work till someone mentioned setting bitdepth to 10 which fixed it then.

This was way back in October 2023 and worked for other people too but stopped working at around November 2024 where the fix was to set it back to 8.

[fxzzi]

https://wiki.hypr.land/Configuring/Monitors/#10-bit-support

p.s. this has been there for a loooooooooooooooooooong time

[mmi333]

Yeah I searched now and it was added in September 2023 which is even earlier than my comment where changing from 8 to 10 fixed screen sharing.

I don't know what exactly broke 10 bit screen capture on browsers (or when it broke) but I thought I'd share this here as my first thought was to look in the issues/discussions not the wiki (which I'd read before) so maybe someone else has the same problem.

[d-hain]

setting my main monitor bitdepth from 10 to 8 instantly resolved the issue.
i probably just read the first part and stopped before reading the warning box 🤦

Thank you very much ❤️

[Steven--]

I am also only able to use screen sharing if bitdepth is set to 8.

[TanawatJukmongkol]

I can't screen share with no bitdepth set, bitdepth set to 8, and even explicit_sync = 0.

[micartey]

I am able to screen share if I don't use the flake but the package in the nix channel 25.05 (24.11) did work as well for me.

[varappdev]

Plasma is able to screenshare with 10 bit color and above just fine. On Hyprland I get a bunch of pipewire error which i check with journalctl --user -eu pipewire.service

[clotodex]

I solved my issue by something I did NOT found googling (full credit goes to @oddlama for my fix)
This only applies to NixOS+HomeManager setups - hope this helps someone.

My symptoms were: wl-screenrec working, but any other tool not opening the selector. (so slack, chrome, ... not working)

The issue was a conflict between the portal chosen by NixOS vs HomeManager.
I had in my graphics config (NixOS) programs.hyprland.enable = true.
This conflicts with the HomeManager xdg.portal.enable. My setup is this

  xdg.portal = {
    enable = lib.mkForce true;
    xdgOpenUsePortal = true;
    config.common = {
      default = [ "gtk" "hyprland" ];
      "org.freedesktop.impl.portal.Secret" = [ "gnome-keyring" ];
      "org.freedesktop.impl.portal.ScreenCast" = [ "hyprland" ];
      "org.freedesktop.impl.portal.Screenshot" = [ "hyprland" ];
      "org.freedesktop.portal.FileChooser" = [ "xdg-desktop-portal-gtk" ];
    };
    extraPortals = [
      pkgs.xdg-desktop-portal-gtk
    ];
  };

The solution is to remove the programs.hyprland.enable.
This essentially switches it to a full HM setup.
I don't know if the double setup was broken intentionally, but following the wiki this setup does not work for me.

Again, this might be specific to my setup, but if someone is stuck and it is not the bitdepth - then this might be it.
The cause is simply dbus not knowing what the right portal to choose is, since there are duplicate options.

[Ali-SZ]

On NixOS, I can capture screen on OBS but screen sharing does not work on Discord, Zen and Brave, it shows a black screen and cursor only if i move the cursor on a xwayland application.

EDIT: The problem was not NixOS or Hyprland.

My desktop's shell is running as systemd service and programs launched with it's launcher couldn't screenshare and i realized if i launch them with terminal their screensharing would work, i just had to add wayland.windowManager.hyprland.systemd.variables = ["--all"]; in my home-manager config, it fixed the screensharing for me.