3 ms·
Yes, Pipewire is at 0.3 today; but that's not a problem. Pipewire has the ambition to replace Pulseaudio, Jack and provide APIs for several other subject, not j
by vetinari 6y ago
Yes, Pipewire is at 0.3 today; but that's not a problem. Pipewire has the ambition to replace Pulseaudio, Jack and provide APIs for several other subject, not just screen grabbing. That's the part that is missing toward 1.0.
Screengrabbing during the last year was even better than what X11 could provide, including the ability for the user to limit the grabbing to display or window. That's something that user cannot have under control in X11.
Pipewire is also not limited to Wayland; it will work with X11 too, so the X11 users won't be abandoned just because there's Wayland support too. Firefox doesn't seem to have problem with it, Chrome has it behind flags. For apps with fast moving releases as these, I don't see any problem with them supporting 0.3 release and when/if there is API breaks, updating it.
Beats not supporting screen sharing under Wayland at all.
- zamadatix 6y agoPipewire is definitely the right path when things are complete but right now you have to build with a beta version of Electron with build flags and rutime flags to use a 0.x version of Pipewire and when you do it currently only presents the option to capture the full screen. I.e. it's not that the tech stack or architecure is the wrong it's simply not done yet and not done to the point it's a bit silly to blame Slack for not enabling it. It's also not the fault of wayland/pipewire/chromium/electron/slack for not all simultaneously releasing working screen sharing but it is a mistake to say you can switch from X11 to <Wayland stack> and not worry about screen sharing. I use pipewire for screen sharing, I like it, but its not a fully baked stack and won't be for some time yet.
- vetinari 6y ago> only presents the option to capture the full screen Are you sure? I'm pretty sure I had two tabs, one for picking displays and other for picking windows. Pretty much like this: https://bug1675764.bmoattachments.org/attachment.cgi?id=9186238 https://bug1675764.bmoattachments.org/attachment.cgi?id=9186...
- zamadatix 6y agoLooking deeper into it (been meaning to anyways) it seems to be the typical Wayland compositor specific issue, and ironically I'm using ddevault's compositor sway. Pipewire doesn't seem to care what you send it but your second window looks to be part of xdg-desktop-portal-gtk if I'm not mistaken. Since I'm using sway/wlroots I need to use xdg-desktop-portal-wlr instead. In the FAQ for this package: "Will this let me share individual windows? No, only entire outputs. It would take significant work in wlroots, and likely a new protocol, to make this possible. A second rendering pass would be required, which would significantly reduce wlroots performance, so this may not be implemented any time soon (or ever). Will this let me share all of my outputs/displays at once? Not yet, no. It will likely never create a single stream that combines all of your outputs, but once we implement better output selection, there is no reason xdpw cannot create multiple simultaneous streams of different outputs." So it looks like I'm shit out of luck for quite a while on sway/wlroots. Looks like Gnome figured it out. Not sure about KDE.
- vetinari 6y agoAh, that explains it. Yes, I'm running Gnome and xdg-desktop-portal-gtk. Thanks for the constructive and informative discussion.
- majewsky 6y agoFor your reference, these are the issues to subscribe to if you're interested in following the discussion as it's taking place: https://github.com/emersion/xdg-desktop-portal-wlr/issues/12 https://github.com/emersion/xdg-desktop-portal-wlr/issues/12 https://github.com/swaywm/wlr-protocols/issues/93 https://github.com/swaywm/wlr-protocols/issues/93