Das Problem betrifft meiner Meinung nach nicht pipewire mit pipewire-pulse und wireplumber als sessioin-manager, sondern bluez und den blueman Manager. Ich beschreibe hier mal kurz zusammengefasst den Grund für meine Ausssage:
Wenn ich frisch boote und die Ear-Buds deaktiviert in ihrer Ladebox stecken, sehe ich im XFCE4-Panel nur das Blueman-Applet ohne jegliche Verbindung und pavucontrol mit den Default Surces und Sinks.
Wenn ich nun die Ear-Buds aus ihrer Box nehme, dauert es ein paar Sekunden, dann meldet das Blueman-Applet 1 aktive Verbindung mit folgender Info:
Code: Alles auswählen
Device 3C:F8:A8:B9:CE:A1 (public)
Name: Hama Freedom Light
Alias: Hama Freedom Light
Class: 0x00240404
Icon: audio-headset
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: yes
LegacyPairing: no
UUID: Audio Sink (0000110b-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: Handsfree (0000111e-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: bluetooth:v05D6p000Ad0240
Danach sollte eigentlich alles ok. sein - ist es aber nicht, denn:
pipewire-pulse hat davon nichts registriert - kein HFP-Device, kein mSBC codec, was ich eigentlich konfiguriert habe (in blueman).
Mein Workaround ist ein simpler Befehl in X-term als user=ego:
Code: Alles auswählen
$ bluetoothctl connect 3C:F8:A8:B9:CE:A1
Attempting to connect to 3C:F8:A8:B9:CE:A1
[NEW] Endpoint /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep2
[NEW] Endpoint /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep1
[NEW] Transport /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep1/fd0
Connection successful
Das geht so lange, bis ich die Ear-Buds wieder einpacke und sie damit sofort als "disconnected" von Blueman gemeldet werden. Auch verschwinden die zugehörigen Sources und Sinks aus pavucontrol - auch korrekt - und die zugehörige Desktop-Notification mit "Freedom Light getrennt" poppt auf.
Nur wenn ich die jetzt nach einer Weile wieder auspacke, geht das selbe Spielchen wieder von vorme los.
Als weitere Info habe ich beobachtet, was ins Journal geschrieben wird, wenn ich
Code: Alles auswählen
$ bluetoothctl connect 3C:F8:A8:B9:CE:A1
Code: Alles auswählen
Feb 27 17:25:35 xpc wireplumber[1593]: RFCOMM receive command but modem not available: AT+CHLD=?
Feb 27 17:25:35 xpc wireplumber[1593]: RFCOMM receive command but modem not available: AT+NREC=0
Feb 27 17:25:35 xpc kernel: input: Hama Freedom Light (AVRCP) as /devices/virtual/input/input20
Feb 27 17:25:35 xpc wireplumber[1593]: RFCOMM receive command but modem not available: AT+CGMI?
Feb 27 17:25:35 xpc wireplumber[1593]: Failed to register battery provider. Error: org.freedesktop.DBus.Error.UnknownMethod
Feb 27 17:25:35 xpc wireplumber[1593]: BlueZ Battery Provider is not available, won't retry to register it. Make sure you are running BlueZ 5.56+ with experimental features to use Battery Provider.
Feb 27 17:25:35 xpc Thunar[2732]: thunar-volman: Nicht unterstützter Eingabegerätetyp »(null)«.
Feb 27 17:25:35 xpc systemd-logind[548]: Watching system buttons on /dev/input/event20 (Hama Freedom Light (AVRCP))
Feb 27 17:25:35 xpc Thunar[2737]: thunar-volman: Nicht unterstützter Eingabegerätetyp »/dev/input/event20«.
Beim trennen der Ear-Buds (in die Ladebox stecken) wird im Journal gemeldet (erste Zeile rot):
Code: Alles auswählen
Feb 27 18:54:01 xpc bluetoothd[1552]: src/profile.c:ext_io_disconnected() Unable to get io data for Hands-Free Voice gateway: getpeername: Transport endpoint is not connected (107)
Feb 27 18:54:01 xpc dbus-daemon[537]: [system] Rejected send message, 0 matched rules; type="method_return", sender=":1.63" (uid=1000 pid=1593 comm="/usr/bin/wireplumber") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.54" (uid=0 pid=1552 comm="/usr/libexec/bluetooth/bluetoothd")
Gruß,
Ingo