search

pop-os / linux

Pop!_OS fork of https://launchpad.net/ubuntu/+source/linux
Other
111 stars 13 forks source link

Linux 5.17.8 bluetooth suspend fix #140

Closed jackpot51 closed 2 years ago

jackpot51 commented 2 years ago

Brings in https://patchwork.kernel.org/project/bluetooth/list/?series=641172&archive=both&state=* to try to fix https://bugzilla.kernel.org/show_bug.cgi?id=215768

n3m0-22 commented 2 years ago

22.04 suspend with bluetooth device paired

bflanagin commented 2 years ago
linuxgnuru commented 2 years ago

22.04 suspend with paired bluetooth speaker works with kudu6

jackpot51 commented 2 years ago

Please test with the bluez from https://github.com/pop-os/bluez

n3m0-22 commented 2 years ago

Tested with new bluez

Working in all cases:

jackpot51 commented 2 years ago

Cool, now one final question @n3m0-22 - does it work without this PR, or is this kernel change still required?

n3m0-22 commented 2 years ago

This requires further investigation. After trying to run the same tests on the same machines, but with the older kernels 5.17.5 and 5.17.6, I can confirm at least for my hardware the kernel change is necessary. I could not get a single successful suspend.

The new problem started after those tests. Booting back to this new kernel I am seeing issues with suspend again on all the machines. The orpy4 had been running for a few weeks. The other two machines were clean installs as of today. I'll try a few things and report back.

n3m0-22 commented 2 years ago

I think I see what was happening. The combination of the new kernel and the new bluez seems to be necessary to reliably suspend with bluetooth enabled. This is not the same as having a device paired. Upon further testing I noticed the paired device can take quite some time to reconnect after a suspend/resume cycle. This would mean the fwts test are not necessarily valid as they may not be giving the device enough time to reconnect. That would mean it would only be testing the suspend/resume with bluetooth enabled.

I tried testing a different approach with varying degrees of success. I opened the bluetooth panel in setting and waited till the paired device showed as connected. Only after that did I try to suspend. I tried this with the 5.17.5 kernel and the new bluez with no success on any machine. I tried the same thing with this PR and the new bluez. That showed intermittent success and failure. It is defiantly an improvement, but still not fixed, at least for my machines. I think this should be tested in the same way on other hardware to compare results.

leviport commented 2 years ago

@n3m0-22 If you know roughly how long it takes for bluetooth to reconnect, you could change the delay time for fwts like so: 

sudo fwts s3 --s3-min-delay {seconds} --s3-max-delay {seconds} --s3-multiple 150

Obviously it will take much longer to run with larger intervals, so you might want to start with a lower multiple.

n3m0-22 commented 2 years ago

I have tested with sudo fwts s3 --s3-min-delay {seconds} --s3-max-delay {seconds} --s3-multiple 150 on darp6 and orpy4. The trouble is no amount of min or max delay is sufficient. The mouse never reconnects without user interaction. After moving the mouse it usually reconnects after between 5 - 30 seconds. I ran a test with sudo fwts s3 --s3-min-delay 60 --s3-max-delay 60 --s3-multiple 6 to allow enough time to unlock between suspends and move the mouse checking that it had reconnected each time. With the mouse connected the machine starts to suspend and then wakes right back up.

darp6 results results.log

orpy4 results results.log

leviport commented 2 years ago

I bet the mouse goes into standby mode. I wonder if an audio device would be better about automatically reconnecting. Do you have a bluetooth speaker or headset you could test with?

n3m0-22 commented 2 years ago

Yes, I'll give that a try.

n3m0-22 commented 2 years ago

I found a speaker that does not go into standby mode, and reconnects right away. Each machine I try it on has the same issue. It will start to suspend, but the connected paired device seems to keep it awake. They all suspend with bluetooth on and no devices paired, as well as with a device paired but disconnected. I've tested the workaround I found here, and it has solved the issue for me on all machines tested.