HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
emersion
xdg-desktop-portal-wlr
C2019–2026
emersion / xdg-desktop-portal-wlr

xdg-desktop-portal-wlr

xdg-desktop-portal backend for wlroots

Mobile & Desktop
Explore on GitHubRead Hacker News discussions
16Distinct people
16Mentions
0Explicit recommenders
744GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

xdg-desktop-portal backend for wlroots

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year16 dated mentions

Observed mentions: 2019-09-22 09:50:26 UTC to 2026-03-20 13:37:33 UTC.

02462019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC303
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC615
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

16 sources
rektide·Jul 7, 2022
wlroots & kde both have their own xdg-desktop-portal-*[1][2]'s, which don't seem to be built by Red Hat. xdg-desktop-portal itself originates from Flatpak[3], which makes me think it's more like to related to Canonical/Ubuntu rather than being something RH drove. [1] https://github.com/emersion/xdg-desktop-portal-wlr https://news.ycombinator.com/item?id=32008412 (2 pts, 30 min ago) [2] https://github.com/KDE/xdg-desktop-portal-kde [3] https://github.com/flatpak/xdg-desktop-portal
In GTK 5 might drop X11 support
AshamedCaptain·Jan 21, 2022
Even the _current_ LTS from Ubuntu does not ship Pipewire 0.3, which is _required_ to use the portal API for screencasting (no dma-buf import in pipewire 0.2), unless you want for it to be significantly slower than using X11 and Xshm. So this API doesn't even work in the current fastest-LTS-cycle distro. > And it's not MIGHT work on anything other than Gnome, it DOES. well, I say that because even thought single-window screencasting now works in Gnome since sometime around last year, when I try to do it on _anything_ else I get a black screen. And turns out because _as of today_ it is not yet implemented for wlr https://github.com/emersion/xdg-desktop-portal-wlr/blob/c34d... This stuff is just way too recent and unstable and changing every day.
In How Not to Support Desktop GNU+Linux, Zoom Edition
jatone·Jan 21, 2022
x11 is no longer maintained. you're thinking of xwayland, which is the only thing getting releases these days. but that is built on wayland. gnome shell has had some version of the screencast API for 8 years now. pipewire is irrelevant to the discussion. https://gitlab.gnome.org/GNOME/gnome-shell/-/blame/main/data... the first commit for the desktop portal (which is the end result of the gnome api above) for wlr was in 2018. https://github.com/emersion/xdg-desktop-portal-wlr/commit/4e... 2 years before the 2020 date in the article. so in short: in 2020 zoom abused a gnome only api to implement desktop sharing, when a proper gnome only desktop sharing api already existed for ~8 years. which was the precursor to the current desktop portal stuff and you're trying to blame wayland for the problem.
In How Not to Support Desktop GNU+Linux, Zoom Edition
danshick·Jun 8, 2020
WebRTC (firefox and chrome) can (usually) stream individual XWayland windows using the same mechanism that was in place for window sharing under X. Wayland native apps are not shareable (and may not be if/until some protocol changes are introduced). I hope that fullscreen desktop sharing "just works" now that we've released xdg-desktop-portal-wlr[0]. If you have any trouble with it, hit me up on freenode #sway or raise an issue on this project. We're happy to help and looking for a broader user base to help us test it out. [0] https://github.com/emersion/xdg-desktop-portal-wlr
In Running Linux on My MacBook
lvh·Apr 1, 2020
If you're running a modern Linux desktop you're probably running Wayland, and screencasts on that have long since been a complete pain in the neck with per-compositor "solutions" that mostly don't work quite right. Fortunately someone who works on Gnome wrote the obs-xdg-portal plugin that should fix this, at least for Gnome and hopefully soon for wlroots and KDE once they fully support the underlying portal API. Until then, the easiest way to get screencasting working is just to run in X11. (Ask me about ffmpeg raw GPU buffer capture one day; running a bunch of codec code as root is always exciting.) OBS Plugin: https://gitlab.gnome.org/feaneron/obs-xdg-portal/ For GTK: https://github.com/flatpak/xdg-desktop-portal-gtk For KDE: https://github.com/KDE/xdg-desktop-portal-kde For wlr: https://github.com/emersion/xdg-desktop-portal-wlr
In OBS Studio: Open-source software for video recording and live streaming
MayeulC·Jan 29, 2020
TL;DR: make sure you have pipewire and xdg-desktop-portal installed, look up how to enable pipewire for your browser. It might help. Well, this blog post barely scratches the surface. The Linux userspace display stack is currently undergoing a big overhaul, following the changes that happened in the kernel a few years ago (DRI3, KMS, atomic modesetting, etc). All of this made Wayland possible. That, plus the fact that apps rasterize their surfaces themselves nowadays (GPU-accelerated trough OpenGL/Vulkan). So, here comes Wayland with a new security model: you can't spy on other windows, so you cannot hack together a desktop sharing solution. A proper, cross-desktop solution is actually being worked on: pipewire[1]. Pipewire aims to replace both pulseaudio and jack for audio, and bring video in as well. So you will be able to direct which
Read the rest
video feed goes where, use the same webcam for multiple applications, and have applications take a video feed, transform it, and plug it elsewhere. You can see where this is fitting with desktop sharing: one feed per window, one feed per screen, one feed for the whole desktop, plus variants. Want to overlay a webcam? No problem. Everything is backed by Gstreamer for realtime hardware-accelerated video encoding/decoding. And the icing on the cake: Flatpak spearheaded the development of "portals"[2]: cross-desktop interfaces for individual programs to ask the user when accessing restricted resources (like a microphone, or a folder on your computer). So, what's needed here is: * Finish up pipewire and have it shipped on most distributions (should be installed in fedora 31, optional for sound in 32, default for sound in 33) * Have compositors talk to pipewire [3] * Have browsers and other software talk to pipewire [4] * ??? * Profit Good progress is being made on these points, except maybe the last? I expect support to start working out-of-the-box in some distros/browser/compositor combinations in 2020. Actually, support seems further along than I thought it was. But it seems that wlroots-based compositor haven't yet decided to support the xdg screensharing portal, and rely instead on a custom wayland extension. I wouldn't be surprised if such a portal is implemented for those. The main issue here is everyone waiting on everyone else before enabling/implementing it. But it looks like we're 80% there, and it just needs to be enabled in some cases (and pipewire installed). Then it will trickle down to most distros and electrons apps. However, I don't think legacy X apps will be able to continue sharing the desktop (they can still be shared by wayland capture programs, or capture the desktop if they implement the new interface). I guess pipewire might be able to create a virtual webcam for these, though. Valve might be working on their own stack with their "Gamescope" wayland compositor[5], for their streaming solution. And in the end, this should work much better, with hardware encoding, actual security, zero copy, etc. Hopefully there won't be a "next big thing" that breaks everything in just a few years. [1] https://pipewire.org/ [1] https://wiki.archlinux.org/index.php/PipeWire [2] https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm... [2] https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm... [3] http://jgrulich.cz/2018/03/06/screen-sharing-in-plasma-wayla... [3] https://jgrulich.cz/2018/07/04/how-to-enable-and-use-screen-... [3] https://wiki.gnome.org/Projects/Mutter/RemoteDesktop [3] https://www.reddit.com/r/linux/comments/8le7rm/first_steps_f... [3] https://github.com/emersion/xdg-desktop-portal-wlr/issues/1 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1496359 (looks disabled by default at compile time) [4] https://bugs.chromium.org/p/chromium/issues/detail?id=682122 (pipewire disabled in chrome://flags until v81 due to waiting on https://github.com/flatpak/xdg-desktop-portal-gtk/issues/204 "dialog hell" it seems) [4] zoom currently uses a gnome-specific screenshot API as a workaround: https://www.reddit.com/r/swaywm/comments/dr8yld/zoom_screens... [5] https://www.gamingonlinux.com/articles/valve-give-a-little-m...
In The sad state of screen sharing on desktop Linux
jchw·Nov 25, 2019
Good news actually, it's already being worked on. As mentioned, Pipewire is the current leading solution. Upstream WebRTC has experimental support for Pipewire; in Chromium it can be enabled with a flag and in Firefox it can be enabled with a patch or configuration flag (I believe it is supposedly merged, but not sure if stable versions will compile and work with it.) GitHub is down atm but there's also an xdg-desktop-portal implementation for wlroots which should allow for Pipewire clients to run under Sway (I have not tried this personally, so I have no idea if it actually all works in practice yet.) https://github.com/emersion/xdg-desktop-portal-wlr
In Are We Wayland Yet?

Showing the 15 most recent of 16 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.