| uvos | is it tho? arm devices are still a clusterf**k compeard to x86 based ones no? | 00:09 |
|---|---|---|
| uvos | wrt standarization allowing a common kernel to work. | 00:09 |
| uvos | at least its sill that way with cromebooks | 00:10 |
| uvos | is this different? | 00:10 |
| Wizzup | uvos: seems like 5.20 supports it | 00:18 |
| Wizzup | not sure about everything | 00:18 |
| Wizzup | but could potentially be a nice build machine too | 00:18 |
| uvos__ | Wizzup: btw something remains wrong with the call audio registers, when calling via gsm, i have the problem that there is significant gsm interferance on the audio, in android this is not the case. | 09:27 |
| uvos__ | presumably we are leaving a pa on we should not | 09:27 |
| Wizzup | uvos__: hm, possible, we can compare the dumps | 10:48 |
| Wizzup | uvos__: btw, 'pa'? | 10:48 |
| uvos__ | Wizzup: an amp | 10:53 |
| Wizzup | preamp ok | 10:56 |
| freemangordon | ok, there is more than one isseu | 11:08 |
| freemangordon | *issue | 11:08 |
| freemangordon | as soon as ofonod is restartde, there are no more sim plug/unplug events | 11:09 |
| Wizzup | freemangordon: what if you restart ofono again? | 11:16 |
| Wizzup | I've found that sometimes it doesn't even find the modem on restart | 11:17 |
| freemangordon | no matter how many times I restart ofono, it needs reboot to start receive sim events again | 11:17 |
| freemangordon | but lets first fix the parser | 11:17 |
| Wizzup | ok | 11:20 |
| uvos__ | sounds like fun buggyness :P | 11:53 |
| uvos__ | i had a long call yesterday | 11:54 |
| uvos__ | and the modem just dropped from usb during the call | 11:54 |
| uvos__ | call continued however, but there was no further way to interact with it (or end the call) | 11:55 |
| Wizzup | heh | 12:22 |
| freemangordon | tmlind: why is expect_pdu set to TRUE here https://github.com/maemo-leste-upstream-forks/ofono/blob/maemo-ofono/drivers/motorolamodem/sim.c#L80 | 12:51 |
| freemangordon | Wizzup: could you gather n_gsm logs on bionic? I want to see if data ends with \n\r or with \n or with \r :) | 13:28 |
| Wizzup | what kind of logs do you want | 13:31 |
| Wizzup | in particular | 13:31 |
| freemangordon | n_gsm debug=0xff | 13:31 |
| Wizzup | for sim insertion, or just reboot and then the logs until I enter pin, or? | 13:31 |
| freemangordon | yes, just reboot | 13:31 |
| tmlind | freemangordon: hmm worth checking them all if pdu is really needed, worth checking the commit logs too if there might be some comments | 13:34 |
| freemangordon | tmlind: my point is - it seems it expects \n as EOL and \r as end of PDU | 13:35 |
| freemangordon | So far I have seen no multi-line responses, besides yesterday which I cannot repro anymore | 13:36 |
| freemangordon | so, at least for MSIM a line is needed, not PDU | 13:36 |
| freemangordon | IIUC | 13:36 |
| Wizzup | freemangordon: btw -I think- my syslog also has a rule for logging n_gsm traffic to /var/log/maemo but I am not sure now | 13:36 |
| tmlind | freemangordon: yup could be a cut and paste error from sms handling which should use the pdu flag | 13:37 |
| freemangordon | tmlind: ok, but you can never get PDU there as well | 13:37 |
| freemangordon | as there is no '\r' | 13:38 |
| tmlind | multipart messages | 13:38 |
| freemangordon | I understand, but parser can never extract PDU without either '\n\r' or '\n\n' (with your hack) | 13:39 |
| freemangordon | i guess thats why sometimes SMSes get lost | 13:39 |
| tmlind | ok could be | 13:39 |
| tmlind | i'm still using just shell scripts.. | 13:39 |
| freemangordon | tmlind: what about adding '\r' at the end of each frame? | 13:39 |
| freemangordon | in n_gsm that is | 13:39 |
| freemangordon | or maybe there is some modem option to send '\n\r' | 13:41 |
| tmlind | maybe possible to fix up after detecting firmware version or something | 13:42 |
| freemangordon | but where? | 13:42 |
| freemangordon | in ofono it is too late | 13:42 |
| tmlind | the real problem is with ophono though, we are trying to parse packet data with a serial line parser | 13:43 |
| freemangordon | yes, but is it garanteed that tty will send the whole packet at one chunk? | 13:43 |
| tmlind | well n_gsm needs to decode it it first, after that it's packet data | 13:44 |
| freemangordon | ok, but is is guaranteed that read() in ofono will receive the packet at once? | 13:44 |
| tmlind | i think that depends on the fifo state | 13:45 |
| freemangordon | fifo? umm, isn;t it(n_gsm) supposed to receive the whole packet before pushing to userspace? | 13:46 |
| tmlind | only place that would possibly know to append a missing \r is n_gsm.c | 13:46 |
| freemangordon | mhm | 13:46 |
| freemangordon | does it have some quirks? | 13:46 |
| Wizzup | freemangordon: https://paste.villavu.com/raw/7521/ | 13:47 |
| Wizzup | freemangordon: yeah so /var/log/maemo/modem.log should be all gsd_receive_buf and gsm_data_kick messages | 13:47 |
| Wizzup | here: https://paste.villavu.com/raw/7522/ | 13:48 |
| Wizzup | and yes that's my sim id and pin etc but w/e :) | 13:48 |
| freemangordon | ok, it is exactly the same on d4 | 13:49 |
| Wizzup | hm | 13:49 |
| Wizzup | this is for a sim with pin fyi | 13:49 |
| freemangordon | it ends with 0x0a | 13:49 |
| freemangordon | does not matter | 13:49 |
| tmlind | probably the \r and \n differences between firmwares are for incoming sms then | 13:51 |
| freemangordon | could be | 13:52 |
| freemangordon | but at least in MSIM there is no difference | 13:52 |
| tmlind | so did your try parsing MSIM without the pdu flag set? | 13:53 |
| freemangordon | so, lets first set expect_pdu to FALSE; | 13:53 |
| freemangordon | going to | 13:53 |
| tmlind | right | 13:53 |
| * freemangordon is afk for ~15 min | 13:58 | |
| uvos__ | even if there is a a modem option that changes line endings | 14:04 |
| uvos__ | we should not set it, that would most likely break libmoto_ril on android/los | 14:05 |
| tmlind | yup | 14:08 |
| freemangordon | tmlind: yep, works | 14:21 |
| tmlind | freemangordon: great :) probably worth fixing it for the other notifications i used it for too | 14:26 |
| tmlind | sounds like it should be kept for incoming sms only | 14:26 |
| mglbg[m] | What is unclear to me from the wiki, do i need to root a droid4 to get ML on there? Iirc the pmos wiki did mention rooting it, but the ML wiki does not? | 14:33 |
| tmlind | mglbg[m]: rooting is optional if using droid4-kexecboot | 14:37 |
| uvos__ | and installing los to /system would be my reccomended way of rooting :) | 14:39 |
| tmlind | freemangordon: fyi g_at_chat_register using pdu for notifications: ~+CREG=, ~+MSIM=, ~+GCMT=, ~+GSSR=, not using pdu for notifications: ~+RSSI= | 14:42 |
| tmlind | seems all those should be fixed | 14:42 |
| freemangordon | mhm | 14:43 |
| freemangordon | tmlind: but, question is - does we receive PDU for SMSes? | 14:44 |
| freemangordon | or, I shell send multi-part SMS to d4 to test? | 14:44 |
| tmlind | yeah please test both on d4 and bionic with a long multipart sms | 14:46 |
| freemangordon | ok | 14:46 |
| freemangordon | I will fix all other g_at_chat_register() calls | 14:47 |
| freemangordon | to not require PDU | 14:47 |
| tmlind | hmm so presumably we can use non-pdu g_at_chat_register() on the same dlci with a pdu parser.. not sure if those conflict | 14:47 |
| tmlind | ack | 14:47 |
| freemangordon | WTYM pdu parser? at least in case of MSIM no parsing is done, IIUC | 14:48 |
| tmlind | well let's say we add sim read/write support that also uses dlci10 and we get pdus for some commands, not sure if that's the case though | 14:49 |
| freemangordon | ah, I see | 14:49 |
| tmlind | anyways, the issue should go away when switching to ell | 14:49 |
| freemangordon | hmm, | 14:49 |
| freemangordon | do wa already have ell parser? | 14:50 |
| freemangordon | *we | 14:50 |
| tmlind | yeah i think ofono uses that for new modems | 14:50 |
| tmlind | i think grep for ell.h | 14:50 |
| freemangordon | yep, it is there | 14:50 |
| freemangordon | are you going to do that? | 14:51 |
| tmlind | i was, and pavel was, but ran out of steam | 14:51 |
| tmlind | on my infinite list of things to do :) | 14:51 |
| freemangordon | also, I still fail to see how this will fix the missing end-of-packet marker | 14:52 |
| tmlind | see what i pasted yesterday, pdu parser fails to see anything | 14:52 |
| freemangordon | sorry, long backscroll, what do you mean? | 14:53 |
| freemangordon | what exactly that is | 14:54 |
| tmlind | see at_chat_handle_command_response() for resp = strstr(line, p->delimiter); | 14:56 |
| tmlind | oh hmm but so in this case d4 and bionic both use the same delimiter? | 14:57 |
| freemangordon | yes | 14:58 |
| freemangordon | also, again, it is not about command responses | 14:58 |
| freemangordon | but unsol messages | 14:58 |
| tmlind | yeah so no clue then :) | 14:58 |
| freemangordon | it is another story when we send cmd and expect PDU as response | 14:58 |
| tmlind | yup | 14:58 |
| freemangordon | for responses the correct flags are set befor parsing | 14:59 |
| tmlind | why would it work on bionic though? | 14:59 |
| freemangordon | no idea | 14:59 |
| freemangordon | ah, yes | 14:59 |
| freemangordon | because qmimodem also receives notifications about SIM | 14:59 |
| freemangordon | somehow | 14:59 |
| tmlind | on bionic only? | 14:59 |
| freemangordon | I saw on d4 as well | 14:59 |
| tmlind | the qmimodem notification is kicked by this dlci10 MSIM parsing.. | 15:00 |
| tmlind | unless something else also kicks the qmi modem | 15:00 |
| freemangordon | well... no idea | 15:00 |
| tmlind | note how the notifier function just calls mot_qmi_trigger_events() | 15:01 |
| freemangordon | yes | 15:01 |
| freemangordon | anything else? https://pastebin.com/9kTCvQYb | 15:01 |
| tmlind | and that just does a dummy SMSC query to trigger pending qmimodem notifications | 15:01 |
| freemangordon | yeah, taht's another issue | 15:02 |
| tmlind | looks good, let's hope it fixes the issue of lost incoming sms too | 15:02 |
| freemangordon | mhm | 15:03 |
| tmlind | would be nice to switch to using ofono :) it's been on my list for years now.. | 15:03 |
| freemangordon | and you'll have the incentive to port to ell :p | 15:04 |
| tmlind | heh i wish | 15:04 |
| tmlind | should be trivial though (tm) | 15:04 |
| freemangordon | I can do it as well, if you give me some hints what and where has to be done | 15:04 |
| Wizzup | if this stuff now works reliably, I think there's a few other things to tackle, but with the current knowledge it might be easy | 15:05 |
| tmlind | go for it, unlikely i can look into it in the near future | 15:05 |
| tmlind | freemangordon: so few years back we discussed on the ofono list that it should use ell.h | 15:05 |
| tmlind | to get it upstreamed. presumably gatchat is kind of deprecated | 15:05 |
| freemangordon | ok, but ell.h just includes headers | 15:06 |
| freemangordon | l_io_new() ? | 15:07 |
| tmlind | so with ell.h, we'd just implement motmdm read/write functions, skip past the U1234 header and that's about it | 15:07 |
| tmlind | no idea, have not looked at it for a few years now | 15:07 |
| freemangordon | ah | 15:07 |
| freemangordon | ok | 15:07 |
| freemangordon | hmm, tho only one that uses ell in our tree seems to be mbim.c | 15:09 |
| tmlind | ok | 15:10 |
| tmlind | it has command_read_handler() | 15:11 |
| freemangordon | RSSI notifications seems to be parsed as well | 15:15 |
| tmlind | ok great | 15:16 |
| tmlind | fyi, here's the ofono list ell discussion: https://www.mail-archive.com/ofono@ofono.org/msg19568.html | 15:16 |
| freemangordon | ah, so they want to get rid of glib | 15:17 |
| freemangordon | tmlind: I don;t think it has anything to do with the parser | 15:18 |
| tmlind | well i described what we want to do, denis replied: "Example of using ell? See drivers/mbimmodem/*. | 15:19 |
| tmlind | " | 15:19 |
| freemangordon | ok | 15:19 |
| tmlind | so if we want to have our own read/write, we can implement it with ell like mbimmodem | 15:20 |
| freemangordon | ok | 15:21 |
| freemangordon | but still the question - how to detect the packet end? :) | 15:21 |
| tmlind | sounds like that will be only an issue for multipart sms hopefully | 15:21 |
| tmlind | hmm if we see U1234, the previous packet ended :) | 15:22 |
| freemangordon | are we guaranteed that read will always return whole packets? or \n marks the end of the packet? | 15:22 |
| freemangordon | hmm | 15:22 |
| freemangordon | right :D | 15:22 |
| tmlind | not sure, both n_gsm and serdev use fifos | 15:22 |
| freemangordon | ok, I guess I can write something | 15:23 |
| freemangordon | see https://pastebin.com/GdASUGuv | 15:23 |
| freemangordon | long sms from d4 to my n900 with delivery status report | 15:23 |
| freemangordon | going to send long sms back | 15:24 |
| tmlind | hmm is GSSR=64\r really a pdu then? | 15:24 |
| freemangordon | not sure | 15:25 |
| freemangordon | maybe I shall revert your \n hack and see | 15:26 |
| tmlind | maybe it does not matter if we just use it to notify usb qmimodem | 15:27 |
| tmlind | seems we can't parse GSSR content unless it's pdu, but if we do not anyays do it, we could add a comment about it | 15:27 |
| freemangordon | tmlind: https://pastebin.com/3uEahCK6 | 15:28 |
| freemangordon | seems modem combines multipart for us | 15:29 |
| freemangordon | or not | 15:30 |
| tmlind | seems like the parser should use the size in ~+GCMT=116 for parsing the rest of the pdu | 15:30 |
| tmlind | i think 116 is the size | 15:30 |
| freemangordon | looks like | 15:30 |
| freemangordon | doesn;t it do it already? | 15:31 |
| tmlind | these are custom moto commands, well at least some are | 15:31 |
| tmlind | custom moto notifications | 15:31 |
| tmlind | so not sure the pdu parser does much anything for us, i could be wrong | 15:32 |
| freemangordon | https://pastebin.com/MYDvEY9y | 15:33 |
| freemangordon | I don;t think this is the whole sms | 15:33 |
| freemangordon | hmm, it is, maybe | 15:33 |
| tmlind | sms is handled by the usb qmimodem :) | 15:34 |
| tmlind | we just need to kick it | 15:34 |
| mglbg[m] | <uvos__> "and installing los to /system..." <- Allright, any howtos? :) | 15:34 |
| freemangordon | ah | 15:34 |
| freemangordon | well, it seems it works than | 15:34 |
| freemangordon | *then | 15:34 |
| tmlind | should also work for mms too in theory | 15:34 |
| tmlind | that's just a url to operator website to download the xml file from.. | 15:35 |
| freemangordon | besides... if ofono receives SMS while noone listens for it, how is that supposed to work? | 15:35 |
| freemangordon | yes, the whole SMS is received | 15:35 |
| tmlind | motorola qmimodem is hardwired to require sms ack | 15:36 |
| tmlind | ofono writes out the messages to directories from what i recall | 15:36 |
| tmlind | anyways, for notifications on ngsm dlci, if we are not parsing anything, there's no need to use pdu it seems as we just kick the usb qmimodem | 15:38 |
| uvos__ | iirc from implementing sphone you can query ofono for old messages | 15:38 |
| uvos__ | sphone dosent do this atm | 15:38 |
| uvos__ | so if sphone isent running sms will be lost from a user perspective atm | 15:38 |
| tmlind | i think there's a possibility of ofono losing messages between acking and saving still | 15:38 |
| tmlind | i could be wrong | 15:38 |
| freemangordon | yeah, but that's a corner case | 15:39 |
| tmlind | yeah not sure if i remember right | 15:39 |
| tmlind | so care to add a comment to your patch for not using pdu for possible pdu packets for the notifiers? | 15:40 |
| freemangordon | ok | 15:40 |
| tmlind | something like: "As we only notify the usb qmimodem and are not parsing the PDU packet, we do not set the PDU option for g_at_chat_register()" | 15:41 |
| freemangordon | ok | 15:41 |
| tmlind | might save days of hair pulling the next time around :) | 15:41 |
| tmlind | Wizzup noticed w | 15:42 |
| Wizzup | hm? | 15:42 |
| tmlind | some commands activate the usb qmimodem btw :) | 15:42 |
| tmlind | so kudos to him | 15:42 |
| tmlind | otherwise we'd be stuck implementing complete modem support over ngsm | 15:43 |
| Wizzup | :) | 15:43 |
| freemangordon | ok, lemme push what I have done so far | 15:45 |
| tmlind | ok | 15:47 |
| tmlind | so even if we managed to get rid of the pdu option completely with the excuse of just kicking the usb qmimodem, we still have the voice call delimiter for : hack left and the skipping of U1234 | 15:48 |
| tmlind | so the case for ell is still there even without the pdu hacks | 15:49 |
| freemangordon | sure | 15:49 |
| freemangordon | I am good at writing parsers, esp easy ones :) | 15:49 |
| freemangordon | so I may consider writing it | 15:49 |
| tmlind | yeah so the motmdm_read() could just wait until it has the full packet read based on the size | 15:51 |
| Wizzup | I can definitely perform some bigger testing (with logging), just let me know when. some other things to eventually test are picking certain operators and/or scanning for operators | 15:51 |
| Wizzup | ui wise I will fix the network activation icd2 stuff to wait, and then implement some roaming things | 15:52 |
| tmlind | freemangordon: looks like ~+RSSI= notifier actually parses the signal strength so should use pdu i think | 15:52 |
| tmlind | maybe it works without the pdu option too not sure | 15:52 |
| freemangordon | I didn;t change RSSI thingie :) | 15:52 |
| freemangordon | see diff ^^^ | 15:52 |
| tmlind | ok | 15:54 |
| tmlind | did you push out to m-l git? | 15:54 |
| freemangordon | https://github.com/maemo-leste-upstream-forks/ofono/commit/770802824a8975059d555e4b1499a1f6381e2719 | 15:55 |
| freemangordon | Wizzup: could you release for devel? I was not able to grok the versioning in debian/changelog :) | 15:55 |
| Wizzup | ok, will do in 1-2hrs | 15:56 |
| freemangordon | ok | 15:56 |
| Wizzup | (maybe sooner) | 15:56 |
| freemangordon | also, we shall teach pin UI to as a pin when it sees SIM card | 15:56 |
| freemangordon | *to ask | 15:56 |
| Wizzup | it does in the xsession | 15:57 |
| freemangordon | should not be that hard | 15:57 |
| Wizzup | it just comes too late | 15:57 |
| Wizzup | ofono reports 'no pin' when it runs | 15:57 |
| Wizzup | and then later ofono realises it has a pin | 15:57 |
| Wizzup | if you go to settings and then phone | 15:57 |
| freemangordon | no pin or no SIM? | 15:57 |
| Wizzup | you will get the dialog | 15:57 |
| Wizzup | no sim. | 15:57 |
| freemangordon | yes, my point | 15:58 |
| Wizzup | because the modem reports this way later in boot process | 15:58 |
| Wizzup | well it doesn't stay around | 15:58 |
| Wizzup | do you want to run it on dbus signals? | 15:58 |
| uvos__ | on mapphones you can also hotplug sim | 15:58 |
| uvos__ | so the xsession thing makes no sense anyhow | 15:58 |
| freemangordon | we shall listen to dbus events (somewhere) and show pin UI upon SIM arrival | 15:58 |
| freemangordon | uvos__: :nod: | 15:58 |
| Wizzup | so will this run all the time? I hope we can avoid that | 15:59 |
| freemangordon | what is this? dbu listener? | 15:59 |
| freemangordon | *dbus | 15:59 |
| Wizzup | yes | 15:59 |
| freemangordon | why not | 15:59 |
| Wizzup | ram? | 15:59 |
| Wizzup | we could maybe use dbus-scripts for this | 15:59 |
| freemangordon | no, hildon-status-menu plugin | 16:00 |
| freemangordon | we already have on there | 16:00 |
| uvos__ | sphone also could do it | 16:00 |
| freemangordon | for connection status | 16:00 |
| uvos__ | it has to deal with this stuff anyhow | 16:00 |
| uvos__ | if you like | 16:00 |
| freemangordon | uvos__: no, we already have status menu plugin that deals with gsm stuff | 16:00 |
| uvos__ | ok | 16:00 |
| tmlind | freemangordon: commit looks good to me :) thanks for debugging the mystery issue | 16:00 |
| freemangordon | :) | 16:01 |
| freemangordon | tmlind: no, please debug why after ofono gets restarted, no more unsol events arrive :) | 16:01 |
| freemangordon | *now | 16:01 |
| freemangordon | this is something in the kernel | 16:01 |
| freemangordon | uvos__: https://github.com/maemo-leste/connui-cellular/blob/master/status-menu-item/status-item.c | 16:02 |
| freemangordon | we just have to check if pin is required and call PIN ui | 16:03 |
| uvos__ | freemangordon: yeah i know, im just not sure a plugin for a statusbar is the right place to do this kind of stuff | 16:03 |
| uvos__ | seams the wrong process imo | 16:03 |
| uvos__ | like how the volume applet used to do routing.... | 16:04 |
| freemangordon | not really, as this is part of connui-cellular | 16:04 |
| freemangordon | and this is used for GSM stuff | 16:04 |
| tmlind | freemangordon: strange, so no more unsol events in dmesg? | 16:05 |
| freemangordon | yes | 16:06 |
| freemangordon | hmm, we already have connui_cell_security_code_register() | 16:06 |
| freemangordon | Wizzup: what do you think? | 16:06 |
| uvos__ | btw pinui is broken in landscape | 16:07 |
| Wizzup | gimme 10mins sry | 16:07 |
| uvos__ | im sure you noticed | 16:07 |
| uvos__ | (screen size issue) | 16:07 |
| freemangordon | never seen it on any other device but n900 :) | 16:08 |
| freemangordon | but ok, will fix that | 16:08 |
| uvos__ | its some issue with libhildon pushbuttons that when they get streched to far horizontaly they break, i have seen it in serveral apps | 16:10 |
| tmlind | freemangordon: you sure m-l does not do gsm 1 AT+SCRN=0 at some point to stop the unsol messages? | 16:10 |
| freemangordon | it does | 16:10 |
| freemangordon | but isn't that related to RSSI only? | 16:10 |
| tmlind | i guess | 16:11 |
| uvos__ | should we be calling UNSOL=1 after SCRN=1 ? | 16:11 |
| freemangordon | does nto seem to matter | 16:11 |
| tmlind | no idea what UNSOL=1 does if anything | 16:11 |
| freemangordon | :nod: | 16:11 |
| Wizzup | uvos__: yes I know | 16:12 |
| freemangordon | tmlind: just removed the card with SCRN=0 and received MSIM notification | 16:12 |
| tmlind | freemangordon: but don't get it if you restart ofono? | 16:13 |
| freemangordon | put it back, and received MSIM in 6 seconds | 16:13 |
| freemangordon | lemme restart ofono and see | 16:13 |
| freemangordon | nothing | 16:15 |
| freemangordon | there is no more MSIM events | 16:15 |
| freemangordon | *there are | 16:15 |
| freemangordon | a reboot is needed to recover | 16:15 |
| tmlind | in dmesg? | 16:16 |
| freemangordon | nothin | 16:16 |
| freemangordon | g | 16:16 |
| tmlind | what if you use ngsm 10 for the sim? | 16:17 |
| tmlind | anything in dmesg with that? | 16:17 |
| tmlind | need to go out here, bbl | 16:17 |
| freemangordon | ok | 16:17 |
| freemangordon | https://pastebin.com/2R1D34uX | 16:20 |
| freemangordon | tmlind: ^^^ | 16:20 |
| tmlind | so manually typed it still responds fine? | 17:10 |
| freemangordon | mhm | 17:10 |
| tmlind | weird | 17:10 |
| freemangordon | hmm, RSSI callback does not get called | 17:10 |
| tmlind | the pdu issue again? | 17:11 |
| freemangordon | no | 17:12 |
| freemangordon | it is like callback is not registered | 17:12 |
| freemangordon | ummm | 17:14 |
| freemangordon | it is not | 17:14 |
| freemangordon | am I blind? | 17:15 |
| tmlind | some state lingering somewhere from previous ofono run? | 17:15 |
| freemangordon | oh, I saw it | 17:15 |
| freemangordon | I am blind :) | 17:16 |
| tmlind | so what issues remain then? | 17:18 |
| freemangordon | oh, it seems that it does not get registered to the network until I enter the PIN | 17:18 |
| freemangordon | that's why no RSSI callabck is set | 17:19 |
| freemangordon | tmlind: ofono restart missing MSIM events | 17:19 |
| tmlind | ok | 17:20 |
| tmlind | maybe usb qmimodem shutdown clears some setting? | 17:20 |
| freemangordon | well, AFAIK :) | 17:20 |
| freemangordon | yeah, could be | 17:20 |
| tmlind | does offlining the modem also stop RSSI after re-enabled? | 17:21 |
| freemangordon | Wizzup: please, LMK if you are ok if I implement PIN UI call from connui-cellular status menu item? | 17:21 |
| freemangordon | tmlind: RSSI is enabled by SCRN, no? | 17:22 |
| tmlind | sorry i mean MSIM | 17:22 |
| freemangordon | ah, I think no | 17:22 |
| freemangordon | lemme check | 17:22 |
| freemangordon | tmlind: hmm, actually those events come no matter if modem is offline or not, IIUC | 17:23 |
| tmlind | ok | 17:23 |
| freemangordon | I think they come faster if modem is online, but that's another story I guess | 17:24 |
| tmlind | ok | 17:24 |
| freemangordon | maybe related to SCRN | 17:24 |
| tmlind | if there's noting in dmesg for MSIM after restarting ofono, it seems like it's some firmware setting that got somehow changed | 17:24 |
| tmlind | assuming other things work | 17:24 |
| freemangordon | mhm | 17:25 |
| freemangordon | can we dump all parameters somehow? | 17:25 |
| freemangordon | and compare | 17:25 |
| tmlind | maybe qmicli can dump most of the nvram | 17:27 |
| tmlind | oh actually.. tcmdrw should be able to dump the whole nvram | 17:27 |
| tmlind | tcmdrw --all | 17:27 |
| freemangordon | ok, seems having modem online and SCRN enabled leads to SIM plug event being generated in few seconds | 17:28 |
| freemangordon | instead of 2 minutes | 17:28 |
| tmlind | what about just toggle SCRN=1 followed by SCRN=0? | 17:28 |
| freemangordon | if I lock the screen, it sends SCRN=0 | 17:29 |
| freemangordon | mce that is | 17:29 |
| tmlind | i think android suffers from this same issue where it can take a long time to see the sim sometimes | 17:29 |
| Wizzup | freemangordon: around now | 17:29 |
| Wizzup | let me read backlog | 17:29 |
| freemangordon | ok | 17:29 |
| freemangordon | tmlind: even with SCRN=0, unplug is reported almost instantly | 17:30 |
| freemangordon | ugh, plug as well :) | 17:30 |
| freemangordon | seems the key is modem being online :) | 17:30 |
| Wizzup | freemangordon: pin ui already check if pin is required, so you can probably just spawn it | 17:31 |
| freemangordon | mhm | 17:32 |
| freemangordon | I just want to register callback on SIM present event | 17:32 |
| freemangordon | and spawn pin UI | 17:32 |
| Wizzup | sounds fine by me, this is for the applet that shows network tech and such? | 17:33 |
| Wizzup | network signal too | 17:33 |
| freemangordon | mhm | 17:33 |
| freemangordon | that one | 17:33 |
| tmlind | freemangordon: ok interesting | 17:34 |
| freemangordon | Wizzup: who brings modem online ATM? | 17:34 |
| freemangordon | nobody? | 17:34 |
| Wizzup | icd2 | 17:34 |
| Wizzup | but only on network search | 17:34 |
| Wizzup | so you have to go to the network connections and then it will | 17:34 |
| Wizzup | which is a kludge | 17:34 |
| freemangordon | does it care about flight mode? | 17:34 |
| freemangordon | scratch that | 17:35 |
| Wizzup | you wrote the icd2 part | 17:35 |
| Wizzup | I think it reads it, but I don't think it acts on it | 17:35 |
| freemangordon | I think we shall online the modem as soon as possible, during boot, unless flight mode is set | 17:35 |
| Wizzup | yes | 17:37 |
| freemangordon | anyway, going on a ride, please release ofono for -devel if you have time | 17:37 |
| freemangordon | bbl | 17:37 |
| Wizzup | will do now | 17:37 |
| Wizzup | freemangordon: where did you push | 17:39 |
| Wizzup | oh to beowulf-devel | 17:39 |
| freemangordon | mhm | 17:47 |
| Wizzup | it's in repos already | 17:49 |
| buZz | make sure pin UI is just optional :P | 18:22 |
| buZz | i nearly always disable pin on sims | 18:22 |
| uvos | pinui just closes if its triggered and sim is unlock | 18:23 |
| uvos | d | 18:23 |
| uvos | so yeah its "optional" | 18:23 |
| buZz | ah, nice | 18:23 |
| Wizzup | Wow, 256GB microsd cards cost like 30 euro these days | 21:06 |
| Wizzup | freemangordon: I can confirm that the sim is now seen, even with pin | 21:51 |
| Wizzup | on boot on d4 | 21:51 |
| Wizzup | so I booted on my sim with pin on my d4, entered pin, and then tried to activate the context | 21:57 |
| Wizzup | looks like it is timing out | 21:58 |
| Wizzup | I do see some motmdm_voice_get_state: lines | 21:58 |
| Wizzup | those happen often/usually when activating the internet context | 21:58 |
| Wizzup | too bad I didn't have n_gsm debug on | 21:58 |
| Wizzup | will turn that on now | 21:58 |
| Wizzup | maybe it misses the CREG | 22:13 |
| Wizzup | this time it worked, need to try again | 22:13 |
| uvos | yeah microsd cards got crazy cheep | 22:15 |
| uvos | (just as most phones droped the slots.. ahm) | 22:15 |
| Wizzup | would 1tb work in the d4? | 22:15 |
| uvos | i think 2tb is the addressing limmit | 22:16 |
| uvos | but have to check again | 22:16 |
| Wizzup | uvos: btw, there's one more thing I'd like to see fixed in the sphone rtcom code, which is when you get a sms from a random service (i.e. bank or your operator or such) that it picks up the name that the network provides | 22:16 |
| uvos | so yeah | 22:16 |
| Wizzup | I couldn't find that in the code | 22:16 |
| uvos | Wizzup: its ofono | 22:16 |
| Wizzup | I can try to monitor dbus for the value | 22:16 |
| Wizzup | see if ofono passes it | 22:16 |
| Wizzup | I bet it does | 22:16 |
| uvos | ofono passes the line identifier form the netowork directly into sphone | 22:17 |
| uvos | this should be the phone number | 22:17 |
| uvos | but operators can put whatever they like there | 22:17 |
| Wizzup | ok, but what about other fields? | 22:17 |
| uvos | i dont think those sms have a phone number at all | 22:17 |
| Wizzup | I get the number, but the n900/fremantle gets both the number and the the name | 22:17 |
| uvos | at least android cant display it | 22:17 |
| uvos | ok | 22:17 |
| uvos | then idk but ofono gives you no indication | 22:17 |
| Wizzup | I'll check dbus I suppose | 22:18 |
| uvos | so im not sure how sphone should know the difference | 22:18 |
| Wizzup | well, I suspect it will just be in the dbus signal :) | 22:18 |
| uvos | yeah maybe i missed something | 22:18 |
| Wizzup | I don't know of an easy way to trigger it but maybe I can mess with my bank and try to get it to send me a text | 22:18 |
| uvos | easy | 22:18 |
| uvos | just move to a different country | 22:18 |
| uvos | the operator sends you a welcome sms :P | 22:19 |
| Wizzup | hm looks like this time it just took 58s to get the ~+CREG=5,11... | 22:20 |
| uvos | Wizzup: btw you could get the softmodem of ofono going | 22:21 |
| Wizzup | uvos: I suppose I could go to a place near the croatian and bosnian border, it switches there all the time | 22:21 |
| uvos | that might be usefull in other ways too | 22:21 |
| uvos | i got a austrian welcome sms recently, i was >50km away from the border, not sure how that happend | 22:22 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!