slack current pipewire script and what is missing

BW-userx · 05-18-2023, 07:40 AM

I found this post when researching this pipewire sound thing
https://www.linuxquestions.org/quest...02#post6328502

in it it states slack has a script (post #2) that does this switch for the user so I ran it; rebooted then got this
[[ /usr/sbin/pipewire-enable.sh ]]

Code:

$ pipewire
[W][00057.564067] mod.rt       | [     module-rt.c:  270 translate_error()] RTKit error: org.freedesktop.DBus.Error.ServiceUnknown
[W][00057.564120] mod.rt       | [     module-rt.c:  637 set_nice()] could not set nice-level to -11: No such file or directory
[E][00057.564912] mod.protocol-native | [module-protocol-:  711 lock_socket()] server 0x563656ef6bb0: unable to lock lockfile '/run/user/1000/pipewire-0.lock': Resource temporarily unavailable (maybe another daemon is running)
[E][00057.564992] pw.conf      | [          conf.c:  574 load_module()] 0x563656ea9600: could not load mandatory module "libpipewire-module-protocol-native": Resource temporarily unavailable
[E][00057.565240] default      | [      pipewire.c:  105 main()] failed to create context: Resource temporarily unavailable

what did I miss, right now I am in Plasma but I use FB, xfce4 etc so it needs to be working or everything, which it should but just stating that for the record.

( as I just found this I have not checked if it is on slack15 too which it prob is)

i got sound, bluetooth but who is running it, pulseaudio? so that script is leaving me to undoing all autostarts starting pulseaudio ijn every desktop/ WM on slack?

Code:

$ pulseaudio
W: [pulseaudio] pid.c: Stale PID file, overwriting.
E: [pulseaudio] socket-server.c: bind(): Address already in use
E: [pulseaudio] module.c: Failed to load module "module-native-protocol-unix" (argument: ""): initialization failed.
W: [pulseaudio] cli-command.c: stat('/etc/pulse/default.pa.d'): No such file or directory
E: [pulseaudio] main.c: D-Bus name org.pulseaudio.Server already taken.
N: [pulseaudio] bluez5-util.c: Could not find org.bluez.BatteryProviderManager1.RegisterBatteryProvider(), is bluetoothd started with experimental features enabled (-E flag)?
E: [pulseaudio] backend-native.c: org.bluez.ProfileManager1.RegisterProfile() failed: org.bluez.Error.NotPermitted: UUID already registered
^Cuserx@slack-curr.org:~

LuckyCyborg · 05-18-2023, 08:12 AM

Please note that the solution chosen (by users and) by Slackware for handling the PipeWire daemons is via XDG autostart, with the use an one of its kind daemon supervisor, which knows to stop those daemons when the user logouts - that's it, the PipeWire daemons was made as systemd services and special care is required.

However, please note that Slackware treats the this XDG autostart feature rather with superficiality, and the single DE which have full support for it is Plasma5.

Also XFCE has support for XDG autostart, BUT inexplicably, the XFCE developers chosen to permit to user to chose what "services" are executed (as they put the things) so IF the user like a Boss chose to execute on startup only the XFCE "services" - in fact the desktop files marked as "XFCE-only", the PipeWire daemons will NOT be started, unless they are manually edited.

Finally, believe it or NOT, any other WM shipped by Slackware has NO support for XDG autostart, BUT there's a solution as described in this post of mine:

https://www.linuxquestions.org/quest...ml#post6430055

It's about a little program named fbautostart (and already present on SBo) which can instructed to run on WM startup scripts for executing the XDG autostart files on any WM.

Yeah, I know, I know, it's complicated, but it's not the PipeWire's fault. It's just that Slackware as usual strives to complicate the users life. For the sake of simplicity, of course.

RE: who runs the Bluetooth stack? It's PipeWire, and you probably interact with it via a special daemon of PipeWire, which is is on-site replacement of the PulseAudio daemon and talks that API.

allend · 05-18-2023, 09:32 AM

Quote:

Finally, believe it or NOT, any other WM shipped by Slackware has NO support for XDG autostart, BUT there's a solution as described in this post of mine:

So in my WindowMaker (first released in 1997) setup, I should be using a third party tool to implement a draft specification (from 2006) to automatically launch an application during startup of the user's desktop environment from information provided by a (hopefully properly formatted) .desktop file placed in an accessible directory in $XDG_CONFIG_DIRS.

Spare me, despite the complication, I will just keep editing ~/GNUstep/Library/WindowMaker/autostart

chemfire · 05-18-2023, 10:02 AM

KDE and XFCE are "environments", so one would expect them to manage aspects of the environment. The other things are "window managers" one would expect them to uh manage windows and to provide the rest of the environment themselves by other means be that some combination .profile, .xintric, rc.scripts, and/or custom stuff.

Expecting some Window Manager (at least one not part of a larger environment) to fully implement FreeDesktop.org specs is like being surprised vim does have "IntelliSense"TM support for your favorite language / framework.