[artix-general] [s6] wayland and perhaps pipewire

[Javier]

On 1/20/21 11:29 PM, Jacob Moody via artix-general wrote:
> I currently use sway with s6 and have used pipewire
> for both sharing my screen through firefox with webRTC
> Since it seemed impossible to find good documentation
> online I figured I would put how I got screen sharing
> working in this email if this was a curiosity of yours.
> 
> 1. Install pipewire from pacman
> 2. Install xdg-desktop-portal-wlr(https://github.com/emersion/xdg-desktop-portal-wlr)
> 3. Install the fedora fork of firefox for their wayland patches(fedora-firefox-wayland-bin on the aur)
> 4. Start pipewire in one terminal
> 5. 'XDG_CURRENT_DESKTOP=sway /usr/local/libexec/xdg-desktop-portal -r' in another terminal
> 6. 'XDG_CURRENT_DESKTOP=sway firefox' to start firefox
> 
> With that being said, I haven't run in to any issues with pipewire while running without systemd,
> I think Dudemanguy's assumptions are right in that it only uses systemd for socket activation.

Cool, thanks.  According to [3], FF no longer needs patches though.

>  From what I understand. pipewire is the only way that screen
> sharing will be done with wayland compositors of any kind.
> I imagine that if electron starts getting wayland native builds
> it likewise will be required for screen sharing there.

I'm afraid you're right regarding electron/flutter based apps, if they become waylan native, :(  Hopping not becoming true though.

BTW I thought for general desktop sharing (not app specific like slack or zoom), one could always use wayvnc [1], though now that I read the description ("VNC server for wlroots-based Wayland compositors"), and also looking at [2], it doesn't work for all compositors, except by sway, perhaps wayfire, and other wlroots based compositors.  But any other solution, like the Gnome one mentioned in [2] most probably is based on pipewire, :(  Although my goal was to eventually use kwin, perhaps I'd have to stick with wayfire, if I'm to use wayvnc...

Sounds like you're right though.

> 
> As a fun aside, I did try out replacing pulseaudio with pipewire
> through pipewire's pulseaudio shim and that seemed to work alright,
> just started pipewire from an exec line in sway.conf and
> things seemed to just kinda work(pavucontrol and firefox at least).

Does it mean, that if apps sharing video and audio, for video or audio calls for example, become wayland native, such as slack and zoom, then by definition pipewire's video and audio must be used?  So far I've avoided using pulseaudio, and I'm afraid pipewire's audio looks pretty much like another pulse-audio, :(  It adds a server as well [4], and it's a server per user, instead of a global root one (for several reasons, I don't like this either).  Also, for pulse by default apps, which haven't been tweaked to use alsa instead, one needs to install pipewire-pulse and then make sure the pipewire-pulse.socket is enabled for each user [5], which might require some S6 service assistance any ways.  For plain alsa apps, it seems OK to just install pipewire-alsa, and it sounds easier to tweak pulse by default apps into plain alsa apps, and avoid having to deal with the pipewire-pulse.sockets...

So in the end, it seems some S6 assistance with those sockets might become handy (I guess they need to be created when each user logs in, not sure)...

I don't like these models, :(  But it sounds like when everything is wayland native, there will be no other way, right?  Really sad, at least for me, :(  Not sure if I like the wayland ways now, but Xorg is no more any ways [6], :(

> Thanks,
> Moody

Thanks Moody !

-- 
Javier

[1]  https://aur.archlinux.org/packages/wayvnc
[2]  https://wiki.archlinux.org/index.php/wayland#Remote_display
[3]  https://wiki.archlinux.org/index.php/PipeWire#WebRTC_screen_sharing
[4]  https://wiki.archlinux.org/index.php/PipeWire#Audio
[5]  https://wiki.archlinux.org/index.php/PipeWire#PulseAudio_clients
[6]  https://www.theregister.com/2020/10/30/x_server_lead_maintainer_declares

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.artixlinux.org/archives/artix-general/attachments/20210121/dedbfe2f/attachment-0001.sig>