Wayland Screensharing Screens/Windows List Empty

I have both KDE Plasma 6 and Hyprland set up on my NixOS systems running using
the nixos-24.11 nixpkgs flake input.

I tried to screenshare today through Discord and the screenshare display/windows list appears empty. Nothing appears in the list. This behaviour is observed both in Hyprland (USWM) and the Wayland session for Plasma 6.

This would lead me to believe that something is wrong with the XDG portal configurations, but I am stumped. I went through the NixOS Stable Manual and NixOS Wiki, but found nothing of help. I also wasn’t able to find a post here on NixOS Discourse that reflected this same issue.

I tested the using the following on both Hyprland (USWM) and the Wayland session for Plasma 6:

  • Browser version of Discord on Brave
  • Browser version of Discord on Firefox
  • The discord client app from nixos-24.11
  • The discord client app from nixos-unstable
  • The discord-canary client app from nixos-24.11
  • The discord-canary client app from nixos-unstable
  • The vesktop client app from nixos-24.11
  • The vesktop client app from nixos-unstable
  • The discord-screenaudio client app from nixos-24.11
  • The discord-screenaudio client app from nixos-unstable

I then tried to X11 session for Plasma 6, and that did work, as should be expected.

To confirm that this isn’t specific to Discord, I also tried screensharing with Jitsi and the issue is the same there.

Other than this, the portals seem to be working correctly for other tasks, such as the file chooser, which does work. I am able to open the file chooser and upload the selected files at https://www.amazon.com/sendtokindle in Firefox in Wayland sessions. This makes this more confusing.

Steam also appears to work fine in this regard to the XDG portals working, as it is able to access my games drive mounted in /mnt for my user.

Any idea what is wrong? What am I missing?


Output of nix-shell -p nix-info --run "nix-info -m":

 - system: `"x86_64-linux"`
 - host os: `Linux 6.12.9, NixOS, 24.11 (Vicuna), 24.11.20250115.e24b4c0`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.24.11`
 - nixpkgs: `/nix/store/awsvw44jla0idziiks2zwgzslfd2dczn-source`


System

Configurations

I included potentially related values here from my system configuration.

{ inputs, pkgs, ... }:
{
  imports = [ inputs.home-manager.nixosModules.default ];

  home-manager = {
    useUserPackages = true;
    useGlobalPkgs = true;

    users."sebas" = import ./users/sebas;
  };

  environment.sessionVariables.NIXOS_OZONE_WL = "1";

  programs.hyprland = {
    enable = true;
    withUWSM = true;
  };

  services = {
    desktopManager.plasma6.enable = true;
    gnome.gnome-keyring.enable = true;
    gvfs.enable = true;
  };

  xdg.portal = {
    enable = true;
    xdgOpenUsePortal = true;
    extraPortals = [ pkgs.xdg-desktop-portal-gtk ];
  };
}

Final Evaluated XDG Portal Values

This is the actual evaluated value of xdg.portal, which I sourced through the nix repl. This is what actually gets built.

{
  config.xdg.portal = {
    config = { };
    configPackages = [
      "/nix/store/jv8c6l3r7lvyxnlhf8h1jl1zhx2rn3mw-plasma-workspace-6.2.5"
      "/nix/store/5034wblcrnara8rjah8ak57z3nlijgq0-hyprland-0.45.2"
    ];
    enable = true;
    extraPortals = [
      "/nix/store/nhjgy68kzplrqk6i2wqyw3l9r180k4hj-xdg-desktop-portal-gtk-1.15.1"
      "/nix/store/klkjvwbjh9f8f5nm0adhyj0v8hcvn4fm-kwallet-6.8.0"
      "/nix/store/7a7z07b0jp5f4czdjp914mcr5g7ab3id-xdg-desktop-portal-kde-6.2.5"
      "/nix/store/nhjgy68kzplrqk6i2wqyw3l9r180k4hj-xdg-desktop-portal-gtk-1.15.1"
      "/nix/store/8nl1bqgcbcc0q9q4djzxb75dmaigrraa-gnome-keyring-46.2"
      "/nix/store/44y2l4q82y4c28gnqwm7llpyz2c1l5f3-xdg-desktop-portal-hyprland-1.3.6"
      "/nix/store/nhjgy68kzplrqk6i2wqyw3l9r180k4hj-xdg-desktop-portal-gtk-1.15.1"
    ];
    lxqt = {
      enable = false;
      styles = [ ];
    };
    wlr = {
      enable = false;
      settings = { };
    };
    xdgOpenUsePortal = true;
  };
}

Home-Manager

Configurations

{ pkgs, ... }:
{
  wayland.windowManager.hyprland = {
    enable = true;
    systemd.enable = false;
    settings.envd = [
      "CLUTTER_BACKEND,wayland"
      "GDK_BACKEND,wayland,x11,*"
      "QT_AUTO_SCREEN_SCALE_FACTOR,1"
      "QT_QPA_PLATFORM,wayland;xcb"
      "QT_QPA_PLATFORMTHEME,qt5ct"
      "QT_WAYLAND_DISABLE_WINDOWDECORATION,1"
      "SDL_VIDEODRIVER,wayland"
      "XDG_CURRENT_DESKTOP,Hyprland"
      "XDG_SESSION_DESKTOP,Hyprland"
      "XDG_SESSION_TYPE,wayland"
    ];
  };

  xdg = {
    enable = true;
    portal = {
      enable = true;
      xdgOpenUsePortal = true;
      extraPortals = [ pkgs.xdg-desktop-portal-gtk ];
      /*
       I set this as suggested by the home-manager evaluation warning:
       ##############################################################################################################
       evaluation warning: sebas profile: xdg-desktop-portal 1.17 reworked how portal implementations are loaded, you
                           should either set `xdg.portal.config` or `xdg.portal.configPackages`
                           to specify which portal backend to use for the requested interface.
       
                           https://github.com/flatpak/xdg-desktop-portal/blob/37a6f7c8b8e08b9861f05e172cd4e0d07a832c4d/doc/portals.conf.rst.in
       
                           If you simply want to keep the behaviour in < 1.17, which uses the first
                           portal implementation found in lexicographical order, use the following:
       
                           xdg.portal.config.common.default = "*";
       ##############################################################################################################
      */
      config.common.default = "*";
    };
  };
}

Final Evaluated XDG Portal Values

This is the actual evaluated value of xdg.portal, which I sourced through the nix repl. This is what actually gets built.

{
  config.home-manager.users."sebas".xdg.portal = {
    config = { };
    configPackages = [ ];
    enable = true;
    extraPortals = [
      "/nix/store/nhjgy68kzplrqk6i2wqyw3l9r180k4hj-xdg-desktop-portal-gtk-1.15.1"
    ];
    xdgOpenUsePortal = true;
  };
}

I also tested the camera and microphone inputs again through Jitsi, and they work perfectly fine in the Wayland sessions. No issues here.

The user systemd logs through journalctl --user -b 0 don’t show anything of value either that would indicate that anything is wrong.

You’ve actually found yourself victim of not 1 but 3 major issues actually.

Screensharing under wayland only is borked, screensharing in discord is borked anyways even if screensharing is working under wayland correctly.

Alot of discord specific issue traces back to bad hardware accel code that just… doesnt work. Discord is also closed source, so we have to reverse engineer and hack on fixes to make shit work and Wayland really doesnt like it most of the time anyways even when it is behaving its unstable af.

If screensharing is a serious need of yours, you should consider switching back to x11 but i understand if you dont.

Another work around is to use pipewire configured with xwayland and boot discord with the --use-gl=desktop flag, this fixes the video accel problem completely but screensharing is still borked.
If you want to tinker with this, you can replace discord in your system packages with this block:

    (pkgs.writeShellApplication {
      name = "discord";
      text = "${pkgs.discord}/bin/discord --use-gl=desktop";
    })
    (pkgs.makeDesktopItem {
      name = "discord";
      exec = "discord";
      desktopName = "Discord";
    })

This will create a new discord package (no icon) you can launch from terminal or desktop that includes the hardware accel fix with the main discord pkg.

You didnt mention webcord, but webcord is the only version of discord ive found that actually works correctly out of the box with all features working, including the proprietary krisp voice plugin which typically doesnt work on any nix system, and even with that, screensharing will still result in frequent crashes when it hooks into the window you want to stream.
ive been actively banging away at this issue for months with little progress since ive had to de-compile the bins and read the assembly, and there is alot of it.

Caveat with Webcord though is it runs through an electron wrapper over the chromium framework, so its basically a really customized browser instance, so keybinds dont work even when your tabbed in but thats small fry compared to some of the other system breaking bugs.

I see. Any idea why this would still happen with Jitsi also?

I have no experience with Jitsi so i couldnt even hazzard a guess on that front

I did however find this on a another forum post that might be of interest.

You can pipe your screen output into a dummy webcam device, and set Zoom to use that webcam, which results in the other party seeing your desktop.

It’s a hack, but basically results in screen sharing.

If you’re using swaywm, you can use wf-recorder to do this. On other desktops, find something that can do screen recording, and pipe it into /dev/video2 similar as below:

# Install the v4l2 loopback driver
sudo pacman -S v4l2loopback-dkms
# Load the kernel module
sudo modprobe v4l2loopback

# Finally, pipe the screen output into the virtual webcam:
wf-recorder --muxer=v4l2 --codec=rawvideo --pixel-format=yuv420p --file=/dev/video2

Now jump back to zoom, and change the video output to the “Dummy video device”.

Extra tips:

  • Remember to turn off video mirroring, or everything will be mirrored, which you generally don’t want when sharing the screen.
  • In zoom, if you set the camera to Original Ratio, your full screen will be shared, but the quality will be really crap (it’s unlikely the other party will be able to read anything).
  • If you set it to 16:9, the sides of your screen will be cropped, but the quality should be readable. Your pick. :disappointed:
  • Remember to kill wf-recorder once you’re done or your screen will be shared next time you join a call!

OG post here, its one of the many answers: linux - Screensharing under Wayland - Super User

Thanks for suggesting Webcord. I just tried it. Ding ding.

I got the issue to pop up in the logs:

(electron:232689): Gdk-WARNING **: 03:18:37.982: Server is missing xdg_foreign support
[232689:0118/031848.645906:ERROR:screen_capture_portal_interface.cc(48)] Failed to request session: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No existe la interfaz «org.freedesktop.portal.ScreenCast» en el objeto en la ruta /org/freedesktop/portal/desktop
[232689:0118/031848.645920:ERROR:base_capturer_pipewire.cc(81)] ScreenCastPortal failed: 3

Well thats alot more descriptive, cool looks like you just need to configure pipewire.

Is it already in your main system config or no?

Yep. Maybe I’m missing something here?

{ ... }:
{
  hardware.pulseaudio.enable = false;

  services.pipewire = {
    enable = true;
    alsa = {
      enable = true;
      support32Bit = true;
    };
    jack.enable = true;
    pulse.enable = true;
  };
}

Hmm. This mixed with the XDG portal error kinda makes me think it really wants the x11 server running to do stuff with, maybe as an unlisted dependency.

How do you have your DE and shit configured?

I do have my Hyprland set up configured through home-manager, but at this moment I’m in the Plasma session to keep things simple. It was in Plasma that I got that log to come up. As far that is concerned, all I have is services.desktopManager.plasma6.enable = true; for that. Nothing else.

Not sure why it can’t find a portal that provides org.freedesktop.portal.ScreenCast.

I would think that the KDE portal, which is already included, would provide this. That or fallback to the GTK one.

n0f7lsbnafpyq0a8i14pixx1v7i1r7g1-system-path/share/xdg-desktop-portal/portals/kde.portal:

[portal]
DBusName=org.freedesktop.impl.portal.desktop.kde
Interfaces=org.freedesktop.impl.portal.Access;org.freedesktop.impl.portal.Account;org.freedesktop.impl.portal.AppChooser;org.freedesktop.impl.portal.Background;org.freedesktop.impl.portal.Email;org.freedesktop.impl.portal.FileChooser;org.freedesktop.impl.portal.Inhibit;org.freedesktop.impl.portal.Notification;org.freedesktop.impl.portal.Print;org.freedesktop.impl.portal.ScreenCast;org.freedesktop.impl.portal.Screenshot;org.freedesktop.impl.portal.RemoteDesktop;org.freedesktop.impl.portal.Settings;org.freedesktop.impl.portal.DynamicLauncher;org.freedesktop.impl.portal.GlobalShortcuts;org.freedesktop.impl.portal.InputCapture
UseIn=KDE

It’s in the portal definition. Not sure why it isn’t being used then.

Likely because XDG is so damned old its probably configured by default to look for screencasts in xorg if i had to guess even if you are running a different WM, remember that plasma6 and KDE6 are the first releases to use wayland as a default so its not fully settled yet im sure.
Try adding these

  services.xserver.enable = true;
  services.displayManager.sddm.enable = true;
  services.displayManager.sddm.wayland.enable = true;
  services.desktopManager.plasma6.enable = true;
  services.displayManager.defaultSession = "plasma";
  services.displayManager.autoLogin.user = "<your user here>"; #might be worth setting in case SDDM or plasma6 go apeshit at login which has been a known bug recently.
  hardware.opengl = {
	enable = true;
    extraPackages = with pkgs; [libvdpau-va-gl]; #these libs are often needed to smooth over rough edges on Wayland, i have no idea why to be perfectly honest.
  services.xserver.videoDrivers = ["nvidia"]; #change from nvidia if you got an amd card

This will still enable wayland as the main protocol to use but xserver will be there, and together these too create xWayland which blends elements of both and improve compatibility ALOT across many applications, including steam games
If you get a successful rebuild without issues, do a full reboot and try again

Let me give that a go. Thanks :+1:

Also, did some more digging.
Found this reference in the arch wiki, gotta love the Arch wiki.

https://wiki.archlinux.org/title/PipeWire#WebRTC_screen_sharing

Quoted:

WebRTC screen sharing

Most applications used to rely on X11 for capturing the desktop (or individual applications), for example when using WebRTC in web browsers (e.g. on Google Meet). On Wayland, the screen sharing mechanism is handled through the XDG Desktop Portal and PipeWire, which enables sharing content under Wayland with fine-grained access controls.

Tip: Test whether WebRTC screen sharing is working by using Mozilla’s GetUserMedia WebRTC test page.

Note: xdg-desktop-portal 1.10.0 fixed a mismatch between specification and implementation of its D-Bus interface. [3] Hence, some clients may not work with xdg-desktop-portal 1.10.0 or newer.

Firefox (84+) and Chromium (110+) support this method by default, while on older versions of Chromium (73+), one needs to enable WebRTC PipeWire support by setting the corresponding (experimental) flag at the URL chrome://flags/#enable-webrtc-pipewire-capturer or via CLI argument --enable-features=WebRTCPipeWireCapturer.

obs-studio (27+) supports this method by using the new PipeWire capture source.

Video

This article or section needs expansion.

Reason: pipewire-v4l2 (Discuss in Talk:PipeWire)

Although the software is not yet production-ready, it is safe to play around with. Most applications that rely on GStreamer to handle e.g. video streams should work out-of-the-box using the PipeWire GStreamer plugin, see GStreamer#PipeWire. Applications like e.g. cheese are therefore already able to share video input using it.

Using pipewire-v4l2, it should also be possible to use the pw-v4l2 script to preload a library (/lib/pipewire-0.3/v4l2/libpw-v4l2.so) that intercepts v4l2 calls and routes video through pipewire.

Although im not sure if this totally relevant tho tbh

1 Like

It is still, I see your point. I don’t use screen-sharing much at all for my use cases, so I’m fine to switch to an X11 session briefly for those sparse times it is needed. There is something wrong with either the XDG portal configurations or packaging, since this should work. Especially, since everything else with the portals seems to work perfectly. That or there was as bug introduced with the current package versions that has gone unnoticed. Before moving to NixOS, I used Arch with Hyprland for over a year. Screen capture there, even if buggy and not entirely perfect, did work with audio just fine. discord-screenaudio is what I used to use in those times and it worked well under Wayland. Jitsi screen-sharing worked for me the 3 times or so that I needed it also. That’s why when I expected it to work here in NixOS, but something seems off. Again, not a major issue for me since I don’t rely on it much. I am however going to do some digging into how the portals are packaged and configured for NixOS and home-manager set-ups, since something seems wrong here. I’ll open an issue in nixpkgs covering this also since it seems appropriate.

Thanks for the help. It was helpful to get to these conclusions :+1:

No problem, as for x11 over wayland. You can keep Wayland as the main and just keep xserver running as a service, after doing so you can tinker with your env variables for startup. You can set discord/zoom/whatevs to use x11, you can write this in your nixconfig as a makeShellApplication

as mentioned here, this will likely be your most flexible solution

1 Like

Make sure you enabled pipewire and rtkit, at a bare minimum.

  security.rtkit.enable = true;
  services.pipewire = {
    enable = true;
    pulse.enable = true;
  };

Also, check the status of the portal services.
The hyprland portal should provide screen-capturing, so extra config should generally not be necessary. (Don’t know about KDE.)

1 Like