rinigus | @b100dian: morning! Turned out that suspend difference was down to not having whisperfish running during night. With it running, suspend via kernel or android service had the same stats. | 04:02 |
---|---|---|
rinigus | No visible diff in sleep % nor others | 04:04 |
T42_ | <TheVancedGamer> rinigus: is whisperfish hindering suspend a lot? rockwork doesnt hinder any suspend for me | 04:31 |
T42_ | <TheVancedGamer> It only wakes up on BT communicatiob | 04:32 |
T42_ | <TheVancedGamer> It only wakes up on BT communication (edited) | 04:32 |
rinigus | @TheVancedGamer: it brings single suspend from ~60s to ~30s. there is an impact, but not really unexpected one. what's rockwork - just searching for it doesn't bring immediately any meaningful hits | 05:17 |
T42_ | <TheVancedGamer> rockwork is the smartwatch daemon for pebble watches | 05:18 |
T42_ | <TheVancedGamer> I have perfect suspend with it on FP5 | 05:18 |
rinigus | OK, I see. well, these are not exactly the same :) | 05:25 |
T42_ | <TheVancedGamer> ah, i thought whisperfish was some amazfit daemon | 05:26 |
rinigus | :) | 05:26 |
rinigus | @b100dian: I think I am getting close to finding out reasons behind BT suspend issue. will continue tonight | 05:27 |
Mister_Magister | mal: plot plottens, now my android 14 device stoppe suspending despite me not changing literally anything, couple days after installing and it stops suspending | 17:34 |
T42_ | <b100dian> rinigus: ... 6th daemon to be written for nagara? | 17:53 |
T42_ | <b100dian> interesting that the suspend is bugged by bluebinder, that would explain droid diff | 17:54 |
rinigus | @b100dian: its a nightmare. basically suspend is failing as kernel tries to prepare device for suspend, this makes bluebinder to forward it to BT HAL, which on receiving it opens a wakelock and prevents suspend. | 18:03 |
rinigus | thinking how can we get out of this catch-22 | 18:04 |
Mister_Magister | rinigus: can you fix my suspend while you're at it | 18:05 |
rinigus | Mister_Magister: if it has the same reason, maybe. but I have to still figure out how to get out of it. | 18:07 |
rinigus | for those who are interested - logs at https://github.com/sailfishos-sony-nagara/main/issues/38 | 18:08 |
Mister_Magister | its not the same reason i'm not even sure whats the reason, /sys/kernel/wakeup_reasons/last_resume_reason says, even if what it says is correct or not, -1 misconfigured IRQ 373 qcom,qmp-aop | 18:08 |
Mister_Magister | which is like, what does it even mean | 18:08 |
T42_ | <b100dian> there were some patches to ignore specific wakelock names, maybe we should ignore hal_bluetooth_lock | 18:08 |
Mister_Magister | like i ignore most of the wakelocks on op6 and when it suspends it totally breaks wifi? | 18:09 |
T42_ | <b100dian> rinigus: what about that sibs (Software In-Band Sleep) persist prop, what does it show with bluebinder> | 18:11 |
rinigus | @b100dian: ignoring some wakelocks is not a good idea - they are there for a reason. | 18:12 |
rinigus | sibs - have to check | 18:12 |
T42_ | <b100dian> because I think that prop switches off the behavior of using wakelocks by the bt hal (might mis-remember though) | 18:13 |
rinigus | but it sounds from your description that if you set it to false, sleep is disabled | 18:14 |
rinigus | I'll look into bluez sources and see if I can find where it enables kernel suspend callbacks | 18:15 |
T42_ | <b100dian> like "software" sleep is disabled | 18:17 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!