| Wizzup | uvos: right, thanks | 02:22 |
|---|---|---|
| Wizzup | somehow I keep forgetting that it has no sd card :D | 02:22 |
| Wizzup | (reader) | 02:23 |
| Wizzup | uvos: so what partition did you install leste to? | 04:00 |
| Wizzup | uvos - the tablet should not draw a lot with the screen off through right? | 06:27 |
| Wizzup | uvos - well I guess stesp one is to install kexecboot, see if android still boots, and then take it from there | 06:28 |
| Wizzup | sicelo: if it only works for some operators, maybe the mobile broadband providers is out of date | 06:28 |
| tmlind | Wizzup, uvos: from stock android you can reformat userdata as ext4 with make_ext4fs, then reboot to android and it's ext4 isntead of vfat. this naturally resets the device to defaults | 06:29 |
| tmlind | uvos: got the modem patches rebased, but seeing hangs playing audio on voice, so some issue with the mcbsp tdm with multiple dais i think | 06:30 |
| tmlind | and my mz609 memory issues have gotten so bad i can no longer even copy over files, ordered a mz608 though | 06:31 |
| Wizzup | tmlind: ok, and then put leste on uesrdata? | 06:36 |
| tmlind | Wizzup: yes that way you can share it between android and m-l (unless there's some directory name conflict) | 06:38 |
| Wizzup | probably shouldn't be a conflict, not sure if android will do any crazy stuff to it | 06:39 |
| tmlind | yeah so far no issues here | 06:39 |
| Wizzup | btw, you said there's a hang for audio on voice, is this even hooked up on the tablets | 06:40 |
| Wizzup | tmlind: ok, sounds like I should try this and document it somewhere | 06:40 |
| tmlind | Wizzup: no idea, so far did not get any response on mz617 on the n_gsm serial port from the modem, usb only | 06:40 |
| Wizzup | I would not be super surprised is audio is just not hooked up | 06:41 |
| Wizzup | (would be cool if it was, though) | 06:41 |
| Wizzup | s/is audio/if audio/ | 06:41 |
| tmlind | yeah maybe it is, need to get busy here now, ttyl | 06:44 |
| Wizzup | ttyl! | 06:44 |
| sicelo | Wizzup: no. it's the operator themselves :-) | 07:28 |
| sicelo | seems some operators don't support being queried for name. but they do send it without being prompted. the ofono code only shows it if it's a response to a request, so on such operator, there won't be anything showing | 07:29 |
| sicelo | https://paste.debian.net/1296684/ is a patch i'm working on to workaround that. at line 33, the operator name is saved in `tag` variable. unfortunately, the remainder of the code doesn't actually result in the operator name being propagated correctly through ofono | 07:32 |
| sicelo | so i still need to find correct way to do that. | 07:33 |
| sicelo | the 'normal' code (for when it's a response to a request) seems to use this macro, https://elixir.bootlin.com/ofono/latest/source/drivers/isimodem/network-registration.c#L504 | 07:33 |
| sicelo | oh and the `if` on line 22 doesn't work either ... not sure why, hence i commented it out for the time being | 07:34 |
| sicelo | because ideally i want to only use this codepath only if operator name was not already set by other means | 07:47 |
| sicelo | 08:29 < sicelo> seems some operators don't support being queried for name. but they do send it without being prompted ... oh btw on D4 it works on that 'bad' operator | 07:48 |
| sicelo | so it must be in how the n900 radio does it ... but it's exactly the same raw packet over the wire as that which gets sent when on 'good' operator | 07:56 |
| sicelo | some C help please ... bencoh, freemangordon, Wizzup (sorry for pings) | 11:41 |
| sicelo | https://elixir.bootlin.com/ofono/latest/source/drivers/isimodem/network-registration.c#L504 | 11:41 |
| sicelo | this macro - what are the final/real C statements that end up being run? | 11:42 |
| freemangordon | sicelo: hard to say, because the macro is defined on several places | 11:57 |
| freemangordon | I guess this https://elixir.bootlin.com/ofono/latest/source/drivers/isimodem/isiutil.h#L45 is the one that is used | 11:58 |
| sicelo | i think we can confine ourselves to the isimodem part | 11:58 |
| sicelo | yes, that's the one | 11:58 |
| freemangordon | ofono_netreg_operator_cb_t cb = cbd->cb; | 11:58 |
| freemangordon | so it does 'cb(&e, &op, cbd->data); | 11:59 |
| freemangordon | 'cb(&e, &op, cbd->data);' | 11:59 |
| freemangordon | does that answer your question or you want to know what exactly cb() is? | 12:01 |
| freemangordon | BTW, cb stands for 'callback' | 12:01 |
| sicelo | yes, i would like to know what it is exactly :-) | 12:01 |
| freemangordon | ok, seems to be here https://elixir.bootlin.com/ofono/latest/source/drivers/isimodem/network-registration.c#L511 | 12:01 |
| freemangordon | called from https://elixir.bootlin.com/ofono/latest/source/drivers/isimodem/network-registration.c#L551 | 12:02 |
| freemangordon | and we end up here https://elixir.bootlin.com/ofono/latest/source/drivers/isimodem/network-registration.c#L1172 :) | 12:02 |
| freemangordon | better put breakpoint in name_get_resp_cb() and print *cbd | 12:03 |
| freemangordon | and see which function cbd->cb is | 12:04 |
| sicelo | i had got as far as that line 511... but that confuses me a bit as. the first/original location is ofono processing the network operator name modem responded with, now in 511 we seem to be starting another request ... | 12:04 |
| freemangordon | does that help? | 12:04 |
| sicelo | freemangordon: maybe let me state why i am even trying to understand this macro: | 12:05 |
| freemangordon | "got so far"? like, folowing the source or in gdb? | 12:05 |
| sicelo | source | 12:05 |
| freemangordon | sicelo: forget the macro, it just sets an error if needed and then calls the callback | 12:05 |
| freemangordon | if your results are not ok, you have to check what that callback does | 12:06 |
| freemangordon | the easiest way to see which function is called as a callback is with the debugger | 12:06 |
| sicelo | so let me explain a bit: as far as i understand the code and n900 modem: ofono periodically requests modem/network to provide operator name, https://elixir.bootlin.com/ofono/latest/source/drivers/isimodem/network-registration.c#L511 | 12:07 |
| freemangordon | ok | 12:07 |
| sicelo | when modem/network has the data, it responds here, https://elixir.bootlin.com/ofono/latest/source/drivers/isimodem/network-registration.c#L458 | 12:07 |
| freemangordon | right | 12:08 |
| sicelo | unfortunately, in some cases, the response is not successful (from modem/network end), and ofono doesn't display operator name as a result. that's fine | 12:08 |
| freemangordon | ok | 12:08 |
| sicelo | however, the 'live' operator name is also periodically sent by network without being asked for. it returns it in NET_REG_STATUS_IND, which is unsolicited. https://elixir.bootlin.com/ofono/latest/source/drivers/isimodem/network-registration.c#L191 handles it | 12:09 |
| sicelo | but the code doesn't really make that much use of the returned data. | 12:10 |
| sicelo | https://paste.debian.net/1296684/ is initial code using that data, and the `tag` variable does contain correct operator name at that point | 12:10 |
| sicelo | so what i need is to inject it into ofono core | 12:11 |
| freemangordon | ahaaa | 12:11 |
| freemangordon | why don't you just issue another create_name_get_req()? | 12:12 |
| freemangordon | IOW - just ask ofono to refres the operator name by asking the modem | 12:12 |
| sicelo | it will fail, because for this network, when you ask modem, it errors :-) | 12:13 |
| freemangordon | ugh | 12:13 |
| sicelo | i.e. don't ask modem. it will tell you when it feels like it | 12:14 |
| freemangordon | ok, but then are you sure it is properly registered? | 12:14 |
| sicelo | yes | 12:14 |
| freemangordon | hmm... | 12:14 |
| freemangordon | how do you know, if it errors out if you ask for registration status? | 12:14 |
| sicelo | let me show you, just a moment | 12:15 |
| sicelo | https://paste.debian.net/1296696/ | 12:15 |
| sicelo | this is debug data from ofono | 12:16 |
| freemangordon | what is NET_CAUSE_COMMUNICATION_ERROR? | 12:16 |
| sicelo | line 12 is ofono requesting operator name info, and line 22 is modem/network failing to provide it | 12:16 |
| freemangordon | so, the modem is not registered properly | 12:16 |
| sicelo | it is :-) | 12:17 |
| freemangordon | well, why then it fails to provide op name? | 12:17 |
| freemangordon | BTW... | 12:17 |
| freemangordon | what you can do... | 12:17 |
| sicelo | no idea. i guess it's operator related, because on a different operator, the call succeeds | 12:17 |
| sicelo | now, look at lines 1-10 ... | 12:17 |
| sicelo | that's the modem sending, unsolicitied, information to ofono, including 3 operator name options to choose from :-) | 12:18 |
| freemangordon | is - cache the name from NET_REG_STATUS_IND, and later on, if NET_OPER_NAME_READ_REQ fails, provide the cached name | 12:18 |
| sicelo | so ofono currently does not use any of those three operator names, and that's what i want to add support for | 12:19 |
| freemangordon | ok, how do you choose between them? | 12:19 |
| sicelo | up to you, i guess. seems gsm standard provides for short name and full name. the SZ 02 is correct short name for Eswatini Mobile ... no idea why they send a third one with no space in between | 12:20 |
| freemangordon | ok | 12:20 |
| freemangordon | so, wouldn't caching those fix your issue? | 12:21 |
| sicelo | sounds like a good plan what you propose! | 12:21 |
| freemangordon | yeah | 12:21 |
| sicelo | i don't know if i'll be able to implement it on my own though, heh, but will try | 12:22 |
| sicelo | still within this context, could you have a look at https://elixir.bootlin.com/ofono/latest/source/drivers/isimodem/network-registration.c#L204 ... this is the block that iterates through the information available in NET_REG_STATUS_IND | 12:23 |
| sicelo | i added a `default` case, hoping to find other subblocks from the message, which is on lines 1-9 of https://paste.debian.net/1296696/ | 12:24 |
| freemangordon | sorry, have to run now | 12:24 |
| freemangordon | laters | 12:24 |
| sicelo | sure, thanks | 12:25 |
| sicelo | i'll leave it here anyway | 12:25 |
| sicelo | so one of the subblocks is the one on byte position 7 of that dump (it's actually 6, since the first byte is ignored ... it's a transaction id). the header for this block goes up to the 0x05, which tells us the number of UCS-2 characters that follow (SZ 02). | 12:27 |
| sicelo | i was thinking this block would show up in the default case, but it doesn't ... the first block that shows up is the one on the first 0xE3 on line 5 ... | 12:28 |
| sicelo | i don't mind it too much, because, luckily, this is the block i'm most interested in, but i do have some interest in the other block, since there are cases where it's the only extra block available | 12:29 |
| sicelo | for example, in the trace at https://yhbt.net/lore/all/1306164011-29368-1-git-send-email-arunlee@gmail.com/T/ | 12:30 |
| sicelo | anyway for now, will focus on caching it | 12:30 |
| dsc_ | freemangordon: I am moving to a new appartment this month so I may not always have time but we can talk about abook sometime | 12:59 |
| freemangordon | uvos: I was able to run glimagesink on d4, will start using that instead of xvimagesink | 15:09 |
| * uvos__ is pleased | 15:25 | |
| uvos__ | how is perf? | 15:26 |
| uvos__ | same? | 15:26 |
| uvos__ | should be same really, barring issues | 15:26 |
| freemangordon | seems same/similar | 15:34 |
| sicelo | fmg, nvm the last part (of the ofono discussion) about parsing the `SZ 02` block. turns out it's not a separate subblock, but that's still part of the first block. so now i have perfect parsing of all three possible operator name subblocks from NET_REG_STATUS_IND | 21:03 |
| sicelo | ofonod[29468]: drivers/isimodem/network-registration.c:parse_common_info() Short OperName = SZ 02 │ time to empty: 3.6 hours | 21:03 |
| sicelo | ofonod[29468]: drivers/isimodem/network-registration.c:reg_status_ind_cb() Full opername is Swazi Mobile │ percentage: 20% | 21:03 |
| sicelo | ofonod[29468]: drivers/isimodem/network-registration.c:reg_status_ind_cb() Alternate full opername is Swazi Mobile │ icon-name: 'battery-caution-symbolic' | 21:03 |
| sicelo | the caching/injecting is next :-) | 21:04 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!