<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) { .. } `
uvos__ has joined #maemo-leste
<uvos__>
Wizzup: we could, but simply exiting sphone unsucessfully achives the same thing for less effort, since the other sphone process will respawn us.
Pali has joined #maemo-leste
Smatkovi has joined #maemo-leste
Smatkovi has quit [Remote host closed the connection]
<Wizzup>
uvos__: ok, much like dsme for most of the other core programs then, that works for me
<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
<Wizzup>
the past few times I touched it it appeared to be turned off
<Wizzup>
yeah, it powers off even when connected to charger, wth
<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
<uvos__>
then again im not sure that there are any senarios where a call would survive pulseaudio dieing in the first place
<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
<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
<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)
<sicelo>
with that upower conf, it's not upower. you can confirm with `upower -d` and ensure under critical-action it says Ignore
<Wizzup>
I can't get to a shell
<Wizzup>
I'll see if my charger suddenly turned flaky since the last 'apt update ; apt upgrade' :p
<sicelo>
so the only remaining battery-related reason to power off would be (1) mce, or (2) just the battery dying completely
<sicelo>
you're still on old mce, so anything happening with new upower is not affecting it
<Wizzup>
well, it's a controlled power off
<Wizzup>
so it's initiated by some software
<Wizzup>
charge-mode says the battery is well in the green
<sicelo>
right. so could be worn-out battery reaching MinVoltage quickly when you enable the display
<Wizzup>
but status applet says 0%
<sicelo>
ah
<Wizzup>
if there a filter for this minvoltage?
<Wizzup>
low pass or so
<sicelo>
there isn't :-)
<sicelo>
and that's why i hate it
<Wizzup>
that's a problem
<Wizzup>
but something must have changed
<Wizzup>
I didn't have these kind of problems before
<Wizzup>
and in any case, never when attached to a charger
<sicelo>
status applet says 0% ... what does /sys/class say?
<Wizzup>
ah, it turned off again before I could reach a terminal
<Wizzup>
I think I'm hosed
<Wizzup>
I'll deal with this later and find another way to congratulate something on their birthday :P
<sicelo>
the older upower didn't report UP_DEVICE_STATE_EMPTY since it would do the estimation itself ...
<Wizzup>
good catch
<Wizzup>
and the || there makes it not care about charger state then
<sicelo>
yup
<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
<Wizzup>
or something else happened, I can investigate a bit later
<Wizzup>
yes, I do think we want that change in any case, but I will also look at the MR
<sicelo>
yeah. actually i think all add more of the charger tests in the MR as well
f_ has quit [Ping timeout: 245 seconds]
f_ has joined #maemo-leste
ceene has quit [Read error: Connection reset by peer]
ceene has joined #maemo-leste
<uvos__>
on d4 i think the kernel also shutsdown
<uvos__>
it tirggers of voltage, the limit is very low
<uvos__>
mce min_voltage could be improved by requireing a couple of reads below the minimum to react, yeah
<Wizzup>
yes, the kernel does it, but with some filter at least
<Wizzup>
iirc
<sicelo>
someday we will need to extend mce/battery-upower so it is responsible for reporting the properties status-applet-battery wants
<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.
<sicelo>
this was there even in older upower
<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
<sicelo>
this ensures we can delay power off due to emergency call for example, something upower won't care about
donihalim_ has joined #maemo-leste
donihalim has quit [Remote host closed the connection]
donihalim_ is now known as donihalim
xmn has joined #maemo-leste
System_Error has quit [Ping timeout: 264 seconds]
<uvos__>
sicelo: well ideally shutdown would just not work when there is an emergency call
<uvos__>
this is trival in systemd, im not sure you can do it in openrc
<uvos__>
currently on leste is only enforced when you ask dsme to shutdown
<uvos__>
mce duplicates it too, but thats just in case you dont use the dsme module
<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.
ceene has quit [Ping timeout: 265 seconds]
System_Error has joined #maemo-leste
_fab has quit [Quit: _fab]
<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
Daanct12 has quit [Quit: WeeChat 4.6.1]
_fab has joined #maemo-leste
<uvos__>
holding an inhibit would be either mces or sphones job imo but thats details
<sicelo>
an inhibit against shutdown is best owned by a 'system-level' component (mce/dsme?) instead of something like sphone
<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
pere has quit [Read error: Connection reset by peer]
pere has joined #maemo-leste
<uvos__>
sicelo: the wrinkel being that the inhibit is held at the session level
<uvos__>
so doing that from a system daemon is contorting yourself a bit
<uvos__>
which is why i suggested sphone
<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
<uvos__>
on the other hand mce should not be a system daemon anyhow
<uvos__>
it almost exculively deals with session level things
<uvos__>
like display brigtness and sutch
<uvos__>
session level mce (which is possible with systemd) would be the ideal place imo
* 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
<uvos__>
sicelo: yeah soulds good, but maybe we could have an apt hook instead
<uvos__>
that makes mce not shutdown while apt is running
<uvos__>
that way it works outside of ham too
<uvos__>
i think the hook could also make apt fail
<uvos__>
if battery is to low at the start
<uvos__>
but not sure
<uvos__>
anyhow ideally this would be at apts level not ham
<freemangordon>
sicelo: this is the commit that makes d4 connect every time on start
pere has quit [Ping timeout: 244 seconds]
<freemangordon>
also, there should be a timer, that closes the connection on timeout, so the must be somethign else goinbg on
uvos__ has quit [Ping timeout: 248 seconds]
pere has joined #maemo-leste
uvos__ has joined #maemo-leste
Twig has joined #maemo-leste
<sicelo>
thanks for the context. Will have a closer look
<sicelo>
or I'm the only one experiencing unusual wlan icon behavior?
<Wizzup>
sicelo: no, I think I have it to
<Wizzup>
too
<Wizzup>
the commit fixes the one problem but introduced another I think
<sicelo>
ah. anyway manually disconnecting then reconnecting works. i'll leave it be for now
<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
arno11 has joined #maemo-leste
<arno11>
sicelo: hehe, in fact vibration is so high on my phone that it works better than a ringtone
<arno11>
so no issue with missed calls so far
<Wizzup>
is this the tonegen thing? I don't think so right
<arno11>
yeah probably not related
<arno11>
Wizzup: no issue on d4 with ringtone btw ?
<sicelo>
Wizzup: i don't believe it's tonegend
<sicelo>
arno11: d4 doesn't have issues. i was daily-driving it for some weeks until the battery went south
<arno11>
ok
<arno11>
under daedalus, right ?
<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 :;
<sicelo>
daedalus, yes
<arno11>
oh, cmt_pulse crashes and restart when the issue happens
<sicelo>
but didn't you find the issue was also there on SIP? or it wasn't?
<arno11>
yes indeed
<arno11>
so maybe the root cause is elsewhere
<Wizzup>
arno11: I will need to check, I always have my phone on silent
<arno11>
ah ok
<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
<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
<arno11>
sounds weird anyway
<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)
<sicelo>
hey! does the person hear your music? :p
_fab has quit [Quit: _fab]
bencoh has quit [Ping timeout: 260 seconds]
<arno11>
apparently not
<sicelo>
would been a fun thing to do :p
<arno11>
yeah
<arno11>
just 1 or 2 alsamixer changes and it works iirc
<sicelo>
what works?
<arno11>
music to the other side
bencoh has joined #maemo-leste
<sicelo>
nice. poor man's IVR system
<sicelo>
no, MOH :-)
uvos__ has quit [Remote host closed the connection]
<arno11>
lol
Livio has joined #maemo-leste
akossh has joined #maemo-leste
<arno11>
sicelo: i found a workaround
<arno11>
call the n900 using general profile, ringtone works, then before answering click on mute ringtone, then answers. seems to work
Livio has quit [Remote host closed the connection]
Livio has joined #maemo-leste
<arno11>
so the problem is maybe with ringtone mute stuff
mkfx has left #maemo-leste [Error from remote client]
<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
<arno11>
i tried again without clicking on ringtone mute btn and it crashed
Twig has quit [Remote host closed the connection]
<arno11>
yeah so i'm able to get general profile working again this way but ringtone works randomly (like in chimaera in fact)
System_Error has quit [Remote host closed the connection]
<arno11>
so there is another issue with sphone apparently and still an unknown issue with ringtone
System_Error has joined #maemo-leste
<arno11>
sorry i meant 'mute ringing' btn
<sicelo>
i understand. it's probably that (because we're slow and near-freezing) we take too long to switch between the profiles
<sicelo>
which is why no-ringtone seems to work better
<arno11>
maybe yeah
akossh has quit [Quit: Leaving.]
<sicelo>
arno11: when you saw cmt_pulse crashing, PA had not crashed?
<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
<sicelo>
ok
<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)
<arno11>
maybe i should try with no ucm and default asound state btw
<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
<arno11>
ok
<arno11>
hmm even if the ringtone doesn't work, i have to click on mute ringing btn to avoid sphone crash (general profile)