Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 824230 - media-video/pipewire audio/video support - IUSE pipewire vs. screencast
Summary: media-video/pipewire audio/video support - IUSE pipewire vs. screencast
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-17 15:37 UTC by Andreas Sturmlechner
Modified: 2022-07-14 13:47 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Sturmlechner gentoo-dev 2021-11-17 15:37:41 UTC
Optional media-video/pipewire support was originally introduced via IUSE screencast, as that was what described its purpose at the time.

As time progressed, predictably the 'IUSE=library' model got used for pipewire, partially overlapping with the meaning of screencast (I guess at least in the case of dev-libs/weston).

Does it make any sense to keep the descriptive 'screencast' separate from 'pipewire', or should it be merged into the latter?
Comment 1 Niklāvs Koļesņikovs 2021-11-17 16:22:00 UTC
Right now it does not make sense, because there's no supported way to disable audio support, meaning that for OpenRC enabling screencast will in fact replace PulseAudio with PipeWire while for systemd the only choice is to have it installed but not used (which allows to use PulseAudio) or the enable PipeWire daemons and replace PulseAudio.

The better news is that it may be possible to have a sound IUSE on media-video/pipewire, which would again make it possible to have PipeWire that only does screencast'ing without replacing PulseAudio daemon. The issue is that I'm not sensing anyone actually being interested in making that happen despite all the talk about how important choice between PipeWire and PulseAudio is.

This would allow for:

screencast? ( media-video/pipewire )
pipewire? ( media-video/pipewire[audio(+)] )

type of dependencies, was there any actual willingness to do it.

And before someone yells they want it, a sound IUSE will require either REQUIRED_USE or rolling bluetooth IUSE into sound, which, I'm sure, will be a tough pill to swallow either way, so think carefully if you actually value the option to use PulseAudio enough to accept such a PR.
Comment 2 Mart Raudsepp gentoo-dev 2021-11-17 16:51:49 UTC
I haven't looked at all the consumers, but feature based IUSE sounds good to me, it's just now the concerns about that then switching your audio daemon potentially as well automagically. If that can't be avoided, explicit IUSE=pipewire might be better.

(In reply to Niklāvs Koļesņikovs from comment #1)
> And before someone yells they want it, a sound IUSE will require either
> REQUIRED_USE or rolling bluetooth IUSE into sound, which, I'm sure, will be
> a tough pill to swallow either way, so think carefully if you actually value
> the option to use PulseAudio enough to accept such a PR.

It requires neither of those things. USE=bluetooth can be a no-op when USE=sound isn't set, so e.g. deps would be:

RDEPEND="sound? ( bluetooth? ( ... ) )"

and meson option could be something like:

-Dbluetooth=$(usex sound $(usex bluetooth enabled disabled) disabled)

which probably can be shortened via meson_feature still but that's an exercise for the doer.
Comment 3 Niklāvs Koļesņikovs 2021-11-17 17:17:43 UTC
Thank you for the example code but both Andreas and Sam are strong proponents of no silent disabling of USE flags (and I do agree with them that it's not cool). I can write and test the PR in probably less than an hour but I want to see that there's actual willingness to accept it, so that it's not yet another hung PR.

In practice what needs to be done is to build PipeWire without ALSA and BlueZ backends (easy) and to not attempt starting pipewire -c pipewire-pulse.conf in the gentoo-pipewire-launcher (probably easiest achieved by leveraging the new /usr/bin/pipewire-pulse binary that we can could just remove during src_install if sound USE flag is disabled and then doing a shell test on whether the binary is available at runtime).
Comment 4 Andreas Sturmlechner gentoo-dev 2021-11-17 17:19:41 UTC
(In reply to Niklāvs Koļesņikovs from comment #1)
> Right now it does not make sense, because there's no supported way to
> disable audio support, meaning that for OpenRC enabling screencast will in
> fact replace PulseAudio with PipeWire
This is already a problem because we have hard-dependencies on media-video/pipewire like gnome-base/gnome-shell or soon kde-apps/krfb (previously kde-apps/krfb[wayland]).
Comment 5 Niklāvs Koļesņikovs 2021-11-17 18:29:54 UTC
Unfortunately everyone agreeing that something is a problem has not so far worked in actually solving the problem. Since you're probably the most adamant opponent to silently disabling USE flags, what is your take on Mart's suggestion to have a sound USE flag that silently disables bluetooth (and either directly disables ALSA backend  or also silently disables alsa IUSE - if it wasn't clear ALSA and Bluez backends are not related to each other in any way).
Comment 6 Andreas Sturmlechner gentoo-dev 2022-07-14 13:14:44 UTC
With media-video/pipewire[sound-server] in place, I consider this bug done.