Closed hollunder closed 1 year ago
While just restarting the whole portal implementation should work, this is also an issue when the portal is started by bus activation. The better solution would probably be to stop all on PipeWire relying capabilities until the PipeWire socket is available again. @emersion is there a better solution for sth. like that then to register an inotify event? Asking also on #pipewire if there is an official solution to that.
is there a better solution for sth. like that then to register an inotify event?
This is the wrong thing to do. xdpw should exit when the wayland compositor or pipewire does.
Ok, just out of curiosity: The screenshot portal is not depend on PipeWire and thus a screenshot could be interrupted by a restarting PipeWire, even though it would not be affected otherwise. What would be the way to go in the case we want only restart the parts not operable?
Just something I noticed, in case it is relevant. When I restart xdpw OBS becomes totally unresponsive and I have to kill it.
Can't reproduce that. Can you please test it with xdpw build from master und obs 27.2-beta and report if the issue is still present? One way to install obs is the now official flatpak (if you don't want to build the beta yourself):
flatpak remote-add --if-not-exists flathub-beta https://dl.flathub.org/beta-repo/
flatpak install --user flathub-beta com.obsproject.Studio/x86_64/beta
flatpak run --user --branch=beta com.obsproject.Studio
On Arch Linux, xdg-desktop-portal-wlr 0.5.0.
I was playing around with pipewire and noticed that after restarting that OBS would not longer get a picture. It looks to me as if after issuing a
systemctl --user restart pipewire.socket pipewire-pulse.socket
I also need to issue asystemctl --user restart xdg-desktop-portal-wlr.service
.Would it make sense to do this automatically via xdg-desktop-portal-wlr.service?