tmlind | uvos: nice to hear voice calls are getting usable :) did you sort out the power consumption issue you mentioned few days ago with modem? | 06:42 |
---|---|---|
Wizzup | uvos: did you build sphone for -devel? | 12:16 |
parazyd | Yeah | 12:16 |
Wizzup | hm, I don't see any icons | 12:16 |
Wizzup | and I did uprade | 12:16 |
parazyd | 0.1 ? | 12:16 |
Wizzup | it didn't upgrade on apt upgrade | 12:17 |
Wizzup | bbiab | 12:17 |
parazyd | Yes because of wrong version | 12:17 |
parazyd | Remove it with apt and reinstall | 12:17 |
parazyd | In Debian logic 0.06 is > 0.1 so I removed the former from the repos | 12:18 |
Wizzup | parazyd: hm, ok | 13:11 |
Wizzup | uvos: I managed to make a call first attempt, cool | 13:13 |
tmlind | long press on + sign does not seem to work :) | 13:16 |
Wizzup | yeah | 13:16 |
Wizzup | if the phone is locked it doesn't unlock and bring up the window, too | 13:19 |
Wizzup | btw parazyd uvos: maybe the xsession script should use dsme to launch the thing, in case it crashes? | 13:28 |
Wizzup | s/the thing/sphone/ | 13:28 |
parazyd | The thing is it starts sooner than ofono | 13:28 |
parazyd | So something has to be done in that regard | 13:28 |
parazyd | Not sure if dsme is the correct solution | 13:28 |
Wizzup | parazyd: why is that a problem? | 13:29 |
parazyd | What? | 13:30 |
parazyd | The timing or dsme? | 13:30 |
Wizzup | why is it a problem if sphone starts before ofono? | 13:30 |
parazyd | Because currently sphone doesn't start without ofono running and being on dbus | 13:31 |
parazyd | src/ofono.c:112 | 13:32 |
Wizzup | well, that should be fixed I think | 13:33 |
Wizzup | also, what I don't understand, if the xsession just uses dsme to spawn it, it should still be fine, no? | 13:33 |
Wizzup | the timing would be the same | 13:33 |
parazyd | Why not start sphone with openrc instead? | 13:35 |
Wizzup | because that's not how the majority works, and it won't be restart when it crashes then | 13:36 |
parazyd | Why would it crash | 13:36 |
parazyd | I would rather avoid this way of thinking | 13:37 |
parazyd | What has to be done is just start ofono before sphone | 13:37 |
parazyd | Also there's supervise-daemon | 13:37 |
parazyd | And then with openrc you get dependency management for free | 13:38 |
Wizzup | shall we just do that when we eventually, if ever, get rid of dsme? I don't see the point of having multiple ways of doing this | 13:39 |
Wizzup | I'll take a look at what fremantle does for the phone app in a bit, but I'm pretty sure it'll be using dsme | 13:39 |
Wizzup | and sphone should not depend on ofono being running, as it also has to work through restarts | 13:40 |
Wizzup | so that's not a reason to have it depend on ofono in some init script | 13:40 |
parazyd | sphone has a runtime dep on ofono | 13:40 |
Wizzup | no | 13:40 |
parazyd | It can't work without | 13:40 |
Wizzup | in fact sphone can live just fine through ofono restarts | 13:40 |
Wizzup | I already tested that | 13:40 |
parazyd | That's not the issue here | 13:41 |
parazyd | I'm saying you can't start sphone without ofono | 13:41 |
Wizzup | yes, that is a bug | 13:41 |
parazyd | And the dsme approach of having it fail a dozen times until ofono starts is shit | 13:41 |
Wizzup | ? | 13:41 |
Wizzup | nobody is suggesting that? | 13:41 |
parazyd | What then? | 13:42 |
Wizzup | https://github.com/maemo-leste/sphone/commit/b5fdb99695f409d50e70ade69756e5efed812afb#diff-8cef3bb1fe8770e0c473799c7796a61f957fbeba785b46691b07ba145df35947R2 | 13:42 |
Wizzup | if that uses dsme, the timing won't change | 13:42 |
Wizzup | at all | 13:42 |
parazyd | Yeah, so that means it'll keep trying and failing until ofono starts | 13:42 |
parazyd | You can rather use dsme from an initscript and get dependency handling for free | 13:42 |
parazyd | And later on switch it out for supervise-daemon | 13:43 |
Wizzup | why would it keep trying and failing? | 13:44 |
Wizzup | I don't understand this | 13:44 |
Wizzup | the way it is written now, does it crash in your xsession, and just never starts? | 13:44 |
parazyd | Because the xsession runs before ofono | 13:44 |
Wizzup | maybe we should just revisit the conversation once I fix the bug where it needs ofono running to start the app | 13:44 |
parazyd | So the implication is that even with dsme, sphone fails to start N times | 13:44 |
Wizzup | because that's really a bug | 13:44 |
parazyd | By having this in openrc, you can depend on the ofono initscript and have it fail 0 times | 13:45 |
Wizzup | please | 13:45 |
Wizzup | ofono running is *not* a hard dep for the thing to start up | 13:45 |
Wizzup | if it is, it is a bug and we need to fix it | 13:45 |
Wizzup | just try /etc/init.d/ofono stop, then app will keep running np | 13:45 |
parazyd | yes but it's useless | 13:45 |
Wizzup | ??? | 13:45 |
parazyd | e.g. I can't make a call | 13:46 |
Wizzup | yeah, so? | 13:47 |
Wizzup | that has nothing to do with it being a bug that it cannot start when ofono is not running | 13:47 |
Wizzup | by design this should be no problem, and it should just pick up on ofono when it arrives on the bus | 13:47 |
Wizzup | it's entirely unrelated to what the startup looks like | 13:47 |
Wizzup | in any case let's wait for uvos and see what he thinks | 13:48 |
parazyd | actually when I look at the code it's using g_error | 13:48 |
parazyd | This is wrong | 13:48 |
parazyd | Because this calls abort() | 13:48 |
parazyd | Hence the failure | 13:48 |
parazyd | uvos ^ | 13:49 |
uvos | Wizzup: just started working again | 18:09 |
uvos | Wizzup: i gues the blocking takes a while to propogate | 18:09 |
uvos | Wizzup: also ill just get blocked again as soon as the original spammer who i share an ip with gets reported again :\ | 18:09 |
uvos | this isp nat has been the the bane of my existance before :P | 18:10 |
uvos | yeah so the fact that sphone needs ofono to run is accidental-on-purpose | 18:11 |
uvos | so sphone registers lots of handlers for interfaces on dbus for ofono | 18:11 |
uvos | and it only dose this once (now and with the old dbus code) | 18:11 |
uvos | so it dosent work if started later | 18:11 |
uvos | the old code dident exit | 18:12 |
uvos | but it dident work either if ofono was not available | 18:12 |
uvos | now we could/ should improve this | 18:12 |
uvos | but thats the current state | 18:12 |
uvos | parazyd: Wizzup: so openrc should not start user services, it afaik dosent have any real features to support those (unlike systemd) | 18:13 |
uvos | we should thus not start sphone with openrc | 18:13 |
uvos | just like dsme should not be starting system services.... | 18:14 |
uvos | long term we need a real session manager of some kind | 18:14 |
uvos | we could lift one from elsewhere or reduce and ammend (mostly reduce) dsme until its usable as a session manager and dosent do anything else anymore. | 18:15 |
Wizzup | I think dsme makes sense here, we use it in other places, and in the rare case that sphone might crash, it's kinda nice to have it start again, esp if it crashes in the background | 18:15 |
Wizzup | no need to really revisit the dsme discussion again imho, but we can check what fremantle does | 18:15 |
uvos | right dsme makes sense for now | 18:15 |
uvos | but long term dsme needs to be removed from system service invokation | 18:15 |
Wizzup | for me I think that if the phone app crashes in the background, the phone should really try to recover, notify, and if all else fails, maybe reboot or something | 18:15 |
uvos | sure | 18:15 |
uvos | pls not reboot tho | 18:15 |
Wizzup | yeah, ok, but there's no point to revisit it every time :p | 18:15 |
Wizzup | uvos: well if you disable the lg then it won't matter I think | 18:16 |
Wizzup | (for you at least) | 18:16 |
uvos | right | 18:16 |
Wizzup | I managed to get an audio call going with a friend btw | 18:16 |
uvos | nice | 18:16 |
Wizzup | it looked like when I picked up, the vibration did not stop though | 18:16 |
Wizzup | I had to manually mute the vibration | 18:16 |
uvos | hmm | 18:16 |
uvos | ok | 18:16 |
Wizzup | (just giving feedback, you probably know) | 18:16 |
uvos | no | 18:16 |
uvos | worked for me :P | 18:16 |
Wizzup | and audio worked when I set the profile to 'Make a phone call' in pavucontrol | 18:17 |
uvos | right | 18:17 |
uvos | speakerphone only tho | 18:17 |
Wizzup | hm I did earpeace | 18:17 |
uvos | it goes to the speakerphone | 18:17 |
uvos | no matter what you select | 18:17 |
Wizzup | hm, ok | 18:17 |
uvos | this is the kernel problem | 18:17 |
uvos | i have a hack that fixes this in my kernel | 18:17 |
Wizzup | I don't know how nokia does it exactly, but I think a phone call unlocks the phone and locks it again after that | 18:17 |
uvos | but its not something we should/can include | 18:17 |
uvos | Wizzup: mce gets put into call mode | 18:18 |
Wizzup | not quite sure how that is done securely if at all (i have no lock code set on my phone) | 18:18 |
Wizzup | ok | 18:18 |
Wizzup | so mce takes care of it then | 18:18 |
uvos | mce takes care of ti | 18:18 |
uvos | also it takes care of the proximitry screen blanking | 18:18 |
uvos | sphone just dosent tell mce about the ongoing call rn | 18:18 |
uvos | otherwise the mce stuff works allready | 18:18 |
Wizzup | ok | 18:18 |
uvos | oh right the thing with vibration not stopping makes sense | 18:19 |
uvos | this is ofonos fault | 18:20 |
uvos | for some reason the state of the call never changes after its initalized in ofono | 18:20 |
uvos | so a outgoing call is stuck at dialing forever | 18:20 |
uvos | and a incomeing call is stuck at ringing forever in ofono | 18:20 |
uvos | untill the call is hungup | 18:21 |
uvos | then it changes to dissconeccted | 18:21 |
uvos | funny thing | 18:21 |
uvos | this bug existed in 2010 on the htc device too | 18:21 |
uvos | sphone src has a workaround for the outgoing part | 18:21 |
uvos | i gues i never picked up since i implmented vibration | 18:22 |
uvos | tmlind: regarding pm its still broken for me with the modem online | 18:22 |
tmlind | uvos: ok | 18:22 |
uvos | tmlind: but i have made no effort to look into it so ill report when i know more | 18:22 |
tmlind | ok | 18:22 |
uvos | tmlind: regarding asoc | 18:22 |
uvos | tmlind: so i really still dont know what to do about the PGA | 18:23 |
tmlind | ok | 18:23 |
uvos | tmlind: i asked at on the alsa-devel mailing what do in this situation | 18:23 |
uvos | but no replies so far | 18:23 |
uvos | sre also remains mia | 18:24 |
tmlind | heh ok :) so for parsing the /dev/gsmtty1 notifications.. | 18:24 |
tmlind | there needs to be a counter for WAKEUP initialized to 0 | 18:24 |
tmlind | if three WAKEUP instances are seen, alert as it means phone call or sms | 18:24 |
tmlind | but | 18:24 |
uvos | ok | 18:24 |
bencoh | Wizzup: wait, you don't want to unlock phone during phone call? | 18:25 |
uvos | bencoh: we do | 18:25 |
uvos | bencoh: it dosent currently | 18:25 |
tmlind | counter needs to be set back to = -1 if any outgoiong status is seen | 18:25 |
bencoh | oh and iirc, nokia only unlocks phone app | 18:25 |
uvos | bencoh: just inimplemented | 18:25 |
uvos | bencoh: just unimplemented | 18:25 |
bencoh | I don't think you can switch to other apps | 18:25 |
uvos | mce unlocks the deivce (tklock at least) | 18:25 |
Wizzup | bencoh: I don't know how it prevents switching, I never use a lock code on fremantle | 18:26 |
Wizzup | but we'll see I guess :) | 18:26 |
uvos | the nokia phone app is override redirect | 18:26 |
Wizzup | ok | 18:26 |
uvos | its its own lock screen | 18:26 |
Wizzup | clever | 18:26 |
uvos | idk if i want to do this | 18:26 |
uvos | tbh | 18:26 |
uvos | but later anyhow | 18:26 |
uvos | i also dont know what they do if some other app holds a screen grab | 18:27 |
bencoh | yeah | 18:27 |
uvos | cant just not accept the call then | 18:27 |
uvos | so not sure what they do. | 18:27 |
uvos | in this case | 18:27 |
uvos | tmlind: failing this would break pm? | 18:28 |
uvos | tmlind: or what is the context here | 18:28 |
tmlind | uvos: you should see +CIEV notifications on /dev/gsmtty1 for phone status changes | 18:28 |
uvos | what status exactly? in call vs idle? | 18:28 |
uvos | obv rn i have not dealt with gsmtty directly at all | 18:28 |
uvos | since im just using ofono | 18:28 |
tmlind | uvos: incoming call, incoming sms, call status changing to connected and so on | 18:29 |
uvos | ok | 18:29 |
tmlind | so sounds like more +CIEV notifications needs to be parsed in ofono probably | 18:29 |
uvos | and this suspect the handling of this in ofono, or lack thereof relates to the pm problem or the problem that the ofono calls tate dosent change? | 18:29 |
uvos | ok so call state not changeing | 18:29 |
tmlind | yup | 18:29 |
tmlind | and also what to do with WAKEUP events | 18:30 |
uvos | ok | 18:30 |
uvos | who ported ofono to motomdm? | 18:30 |
uvos | or did generic qmi work? | 18:30 |
tmlind | as there are also WAKEUP events for outgoing calls that need to be filtered out when a +CIEV is seen by setting counter to -1 instead of 0.. | 18:30 |
* tmlind ducks | 18:30 | |
uvos | he | 18:31 |
uvos | *hehe | 18:31 |
uvos | ok ill look at the ofono porblems later | 18:31 |
uvos | (sphone and asoc first) | 18:31 |
tmlind | ok | 18:31 |
tmlind | i have not had a chance to get back to ofono for a while.. | 18:31 |
uvos | we also have problems with gprs | 18:32 |
uvos | but that might be Wizzups fault also | 18:32 |
uvos | and not ofonos | 18:32 |
tmlind | but we need to listen to /dev/gsmtty* in ofono for notifications, then trigger qmi notifications for usb | 18:32 |
uvos | ok | 18:32 |
uvos | https://mailman.alsa-project.org/pipermail/alsa-devel/2021-August/188505.html <-- here is alsa-devel email in case some one here is versed in asoc | 18:32 |
tmlind | uvos: fyi, the motmdm related changes are in https://github.com/tmlind/ofono/commits/motmdm | 18:36 |
Wizzup | uvos: I use mdbus2 for gprs, not icd2, and it still fails | 18:36 |
Wizzup | but there might be more to be done somehow, in how I use mdbus2 to talk to ofono, maybe | 18:37 |
parazyd | uvos: In case you missed it, I'm pretty sure you should be using g_critical/g_warning instead of g_error in the code, because g_error does abort() | 18:37 |
uvos | parazyd: right but the abort is on purpose rn because the failure would cause sphone to be in a state where it cant rescive calls but the user dosent know | 18:38 |
uvos | id rather it exits | 18:38 |
uvos | but in reality it should deal with this situation sanely ofc | 18:38 |
Wizzup | sounds like you're on top of things | 18:38 |
tmlind | uvos: you do have those ofono commits from the motmdm branch above, right? otherwise only limited qmi usb functionality will work | 18:42 |
tmlind | uvos: i recall pavel's usb tty changes got merged but that interface is limited and buggy | 18:43 |
uvos | tmlind: i have whatever leste has in its repos | 18:47 |
uvos | tmlind: i gues Wizzup or parazyd knows | 18:47 |
Wizzup | I'm pretty sure we're using the latest from tmlind | 18:47 |
tmlind | hmm i think my most recent branch may have been actually https://github.com/tmlind/ofono/commits/motmdm-serdev-ngsm | 18:48 |
tmlind | Wizzup: is it the upstream-forks ofono or which one? | 18:48 |
Wizzup | our HEAD of your branch is 2b9b5e2553274dde6992edb894712034c27aee82 | 18:48 |
Wizzup | https://github.com/maemo-leste-upstream-forks/ofono-d4 | 18:48 |
Wizzup | and then here | 18:48 |
Wizzup | https://github.com/maemo-leste-upstream-forks/ofono-d4/tree/maemo/beowulf-devel | 18:48 |
tmlind | ok yup that's it | 18:49 |
uvos | hehe tmlind's increasing annoyance at how the motmdm works is apperant in the commit messages | 18:51 |
tmlind | heh yeah :) so on the ofono list we discussed we should just use ell for /dev/gsmtty* handling instead of the legacy g_at stuff | 18:52 |
tmlind | a lot of the issues are related to g_at, and depending of the firmware terminating line breaks are different.. | 18:53 |
uvos | tmlind: btw do you use gprs/umts data on your hacky sway setup? | 18:53 |
uvos | xD @ changeing line breaks | 18:54 |
tmlind | uvos: yeah just used it last weekend, but it seems that caused battery to drain | 18:58 |
uvos | ok script/ dbus calls that you use to set it up might be usefull | 18:59 |
uvos | to compear with what icd dose | 18:59 |
uvos | (and mostly fails) | 18:59 |
tmlind | uvos: i'm pretty sure using data did not used to cause battery drainage after disconnecting | 18:59 |
uvos | tmlind: ok but im mostly worried about data flat out not working most of the time | 19:00 |
tmlind | uvos: well leave wwan0 for voice | 19:00 |
uvos | tmlind: we can look at pm when it works | 19:00 |
tmlind | so wwan0, wwan1 for data, wwan2 works only once don't use, use wwan3 for mms | 19:01 |
tmlind | so again: so wwan0 for qmi and ofono voice, wwan1 for data, wwan2 works only once don't use, use wwan3 for mms | 19:02 |
uvos | ok | 19:02 |
uvos | Wizzup: ^^^ | 19:02 |
Wizzup | hm, I think we use whatever ofono gives us | 19:03 |
tmlind | ofono defaults to wwan0 yeah | 19:03 |
Wizzup | I am not sure if I can tell ofono what interface to use for the context | 19:04 |
Wizzup | will have to check.. | 19:04 |
tmlind | right.. that might be missing | 19:04 |
uvos | whats the reason behind this setup ? | 19:04 |
uvos | do we know? | 19:04 |
tmlind | but no need for ofono to configure data connection? mms connection might be needed from ofono? | 19:04 |
uvos | we would like ofono to abstract data too | 19:05 |
uvos | because we have other devices with different modems.... | 19:05 |
tmlind | yeah, sounds like ofono needs different connections if not supported | 19:05 |
tmlind | mms connection seems like it must be a separate configuration and not usable for internet connection | 19:05 |
Wizzup | so I just get this: | 19:06 |
Wizzup | # mdbus2 -s org.ofono /motmdm_0/context1 org.ofono.ConnectionContext.SetProperty Active true | 19:06 |
Wizzup | [ERR]: GDBus.Error:org.ofono.Error.Failed: Operation failed | 19:06 |
Wizzup | maybe the apn is not configured correctly or something, but usually ofono takes care of that, iiuc | 19:07 |
Wizzup | (it does work in other places, btw, so maybe this is it) | 19:08 |
Wizzup | but apart from the above, it still sometimes just times out | 19:09 |
tmlind | yeah probably it's possible to use wwan0 via ofono for both ofono voice commands and internet. but not for both internet and mmc connection | 19:09 |
Wizzup | what is funny is that when I try to do active the context, I see this in dmesg: | 19:10 |
Wizzup | [21188.396331] mot-mdm6600-codec 4806a000.serial:modem:audio-codec@2: motmdm_voice_get_state: ciev=5,0,6 | 19:10 |
Wizzup | s/active/activate/ | 19:10 |
tmlind | yeah there is a +CIEV on /dev/gsmtty1 for connection status changes too | 19:11 |
tmlind | that's a kernel debug message | 19:11 |
Wizzup | ok, so it's not somehow ending up in the wrong path | 19:11 |
tmlind | Wizzup: rather something is not being parsed in ofono from /dev/gsmtty1 | 19:12 |
Wizzup | ok | 19:12 |
Wizzup | uvos: fwiw sometimes removing (or something else) /var/lib/ofono can help if it's in some weir dstate | 19:13 |
tmlind | uvos: so you want my qmicli commands for a data connection? | 19:13 |
tmlind | uvos: here's a paste of the qmicli commands i use | 19:17 |
tmlind | qmicli -d /dev/cdc-wdm1 --device-open-qmi --uim-get-card-status | 19:17 |
tmlind | qmicli -d /dev/cdc-wdm1 --device-open-qmi --dms-get-operating-mode | 19:17 |
tmlind | qmicli -d /dev/cdc-wdm1 --device-open-qmi '--dms-set-operating-mode=online' | 19:17 |
tmlind | qmicli -d /dev/cdc-wdm1 --device-open-qmi '--device-open-net=net-802-3|net-no-qos-header' --dms-noop | 19:17 |
tmlind | qmicli -d /dev/cdc-wdm1 --device-open-qmi --nas-get-system-selection-preference | 19:17 |
tmlind | qmicli -d /dev/cdc-wdm1 --device-open-qmi '--nas-set-system-selection-preference=umts' | 19:17 |
tmlind | qmicli -d /dev/cdc-wdm1 --device-open-qmi --nas-get-signal-strength | 19:17 |
tmlind | qmicli -d /dev/cdc-wdm1 --device-open-qmi '--wds-start-network=apn=internet' --wds-follow-network | 19:17 |
tmlind | then start dhcp client on wwan1 | 19:20 |
tmlind | i did not have much success configuring stuff in /etc/network/interfaces although it's supposed to work | 19:21 |
tmlind | i tried this with /etc/network/interfaces: | 19:23 |
tmlind | iface wwan1 inet dhcp | 19:24 |
tmlind | pre-up qmi-network --profile=/etc/qmi-internet.conf /dev/cdc-wdm1 start | 19:24 |
tmlind | post-down qmi-network --profile=/etc/qmi-internet.conf /dev/cdc-wdm1 stop | 19:24 |
tmlind | with cat /etc/qmi-internet.conf | 19:24 |
tmlind | APN=internet | 19:24 |
uvos | tmlind: | 19:29 |
uvos | hmm great that works while icd fails at the same time | 19:29 |
uvos | Wizzup: ^^^^ | 19:30 |
Wizzup | uvos: icd or ofono :) | 21:22 |
uvos | true | 22:00 |
uvos | im not assigning blame | 22:00 |
uvos | just describing what i observe :) | 22:00 |
Wizzup | uvos: check :p | 23:15 |
uvos | there sphone now also puts mce into the right mode | 23:56 |
uvos | lightly tested only | 23:56 |
uvos | also proximetry dosent work | 23:56 |
uvos | because of the ofono problems sphone never gets into call state so sphone and mce stay in rinnging mode, the only diff being prox | 23:57 |
uvos | might just work on pp | 23:57 |
uvos | oh and you need to load callstate mce module | 23:57 |
uvos | oh and i have not tested it with tklock only lock-generic so ymmv | 23:58 |
Wizzup | when it is in the right mode, does it still require unlock, or did you make it override? | 23:59 |
Wizzup | (also: exciting) | 23:59 |
uvos | should unlock | 23:59 |
uvos | and lock-generic dose | 23:59 |
uvos | tklock should to | 23:59 |
uvos | but dident test | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!