[SOLVED] Attempting screenshare in Hyprland

wolfdaemon · 2026-01-11 19:12:56

Hi all,

I've been trying to, on-and-off, get Hyprland to be able to screenshare sound and windows/screens. The primary way that I have historically done this on systemd based Linux distributions (OpenMandriva Lx) is via Vesktop.. This has also been an issue with things like attempting to stream or record video on things like OBS.

In Vesktop, when I click the screenshare button in `i3` on XLibre, it simply works now that I am able to launch `pipewire` properly on boot. However, when I switch to Hyprland, when I click the screenshare button on Vesktop, the program simply refuses to open/display the window to display the possible sources for sharing at all. Peculiar.

In an earlier post, I shared that I was able to get Pipewire to work on Hyprland, which from my understanding is what is relied upon for the sound portion of the share for compositors:

wolfdaemon in forum post "How to: Devuan 5 Daedalus an pipewire" at 2025-12-30 18:25:06 wrote:

Hi all,
Wanted to record how I got Pipewire sound working in Hyprland on Devuan 6 Excalibur.
Within /home/$USER/.config/hypr/hyprland.conf:
...
#################
### AUTOSTART ###
#################

# Autostart necessary processes (like notifications daemons, status bars, etc.)
# Or execute your favorite apps at launch like this:

# pipewire on devuan openrc (after installing pipewire-audio)
exec-once = wireplumber &
exec-once = pipewire &
exec-once = pipewire-pulse &
...
Obviously, this is based on OP's initial post/script. Thanks OP.
---
NOTE: For whatever reason, screensharing isn't working. I've been trying to look at the pipewire article on the Gentoo wiki (I'm using OpenRC), and the screensharing article on the Hyprland wiki to see what I can experiment with. Previously on OpenMandriva Lx (systemd distro) where Pipewire was working OOTB. Now that I have Pipewire launching, I'm curious what exactly is missing here where I can't screenshare.
Pipewire article - Gentoo wiki wrote:
Note:
Wayland systems use PipeWire to provide desktop portal functionality such as screen sharing and remote desktop.
I think it might have to do with this "xdg-desktop-portals" thing.
Curious when Xlibre is working on my system again if that will still be the case.

I've been trying to further experiment, but I'm stuck.

In short, here are some relevant notes that could indicate the source of what the solution may be:

1. Created the scripts that the pipewire article on the Gentoo wiki suggests
2. Attempted to follow the GitHub Gist the Hyprland wiki (linked above) suggested
3. One output I do get whenever I stop Hyprland and get booted back into the TTY is the following:

dconf-WARNING **: 12:34:41:884: failed to commit changes to dconf: Cannot autolaunch without X11 $DISPLAY

One thing I've seen suggested on the net a lot is to do something like the following:

export DISPLAY=:0

I do not see a change as a result of this, at least from my understanding.

wolfdaemon · 2026-04-07 13:41:37

Somehow this morning, randomly by happenstance, cobbled together a set of commands that enables the user to share the screen in Vesktop on Hyprland in Devaun on top of the existing configurations elaborated on in the original post. Sharing this solution with the community in case it's helpful for others:

Export the necessary environment variables

Setting these variables ensure that Hyprland and Wayland-based applications are properly identified and can function correctly on your Devuan system.

export XDG_CURRENT_DESKTOP=Hyprland
export XDG_SESSION_TYPE=wayland
export MOZ_ENABLE_WAYLAND=1

Launch Hyprland with D-Bus session

The dbus-run-session command is used to start a new D-Bus session, which is necessary for Hyprland to communicate with other system services. The -- separates the dbus-run-session command from the hyprland command, ensuring that Hyprland is executed as the main process:

⚠️IMPORTANT
Ensure you have xdg-desktop-portal-hyprland installed with:
apt install xdg-desktop-portal-hyprland

Launch Hyprland with:

dbus-run-session start-hyprland

By including these commands in your startup or session configuration, you should be able to run Hyprland on your Devuan system and share the screen as desired.

Turning on screenshare in Vesktop

Launch Vesktop (I have the .deb version of the package installed), enter a voice chat, then click Share Your Screen. When the screensharing popup window appears, check Allow a restore token, then click the desired source to stream from.

Speculation, Documentation, & Help

Can't seem to locate where the information found was sourced from; currently the commentary posted probably isn't the most correct regarding commands or programs do what. Please feel free to correct comment corrections or point newer users to the right direction for any mistakes made causatively in this post.

There's also the official Screen sharing - Hyprland documentation on this topic.

Happy to help!

Last edited by wolfdaemon (2026-04-11 08:40:00)

EDX-0 · 2026-04-11 07:28:20

ya know, instead of managing the pipewire services as exec inside hyprland why not use shed, it provides an implementation of user services and can handle wayland sessions.

https://github.com/eylles/shed

the manpage provides an example for using with sway, my latest shed development related forum post gives some insight on what shed can do and how it may be used for wayland sessions, mind you i got no idea how those are started beyond that the compositor is also the windowing server so it needs to have environment preparation before running, which shed can do
https://dev1galaxy.org/viewtopic.php?pid=63141#p63141

mind you my only frame of refference for wayland stuff is https://wiki.gentoo.org/wiki/Sway#Starting_Sway

but i can guarantee you that in my x11 setup shed is able to perfectly manage pipewire.

ralph.ronnquist · 2026-04-11 08:10:47

didn't you move off github yet?

wolfchar · 2026-04-11 08:28:19

EDX-0 wrote:

Ya know, instead of managing the pipewire services as exec inside hyprland why not use shed, it provides an implementation of user services and can handle Wayland sessions.
https://github.com/eylles/shed

OP from the org account here, it's because I've yet to have heard of it. I've never had to deal with manually managing Pipewire before, so I'm a bit green & lost in that department. Might look into it sometime.

ralph.ronnquist wrote:

didn't you move off github yet?

Real; I myself am doing that, finally.

Last edited by wolfchar (2026-04-11 20:48:10)

EDX-0 · 2026-04-12 00:05:47

i personally keep using github for visibility of my projects, i'm just slow at mirroring everything to other forges like gitlab and codeberg.

colgate · 2026-05-16 15:18:15

Similar setup and issue here, however starting hyprland with dbus-run-session does not solve the issue (in fact it makes it worse by breaking screen recording in OBS, option for pipewire doesnt even show up)

The problem is environment variable DBUS_SESSION_BUS_ADDRESS not being set, this can be fixed by running vesktop with dbus-launch or dbus-run-session but this means you have to launch vesktop from a terminal each time

Would love a more permanent solution

steve_v · 2026-05-16 19:58:53

So, uhh, export the correct bus address? There are about 50 ways to set an environment variable system(or session)-wide.
Something along the lines of:

$ cat /etc/profile.d/zz-env-hacks.sh 

#!/bin/sh
if [ -z "$DBUS_SESSION_BUS_ADDRESS" ]; then
    export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR:-"/run/user/$(id -u)"}/bus"
fi

if [ -z "$XDG_RUNTIME_DIR" ]; then
    export XDG_RUNTIME_DIR="/run/user/$(id -u)"
    if [ ! -d "$XDG_RUNTIME_DIR" ]; then
        mkdir -p "$XDG_RUNTIME_DIR"
        chmod 700 "$XDG_RUNTIME_DIR"
    fi
fi

(or the relevant part thereof) will probably do it, though I don't have a Debian/Devuan install with a GUI to confirm.
Something similar could also go in your users shell profile or some other script that is sourced during hyperland (which I also don't use) startup of course.

EDX-0 · 2026-05-16 22:41:28

as of the release v0.3.0 of shed you can set up 2 files to imitate the x11 dbus activation environment, within the shallow.d subdir of the session config dir put the following in a file named something like dbus-launch.env

if [ -z "$DBUS_SESSION_BUS_ADDRESS" ]; then
    eval $(/usr/bin/dbus-launch --exit-with-session --sh-syntax)
fi

having that in the shallow will allow hyprland to inherit the $DBUS_SESSION_BUS_ADDRESS as part of the environment, then in the env.d subdir we can have dbus-update-activation.env

if [ -n "$DBUS_SESSION_BUS_ADDRESS" ] && \
    [ -x "/usr/bin/dbus-update-activation-environment" ]; then
  # subshell so we can unset environment variables
  (
    # unset login-session-specifics
    unset XDG_SEAT
    unset XDG_SEAT_PATH
    unset XDG_SESSION_ID
    unset XDG_SESSION_PATH
    unset XDG_VTNR

    # tell dbus-daemon --session (and systemd --user, if running)
    # to put the session's environment in activated services'
    # environments
    dbus-update-activation-environment --verbose --systemd --all
  )
fi

that is outright a copy of the /etc/X11/Xsession.d/95dbus_update-activation-env file that debian provides for x11 sessions.

colgate · Yesterday 20:51:01

Progress, mabye? I dont know anything about dbus sorry and this doesnt seem to be a common issue online

In hyprland.conf (only one user on machine so i left it constant):

env = DBUS_SESSION_BUS_ADDRESS,unix:path=/run/user/1000/bus

echo $DBUS_SESSION_BUS_ADDRESS:

unix:path=/run/user/1000/bus

Running vesktop from terminal gives the following:

Checking for beta autoupdate feature for deb/rpm distributions
Found package-type: deb
Checking for update
Vesktop v1.6.5
Disabled Chromium features: WinRetrieveSuggestionsOnlyOnDemand, HardwareMediaKeyHandling, MediaSessionService
[16941:0518/214416.593666:ERROR:dbus/bus.cc:406] Failed to connect to the bus: Failed to connect to socket /run/user/1000/bus: Connection refused
[16941:0518/214416.593748:ERROR:dbus/bus.cc:406] Failed to connect to the bus: Failed to connect to socket /run/user/1000/bus: Connection refused
[16941:0518/214416.670196:ERROR:dbus/object_proxy.cc:573] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path= /org/freedesktop/DBus: unknown error type: 
[16941:0518/214416.670229:ERROR:dbus/object_proxy.cc:573] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path= /org/freedesktop/DBus: unknown error type: 
[16941:0518/214416.670286:ERROR:dbus/bus.cc:406] Failed to connect to the bus: Failed to connect to socket /run/user/1000/bus: Connection refused
[16941:0518/214416.670302:ERROR:dbus/bus.cc:406] Failed to connect to the bus: Failed to connect to socket /run/user/1000/bus: Connection refused
[16941:0518/214416.670582:ERROR:dbus/object_proxy.cc:573] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path= /org/freedesktop/DBus: unknown error type: 
libva error: /usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so init failed
[17015:0518/214416.677568:ERROR:media/gpu/vaapi/vaapi_wrapper.cc:1627] vaInitialize failed: operation failed
[16941:0518/214416.700882:ERROR:dbus/object_proxy.cc:573] Failed to call method: org.freedesktop.DBus.NameHasOwner: object_path= /org/freedesktop/DBus: unknown error type: 
[16941:0518/214416.701982:ERROR:dbus/bus.cc:406] Failed to connect to the bus: Failed to connect to socket /run/user/1000/bus: Connection refused
[16941:0518/214416.722799:ERROR:content/browser/browser_main_loop.cc:290] Gtk: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
(node:16941) [DEP0169] DeprecationWarning: `url.parse()` behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead. CVEs are not issued for `url.parse()` vulnerabilities.
(Use `vesktop --trace-deprecation ...` to show where the warning was created)
[libvesktop::update_launcher_count] Failed to connect to session bus: Could not connect: Connection refused
[libvesktop::update_launcher_count] Failed to connect to session bus: Could not connect: Connection refused
[libvesktop::update_launcher_count] Failed to connect to session bus: Could not connect: Connection refused

(ignore libva, vaapi, gtk and deprecation errors, they also occur when running with dbus-launch)

steve_v · Today 02:50:32

Do you actually have a (session) dbus instance running? How was it started?
The trick is that you want one session bus, and everything in your session to be using the same bus address.
So "DBUS_SESSION_BUS_ADDRESS,unix:path=/run/user/1000/bus" or whatever you are setting the session bus address to needs to be the same as what you passed to dbus-daemon when you started it.

I use OpenRC user services to start (and supervise) dbus-daemon explicitly, so I know that it was launched with '--address ${XDG_RUNTIME_DIR:-"/run/user/$(id -u)"}/bus'. This may not be the case in your setup, which is why I said "Something along the lines of" rather than "copy-paste this".
If you're using dbus-launch, you can a: Manually ensure DBUS_SESSION_BUS_ADDRESS is already set in the environment dbus-launch runs with (and set the same for anything that needs to connect to it) b: Make sure everything that needs to connect to the session bus inherits dbus-launch's environment (since it will set DBUS_SESSION_BUS_ADDRESS itself if it is empty) or c: Use dbus-update-activation-environment as EDX-0 described above.

When you launch applications with dbus-launch or dbus-run-session, you often end up creating a new dbus session just for that application - (so it will start, but it won't be able to do IPC with anything else), or in the case of something like hyprland, starting a session but not propagating the bus address to applications started later (usually because something, like a greeter or launcher, is stripping environment). Launching subsequent applications with dbus-run-session risks starting another isolated dbus session, and you end up back in scenario 1.

man dbus-run-session wrote:

dbus-run-session is used to start a session bus instance of dbus-daemon from a shell script,
and start a specified program in that session. The dbus-daemon will run for as long as the
program does, after which it will terminate.
...
Another use is to run regression tests and similar things in an isolated D-Bus session, to
avoid either interfering with the "real" D-Bus session or relying on there already being a
D-Bus session active
...
The session bus' address is made available to PROGRAM in the environment variable
DBUS_SESSION_BUS_ADDRESS.

Last edited by steve_v (Today 03:22:02)

The officially official Devuan Forum!

#1 2026-01-11 19:12:56