Screensharing not working anymore on Arch Linux with WLR 0.3.0 #117
Comments
|
We added support for a config file and an output chooser. If you only want to share the DP-5 screen, please try to add a configfile to |
|
Not sure if this issue is related, however: I encountered a similar-ish misbehavior. Starting xdg services via systemd-services automatically the error: occured. If I used the manual start however it worked flawlessly. I found your debugging guide above. I tested all the environment variables accordingly. However in step 5 I never got the correct result regarding So I followed your "hint" to add the environment variable directly to the user service I had to restart and re-login for some strange reason because So my question to @emersion would be, is there a chance that xdg fails to recognize the systemd user and system environment variables, e.g. if they are set via systemd-environment.d? Again, manually the start of xdg-desktop-portal-wlr works because all envvars are correctly set in the shell. p.s. I am not sure, but this issue occured in 0.2 as well. I updated in mid debugging. I can try to roll back if you want me to check. |
|
We've struggled to reliably instruct people how to run xdp with the correct environment for a long time. I wrote this wiki page to explain the issue in detail, but I'm afraid even with the TL;DR, it is confusing and not something people are finding when they experience issues. https://github.com/emersion/xdg-desktop-portal-wlr/wiki/systemd-user-services,-pam,-and-environment-variables The wiki page emersion linked to covers more issues, and is more comprehensive, so maybe that will be more helpful for folks. I also like that it gives commands for testing the actual envvars that xdp is aware of. I'm wondering if we can't still do better. Maybe a warning in the README and/or the new man pages. Maybe the wiki documents we have need to be edited/shortened/made clearer/etc. The idea of editing the xdp service definition is not something I would suggest. At bare minimum, I'd override it using |
|
Thanks, @danshick! I admit that I did not look any further through the wiki sites. That's my pity. Excuse me. I know, and that's why I started investigating further initially, that's not the smartest idea to fiddle around with package provided service files manually. They are that way for a reason. I am on your site here. You are referring to the systemd-environment declaration. I've set up all my user environment variables through my Is my assumption wrong, that exactly these user variables should be present when systemd starts my user services, e.g. If not, why fails step 5 of the debug guide and the xdg service misses the important If so, I definitely have not understood the dependencies and inner workings entirely yet. |
|
I would have expected environment variables to be configured correctly if they are present using the show-environment subcommand of systemctl as you suggest. All I can suggest with regards to this is that you triple-check your spelling of all variables and that the values are as intended. Feel free to paste the output of show-environment here. Still, we suggest not using this approach either as it will apply to any shell the user starts. You may only use one shell/wm/etc. but the alternative approach works for all use cases including folks that may also use gnome or kde or others. That involves writing yourself a small wrapper script that you use to invoke sway/river/wayfire/etc. and setting your envvars in that script prior to launching your shell. Then, we suggest exec'ing systemctl to import your environment variables in your sway config like this... |
|
Actually, everyone here seems to have the same issue of the |
|
I'll setup a wrapper later. I am not sure if I understand your:
correctly. Is I removed the environment variable from the service file and it seems to work now as well. However step 5 from the debug guide still empties out. My I tried to thin out the output.
|
|
Importantly WAYLAND_DISPLAY is there (which sway sets itself) and XDG_CURRENT_DESKTOP is there (which you should set in a wrapper script that you use to start sway). Sway does not set XDG_CURRENT_DESKTOP because it was not standardized until 2017 (https://specifications.freedesktop.org/desktop-entry-spec/latest/apes03.html) and some applications (wrongly) insist on a specific value to work correctly, even if that value does not match the window manager/desktop environment/compositor you are using. |
|
@depate Actually I had xdg-desktop-portal-wlr running with just environment.d environment variables: This has been my hack to import the systemd environment variables in the user shell sessions as well: And when I do But still xdg-desktop-portal-wlr.service won't start for me. So I checked the logs and I saw this: Well, well.. this seems to be the reason why I can't share my screen anymore. I tried resetting the failure with: but same behavior. I couldn't start up the screensharing. Hence I tried setting a xdg-desktop-portal-wlr as suggested by @columbarius: ❯ cat .config/xdg-desktop-portal-wlr/config
[screencast]
output_name=
max_fps=30
chooser_cmd="slurp -f %o -o"
chooser_type=simpleThis doesn't work as well.. Before version 0.3.0 everything was fine, with version 0.3.0 it stopped working and I would really like to know why. |
|
@shibumi Can you share the output of Edit: |
|
@danshick Yes, will do, but I need to reboot my laptop because xdg-desktop-portal-wlr somehow managed to crash my dbus and my chromium: brb rebooting |
The chromium monitor chooser remains grey.. and xdg-desktop-portal-wlr seems to ignore my configuration. There is no slurp being activated. |
|
From your logs: xdpw is exiting with an error code because it cannot connect to wayland. It isn't even running long enough to read your config or activate slurp or respond to chromium's d-bus messages. You have If you only want to import the |
|
@danshick After setting It looks like my sway is not setting the WAYLAND_DISPLAY variable oO but when I do Funny. When I execute |
|
It won't be in sway's environment because sway sets this variable, it isn't started with it. I can confirm this on my own system. Edit: a process's environment is fixed once the process is started (unless you use gdb or other hacks) What is likely happening is that xdg-desktop-portal is surviving between sway sessions. If you've added that line to your sway config, try running |
|
@danshick Thank you, Thank you Thank you! This was it! Looks like I forgot to kill my xdg-desktop-portal session. Just out of curiosity, since when is this WAYLAND_DESKTOP variable needed? I never set this before 0.3.0 |
|
There have been no relevant changes to xdpw that would affect this. Maybe sway is handling this differently as of late? Couldn't say for sure but maybe @emersion has some idea. |
|
You mean |
|
Hmmm, that doesn't line up. |
|
Same issue here on two separate machines, went away after downgrading |
|
@sauliusvl quickfix is adding |
Just want to clarify, doing this only helps applications that are launched as systemd user session services. Most people using apps like waybar exec them directly from their sway config, which wouldn't be affected by using this config change. If you do have waybar (or other wayland apps) set up as user services, you definitely do want to consider making this configuration change permanently. It is the only way to ensure that your systemd user session inherits the environment changes that you've set up or that your window manager has made. |
Thanks, this does indeed fix the
yet it only broke after upgrading to 1.6 🤷♂️ |
|
I read that thread today when fixing my issues with screen sharing not working. Just want to add that everything works fine on my setup without:
My setup:
|
|
If your sway session just so happens to initialize It is plausible that the situation you describe is true, but it is unlikely and fragile. I would suggest that you at least call |
Thanks. That's a lot of great info I wasn't aware of. To make it clear in my environment |
Maybe because you have something like
Maybe because you have a login manager?
No, these are completely unrelated things. |
I do. That's in the default Sway config file, so I left it like this.
I do. I use ly. |
Not sure why that is working OOTB for you then. Some people definitely get errors related to xdpw being unable to connect to wayland if they don't have this set in scope for systemd. Maybe your login manager is also managing your env vars for your systemd user session. Not sure. |
|
Archlinux ships a config file with |
Ah, indeed! |
|
I am on Arch Linux. This must have been fixed after my posts. Interesting. EDIT: Ok, I had a glimpse on this. It got submitted into the package 24 days ago: I really would like to know why this is not working for me then and I had to manually include import-environment in my sway configuration?! |
Do you have a line |
|
@robertjk no. |
Then that is the reason, why it doesn't work for you. It's your decision, but it might be good idea to add it. Take a look at example config at |
Helllo,
since the update on xdg-desktop-portal-wlr 0.3.0 screen sharing stopped working for me.
Everything is setup for the tool, but it looks like dbus activation fails.
If I start up wlr manually via: /usr/lib/xdg-desktop-portal -r & /usr/lib/xdg-desktop-portal-wlr -r -l DEBUG -o DP-5
I am able to share my screen, but normally this should start up automatically via dbus, right?
The text was updated successfully, but these errors were encountered: