Bug 2004742

Summary:	Bluetooth headphones fail to reconnect after a successful pairing
Product:	[Fedora] Fedora	Reporter:	giperborey <northernfreevatar>
Component:	pipewire	Assignee:	Wim Taymans <wtaymans>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	35	CC:	agurenko, awilliam, brunovern.a, information, northernfreevatar, wtaymans
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-10-08 20:47:53 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description giperborey 2021-09-15 20:43:55 UTC

Description of problem:
Bluetooth headphones fail to reconnect after a successful pairing. 

Hardware Details:
MB: Asus ROG STRIX B360-I Gaming
BT: Intel 9460/9560
Headphones: Sony WH-1000XM2

Software Details:
kernel-5.14.3-300
pipewire-0.3.35-2
wireplumber-0.4.1-2
bluez-5.61-1
gnome-bluetooth-3.34.5-2
NetworkManager-bluetooth-1.32.10-2

How reproducible:
Always

Steps to Reproduce:
1. Pair headphones
2. Power off headphones
3. Turn on headphones
4. Nothing happens
5. Go to "Settings -> Bluetooth -> WH-1000XM2"
a) click on "Connection" makes switch spinning for several seconds with no result
b) click on "Connection" makes switch spinning for several seconds with no result
c) click on "Connection" connect headphones

Actual results:
Headphones fail to automatically reconnect. Manual reconnect takes at least 3 times of trying before succeeding.

Expected results:
Headphones reconnect automatically.
Manual reconnect works from the first try.

Additional info:
Everything works as a charm on Fedora 34 with following software versions
kernel-5.13.14-200
pipewire-0.3.35-2
bluez-5.61-1
gnome-bluetooth-3.34.5-1
NetworkManager-bluetooth-1.30.6-1

Logs:
(pair headphones):
Sep 15 15:32:33 fedora kernel: input: WH-1000XM2 (AVRCP) as /devices/virtual/input/input32
Sep 15 15:32:33 fedora systemd-logind[919]: Watching system buttons on /dev/input/event24 (WH-1000XM2 (AVRCP))
Sep 15 15:32:42 fedora systemd[1715]: app-gnome-gnome\x2dbluetooth\x2dpanel-4807.scope: Consumed 10.428s CPU time.

(power off headphones):
Sep 15 15:34:05 fedora gsd-media-keys[2220]: Unable to get default sink
Sep 15 15:34:05 fedora wireplumber[2083]: <WpDefaultProfile:0x55eaf7f56880> failed to get current profile on device: pipewire proxy destroyed before finishing

(turn headphones on):
(1-st click on "Connection"):
Sep 15 15:34:59 fedora bluetoothd[900]: profiles/audio/avdtp.c:avdtp_connect_cb() connect to 70:26:05:39:EF:7B: Host is down (112)

(2-nd click on "Connection"):
Sep 15 15:35:06 fedora bluetoothd[900]: profiles/audio/avdtp.c:avdtp_connect_cb() connect to 70:26:05:39:EF:7B: Host is down (112)

(3-rd click on "Connection"):
Sep 15 15:35:09 fedora kernel: input: WH-1000XM2 (AVRCP) as /devices/virtual/input/input33
Sep 15 15:35:09 fedora systemd-logind[919]: Watching system buttons on /dev/input/event24 (WH-1000XM2 (AVRCP))

Comment 1 giperborey 2021-10-04 01:54:46 UTC

Update:
Works only after I do "systemctl --user restart pipewire".

Same:
https://bugzilla.redhat.com/show_bug.cgi?id=2004740#c2

Comment 2 giperborey 2021-10-05 02:07:29 UTC

The issue is tracked here:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1683

Comment 3 giperborey 2021-10-05 14:46:05 UTC

Claimed to be fixed in master:
https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/222

Can't test it yet.

Comment 4 Adam Williamson 2021-10-08 16:35:15 UTC

There's a new wireplumber update now:

https://bodhi.fedoraproject.org/updates/FEDORA-2021-b70755fdc3

which should have the fix, I believe. Can you check that? Thanks!

Comment 5 giperborey 2021-10-08 19:32:47 UTC

wireplumber-0.4.3-1.fc35 fixed the issue for me, thanks!

Comment 6 Adam Williamson 2021-10-08 20:47:53 UTC

OK, that update is pushed stable now, so we can close this.