| sicelo | in the case i have seen, we reach it from the last switch case, PA_CONTEXT_FAILED/default | 00:00 |
|---|---|---|
| uvos | in that case we should probubly just exit sphone | 00:00 |
| uvos | since theres no recovering from that | 00:00 |
| uvos | so yeah thats a bug in sphone, but we also should not get there unless something else is also unhappy | 00:01 |
| sicelo | i was wondering if we reach it because of CONTEXT_FAILED or "PA_CONTEXT_UNCONNECTED" ... because no one's trying to catch that | 00:01 |
| uvos | i think sphone should never trigger PA_CONTEXT_UNCONNECTED | 00:02 |
| uvos | but could be | 00:03 |
| sicelo | but yeah, as we've discussed with arno11, there's most likely something else that causes sphone to reach this state, but at this point we likely can't know what it is. makes sense to fix the sphone side then take it from there | 00:03 |
| uvos | sure | 00:03 |
| uvos | i think PA_CONTEXT_TERMINATED and PA_CONTEXT_FAILED can just exit sphone | 00:04 |
| uvos | since it cant recover from that | 00:04 |
| uvos | and PA_CONTEXT_UNCONNECTED we can just ignore | 00:04 |
| Wizzup | uvos - can't you reconnect to pulseaudio? | 00:38 |
| Wizzup | Isn't that what PA_CONTEXT_TERMINATED would be? | 00:39 |
| sicelo | freemangordon: https://git.maemo.org/leste/libicd-network-wpasupplicant/commit/23a6e250faa178de87f96043b396b17170c58b77 - i can understand the reasoning behind it. however, disconnection can happen at other times as well, e.g. while associating. this seems to be why we now get the blinking wlan icon if we go out of range of a network | 10:02 |
| sicelo | what do you think: (1) we revert that commit, or (2) add more conditions, e.g. ` if (ctx->state == STATE_CONNECTED || ctx->state == STATE_CONNECTING) { .. } ` | 10:03 |
| uvos__ | Wizzup: we could, but simply exiting sphone unsucessfully achives the same thing for less effort, since the other sphone process will respawn us. | 10:34 |
| Wizzup | uvos__: ok, much like dsme for most of the other core programs then, that works for me | 12:10 |
| Wizzup | sicelo: I might be wrong but I feel like my d4 is much more prone to shutting down by itself now when it thinks it has a low battery | 12:12 |
| Wizzup | the past few times I touched it it appeared to be turned off | 12:12 |
| Wizzup | yeah, it powers off even when connected to charger, wth | 12:14 |
| uvos__ | Wizzup: i gues one issue with not handling PA_CONTEXT_UNCONNECTED by trying to reconnect without restartig sphone is that sphone will drop any call that is ongoing | 12:14 |
| uvos__ | then again im not sure that there are any senarios where a call would survive pulseaudio dieing in the first place | 12:15 |
| Wizzup | yes, it's not great, but I think it's fine for now. on fremantle the phone app crashing I think means a reboot of the whole device because they decided it has to be robust | 12:15 |
| Wizzup | sicelo: so I am seeing upower or mce decide to power off even when there is a charger attached, I don't think this should ever happen | 12:15 |
| Wizzup | sicelo: it could be that my d4 powers off for another reason (maybe dsme things some sw crashed, but I think I have the lg disabled) | 12:16 |
| sicelo | with that upower conf, it's not upower. you can confirm with `upower -d` and ensure under critical-action it says Ignore | 12:19 |
| Wizzup | I can't get to a shell | 12:20 |
| Wizzup | I'll see if my charger suddenly turned flaky since the last 'apt update ; apt upgrade' :p | 12:20 |
| sicelo | so the only remaining battery-related reason to power off would be (1) mce, or (2) just the battery dying completely | 12:21 |
| sicelo | you're still on old mce, so anything happening with new upower is not affecting it | 12:21 |
| Wizzup | well, it's a controlled power off | 12:21 |
| Wizzup | so it's initiated by some software | 12:22 |
| Wizzup | charge-mode says the battery is well in the green | 12:24 |
| sicelo | right. so could be worn-out battery reaching MinVoltage quickly when you enable the display | 12:24 |
| Wizzup | but status applet says 0% | 12:24 |
| sicelo | ah | 12:24 |
| Wizzup | if there a filter for this minvoltage? | 12:24 |
| Wizzup | low pass or so | 12:24 |
| sicelo | there isn't :-) | 12:25 |
| sicelo | and that's why i hate it | 12:25 |
| Wizzup | that's a problem | 12:25 |
| Wizzup | but something must have changed | 12:25 |
| Wizzup | I didn't have these kind of problems before | 12:25 |
| Wizzup | and in any case, never when attached to a charger | 12:25 |
| sicelo | status applet says 0% ... what does /sys/class say? | 12:25 |
| Wizzup | ah, it turned off again before I could reach a terminal | 12:26 |
| Wizzup | I think I'm hosed | 12:26 |
| Wizzup | I'll deal with this later and find another way to congratulate something on their birthday :P | 12:26 |
| sicelo | just chmod -x upower then :-) | 12:26 |
| Wizzup | bbiab | 12:26 |
| Wizzup | good idea | 12:26 |
| Wizzup | s/something/someone/ | 12:26 |
| sicelo | i think i know what's happening ... | 12:27 |
| sicelo | https://git.maemo.org/leste/mce/src/branch/master/src/modules/battery-upower.c#L194 ... you are hitting the UP_DEVICE_STATE_EMPTY condition | 12:28 |
| sicelo | not to be bad, but to resolve all this, let's get that review on https://git.maemo.org/leste/mce/pulls/64 completed | 12:29 |
| sicelo | the older upower didn't report UP_DEVICE_STATE_EMPTY since it would do the estimation itself ... | 12:30 |
| Wizzup | good catch | 12:30 |
| Wizzup | and the || there makes it not care about charger state then | 12:30 |
| sicelo | yup | 12:31 |
| sicelo | but for your to hit that so much also suggests the capacity-saving script might not be working for you anymore ... that also would be good to investigate. my battery is toast, so i can't check that myself | 12:39 |
| sicelo | if the script had worked, you would not hit this part of the code, https://git.maemo.org/leste-upstream-forks/upower/src/branch/maemo/daedalus-devel/src/up-device-battery.c#L376 ... which is the only place in upower where UP_DEVICE_STATE_EMPTY gets set on a system battery | 12:45 |
| Wizzup | It would appear that the script probably didn't work given that I also saw 0% in the status applet | 12:52 |
| Wizzup | maybe doing 'apt update; apt upgrade' triggered somethnig that make the script write something strange | 12:53 |
| sicelo | if we're not ready for mce/#64, then a quick workaround/solution would be to change https://git.maemo.org/leste/mce/src/branch/master/src/modules/battery-upower.c#L194 to `if ((upowbat.state == UP_DEVICE_STATE_EMPTY && !mcebat.charger_connected) || ...` | 12:53 |
| Wizzup | or something else happened, I can investigate a bit later | 12:53 |
| Wizzup | yes, I do think we want that change in any case, but I will also look at the MR | 12:53 |
| sicelo | yeah. actually i think all add more of the charger tests in the MR as well | 12:55 |
| uvos__ | on d4 i think the kernel also shutsdown | 13:58 |
| uvos__ | it tirggers of voltage, the limit is very low | 13:58 |
| uvos__ | mce min_voltage could be improved by requireing a couple of reads below the minimum to react, yeah | 13:59 |
| Wizzup | yes, the kernel does it, but with some filter at least | 14:00 |
| Wizzup | iirc | 14:01 |
| sicelo | someday we will need to extend mce/battery-upower so it is responsible for reporting the properties status-applet-battery wants | 14:15 |
| sicelo | currently, they're making different decisions, when some really need to be in sync. to be specific, the low and empty states really need to work the same. right now, applet might notify that battery is completely empty, while mce is chugging along happily. | 14:18 |
| sicelo | this was there even in older upower | 14:18 |
| sicelo | at some point I somewhat with uvos that we shouldn't even have battery stuff in mce. however, having worked on it a bit, I think we just need it in mce always | 14:20 |
| sicelo | this ensures we can delay power off due to emergency call for example, something upower won't care about | 14:21 |
| uvos__ | sicelo: well ideally shutdown would just not work when there is an emergency call | 15:37 |
| uvos__ | this is trival in systemd, im not sure you can do it in openrc | 15:38 |
| uvos__ | currently on leste is only enforced when you ask dsme to shutdown | 15:38 |
| uvos__ | mce duplicates it too, but thats just in case you dont use the dsme module | 15:38 |
| uvos__ | besides low bat shutdown, which i added to mce, mce only uses the battery state to turn on the patterns, which honestly dosent belong in mce, since when the patterns get turned on is a ui descission that belongs in the ui. | 15:42 |
| sicelo | yes, @ systemd. i know about the inhibitor interface, and someday it would be nice for Leste (through dsme perhaps) to use it. it's also available on openrc via elogind | 16:10 |
| uvos__ | holding an inhibit would be either mces or sphones job imo but thats details | 16:55 |
| sicelo | an inhibit against shutdown is best owned by a 'system-level' component (mce/dsme?) instead of something like sphone | 16:59 |
| sicelo | I should check if HAM still cares about battery level ... at least in Fremantle it would refuse to do a system upgrade if battery level was below some threshold | 17:00 |
| sicelo | i see it's commented out for now ... https://git.maemo.org/leste/hildon-application-manager/src/branch/master/src/dbus.cc#L858 :-) | 17:05 |
| uvos__ | sicelo: the wrinkel being that the inhibit is held at the session level | 17:06 |
| uvos__ | so doing that from a system daemon is contorting yourself a bit | 17:07 |
| uvos__ | which is why i suggested sphone | 17:08 |
| sicelo | it can be held anywhere iirc. upower and iio-s-p use it, for example, and it doesn't operate at session, unless i'm mistaken | 17:08 |
| uvos__ | on the other hand mce should not be a system daemon anyhow | 17:08 |
| uvos__ | it almost exculively deals with session level things | 17:08 |
| uvos__ | like display brigtness and sutch | 17:08 |
| uvos__ | session level mce (which is possible with systemd) would be the ideal place imo | 17:09 |
| * sicelo thinks we should restore that enough_battery() check in HAM ... would suck to bork one's system with apt upgrade or dist-upgrade that fails due to system running out of juice | 17:09 | |
| uvos__ | sicelo: yeah soulds good, but maybe we could have an apt hook instead | 17:10 |
| uvos__ | that makes mce not shutdown while apt is running | 17:10 |
| uvos__ | that way it works outside of ham too | 17:10 |
| uvos__ | i think the hook could also make apt fail | 17:11 |
| uvos__ | if battery is to low at the start | 17:11 |
| uvos__ | but not sure | 17:11 |
| uvos__ | anyhow ideally this would be at apts level not ham | 17:11 |
| freemangordon | sicelo: this is the commit that makes d4 connect every time on start | 17:51 |
| freemangordon | also, there should be a timer, that closes the connection on timeout, so the must be somethign else goinbg on | 17:52 |
| sicelo | thanks for the context. Will have a closer look | 18:54 |
| sicelo | or I'm the only one experiencing unusual wlan icon behavior? | 18:55 |
| Wizzup | sicelo: no, I think I have it to | 19:56 |
| Wizzup | too | 19:56 |
| Wizzup | the commit fixes the one problem but introduced another I think | 19:56 |
| sicelo | ah. anyway manually disconnecting then reconnecting works. i'll leave it be for now | 20:05 |
| sicelo | guess i'll look at sphone ... because operating without ringtone is killing me. no idea how it works out for arno11 unless they're constantly looking at the phone :p | 20:06 |
| arno11 | sicelo: hehe, in fact vibration is so high on my phone that it works better than a ringtone | 20:23 |
| arno11 | so no issue with missed calls so far | 20:25 |
| Wizzup | is this the tonegen thing? I don't think so right | 20:31 |
| arno11 | yeah probably not related | 20:31 |
| arno11 | Wizzup: no issue on d4 with ringtone btw ? | 20:32 |
| sicelo | Wizzup: i don't believe it's tonegend | 20:34 |
| sicelo | arno11: d4 doesn't have issues. i was daily-driving it for some weeks until the battery went south | 20:34 |
| arno11 | ok | 20:35 |
| arno11 | under daedalus, right ? | 20:36 |
| sicelo | on N900 it's clearly a bad combination of PA (under sphone control) , cmtspeech (whatever dragons lie in there), and our ant-sized resources :; | 20:36 |
| sicelo | daedalus, yes | 20:36 |
| arno11 | oh, cmt_pulse crashes and restart when the issue happens | 20:41 |
| sicelo | but didn't you find the issue was also there on SIP? or it wasn't? | 20:44 |
| arno11 | yes indeed | 20:45 |
| arno11 | so maybe the root cause is elsewhere | 20:45 |
| Wizzup | arno11: I will need to check, I always have my phone on silent | 20:45 |
| arno11 | ah ok | 20:46 |
| sicelo | arno11: uvos__: btw, last night i ran sphone under gdb for a short time, and i had a BP on ./src/route-pulseaudio.c:sphone_pa_state_callback(). everything was idling, then i either disconnected or connected the charger, which sends an audible notification. at that moment, the BP was hit | 20:50 |
| sicelo | maybe it's expected ... not sure. i would have thought the context is unique to each application, but yeah, not too familiar with PA internals yet | 20:51 |
| arno11 | sounds weird anyway | 20:57 |
| arno11 | hmm...if i play a music through audacious (PA) and call my n900 at the same time with general profile, the ringtone doesn't work but the call works fine with no crash (but ofc remixing makes music playing during the call) | 21:16 |
| sicelo | hey! does the person hear your music? :p | 21:18 |
| arno11 | apparently not | 21:21 |
| sicelo | would been a fun thing to do :p | 21:21 |
| arno11 | yeah | 21:22 |
| arno11 | just 1 or 2 alsamixer changes and it works iirc | 21:25 |
| sicelo | what works? | 21:27 |
| arno11 | music to the other side | 21:28 |
| sicelo | nice. poor man's IVR system | 21:31 |
| sicelo | no, MOH :-) | 21:32 |
| arno11 | lol | 21:42 |
| arno11 | sicelo: i found a workaround | 21:56 |
| arno11 | call the n900 using general profile, ringtone works, then before answering click on mute ringtone, then answers. seems to work | 21:58 |
| arno11 | so the problem is maybe with ringtone mute stuff | 22:01 |
| arno11 | it works 100% of time on my device but now the old issue with ringtone re appears: sometimes the ringtone works, sometimes not lol | 22:02 |
| arno11 | i tried again without clicking on ringtone mute btn and it crashed | 22:04 |
| arno11 | yeah so i'm able to get general profile working again this way but ringtone works randomly (like in chimaera in fact) | 22:07 |
| arno11 | so there is another issue with sphone apparently and still an unknown issue with ringtone | 22:10 |
| arno11 | sorry i meant 'mute ringing' btn | 22:21 |
| sicelo | i understand. it's probably that (because we're slow and near-freezing) we take too long to switch between the profiles | 22:24 |
| sicelo | which is why no-ringtone seems to work better | 22:25 |
| arno11 | maybe yeah | 22:26 |
| sicelo | arno11: when you saw cmt_pulse crashing, PA had not crashed? | 22:37 |
| arno11 | idk, i just figured out cmt_pulse crashed/restarted because i reniced it (for testing) and it was back to default value after sphone crash | 22:40 |
| sicelo | ok | 22:40 |
| arno11 | btw how to explain that things work fine if i click on mute ringing button before answering ? (switching profile seems fast on my device) | 22:42 |
| arno11 | maybe i should try with no ucm and default asound state btw | 22:43 |
| sicelo | probably sphone's PA connection idles a bit when you mute the ringtone ... so we're ready for the soon-to-happen switch to VoiceCall use case | 22:44 |
| arno11 | ok | 22:44 |
| arno11 | hmm even if the ringtone doesn't work, i have to click on mute ringing btn to avoid sphone crash (general profile) | 22:51 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!