ahmed_sam has joined #maemo-leste
<Wizzup> uvos: right, thanks
<Wizzup> somehow I keep forgetting that it has no sd card :D
<Wizzup> (reader)
neimsaci has joined #maemo-leste
neimsaci has quit [Client Quit]
<Wizzup> uvos: so what partition did you install leste to?
ceene has joined #maemo-leste
<Wizzup> uvos - the tablet should not draw a lot with the screen off through right?
<Wizzup> uvos - well I guess stesp one is to install kexecboot, see if android still boots, and then take it from there
<Wizzup> sicelo: if it only works for some operators, maybe the mobile broadband providers is out of date
<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
<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
<tmlind> and my mz609 memory issues have gotten so bad i can no longer even copy over files, ordered a mz608 though
<Wizzup> tmlind: ok, and then put leste on uesrdata?
<tmlind> Wizzup: yes that way you can share it between android and m-l (unless there's some directory name conflict)
<Wizzup> probably shouldn't be a conflict, not sure if android will do any crazy stuff to it
<tmlind> yeah so far no issues here
<Wizzup> btw, you said there's a hang for audio on voice, is this even hooked up on the tablets
<Wizzup> tmlind: ok, sounds like I should try this and document it somewhere
<tmlind> Wizzup: no idea, so far did not get any response on mz617 on the n_gsm serial port from the modem, usb only
<Wizzup> I would not be super surprised is audio is just not hooked up
<Wizzup> (would be cool if it was, though)
<Wizzup> s/is audio/if audio/
<tmlind> yeah maybe it is, need to get busy here now, ttyl
<Wizzup> ttyl!
ahmed_sam has quit [Ping timeout: 252 seconds]
joerg has quit [Ping timeout: 255 seconds]
joerg has joined #maemo-leste
xmn has quit [Ping timeout: 272 seconds]
<sicelo> Wizzup: no. it's the operator themselves :-)
<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
<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
<sicelo> so i still need to find correct way to do that.
<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
<sicelo> oh and the `if` on line 22 doesn't work either ... not sure why, hence i commented it out for the time being
<sicelo> because ideally i want to only use this codepath only if operator name was not already set by other means
<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
<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
LjL has quit [Read error: Connection reset by peer]
LjL has joined #maemo-leste
Daanct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 246 seconds]
Daanct12 has joined #maemo-leste
akossh has joined #maemo-leste
asriel has quit [Quit: Don't drink the water. They put something in it to make you forget.]
asriel has joined #maemo-leste
[TheBug] has quit [Ping timeout: 264 seconds]
<sicelo> some C help please ... bencoh, freemangordon, Wizzup (sorry for pings)
<sicelo> this macro - what are the final/real C statements that end up being run?
<freemangordon> sicelo: hard to say, because the macro is defined on several places
<freemangordon> I guess this https://elixir.bootlin.com/ofono/latest/source/drivers/isimodem/isiutil.h#L45 is the one that is used
<sicelo> i think we can confine ourselves to the isimodem part
<sicelo> yes, that's the one
<freemangordon> ofono_netreg_operator_cb_t cb = cbd->cb;
<freemangordon> so it does 'cb(&e, &op, cbd->data);
<freemangordon> 'cb(&e, &op, cbd->data);'
<freemangordon> does that answer your question or you want to know what exactly cb() is?
<freemangordon> BTW, cb stands for 'callback'
<sicelo> yes, i would like to know what it is exactly :-)
<freemangordon> better put breakpoint in name_get_resp_cb() and print *cbd
<freemangordon> and see which function cbd->cb is
<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 ...
<freemangordon> does that help?
<sicelo> freemangordon: maybe let me state why i am even trying to understand this macro:
<freemangordon> "got so far"? like, folowing the source or in gdb?
<sicelo> source
<freemangordon> sicelo: forget the macro, it just sets an error if needed and then calls the callback
<freemangordon> if your results are not ok, you have to check what that callback does
<freemangordon> the easiest way to see which function is called as a callback is with the debugger
<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
<freemangordon> ok
<freemangordon> right
<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
<freemangordon> ok
<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
<sicelo> but the code doesn't really make that much use of the returned data.
<sicelo> https://paste.debian.net/1296684/ is initial code using that data, and the `tag` variable does contain correct operator name at that point
<sicelo> so what i need is to inject it into ofono core
<freemangordon> ahaaa
<freemangordon> why don't you just issue another create_name_get_req()?
<freemangordon> IOW - just ask ofono to refres the operator name by asking the modem
<sicelo> it will fail, because for this network, when you ask modem, it errors :-)
<freemangordon> ugh
<sicelo> i.e. don't ask modem. it will tell you when it feels like it
<freemangordon> ok, but then are you sure it is properly registered?
<sicelo> yes
<freemangordon> hmm...
<freemangordon> how do you know, if it errors out if you ask for registration status?
<sicelo> let me show you, just a moment
<sicelo> this is debug data from ofono
<freemangordon> what is NET_CAUSE_COMMUNICATION_ERROR?
<sicelo> line 12 is ofono requesting operator name info, and line 22 is modem/network failing to provide it
<freemangordon> so, the modem is not registered properly
<sicelo> it is :-)
<freemangordon> well, why then it fails to provide op name?
<freemangordon> BTW...
<freemangordon> what you can do...
<sicelo> no idea. i guess it's operator related, because on a different operator, the call succeeds
<sicelo> now, look at lines 1-10 ...
<sicelo> that's the modem sending, unsolicitied, information to ofono, including 3 operator name options to choose from :-)
<freemangordon> is - cache the name from NET_REG_STATUS_IND, and later on, if NET_OPER_NAME_READ_REQ fails, provide the cached name
<sicelo> so ofono currently does not use any of those three operator names, and that's what i want to add support for
<freemangordon> ok, how do you choose between them?
<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
<freemangordon> ok
<freemangordon> so, wouldn't caching those fix your issue?
<sicelo> sounds like a good plan what you propose!
<freemangordon> yeah
<sicelo> i don't know if i'll be able to implement it on my own though, heh, but will try
<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
<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/
<freemangordon> sorry, have to run now
<freemangordon> laters
<sicelo> sure, thanks
<sicelo> i'll leave it here anyway
<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).
<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 ...
<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
<sicelo> anyway for now, will focus on caching it
<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
[TheBug] has joined #maemo-leste
ahmed_sam has joined #maemo-leste
ahmed_sam has quit [Read error: Connection reset by peer]
Danct12 has quit [Read error: Connection reset by peer]
Daanct12 has quit [Quit: WeeChat 4.1.1]
xmn has joined #maemo-leste
Danct12 has joined #maemo-leste
Danct12 has quit [Client Quit]
neimsaci has joined #maemo-leste
<freemangordon> uvos: I was able to run glimagesink on d4, will start using that instead of xvimagesink
uvos__ has joined #maemo-leste
* uvos__ is pleased
<uvos__> how is perf?
<uvos__> same?
<uvos__> should be same really, barring issues
[TheBug] has quit [Changing host]
[TheBug] has joined #maemo-leste
<freemangordon> seems same/similar
nmdv has joined #maemo-leste
nmdv has quit [Read error: Connection reset by peer]
Danct12 has joined #maemo-leste
_nmdv has joined #maemo-leste
ceene has quit [Ping timeout: 264 seconds]
ceene has joined #maemo-leste
pere has quit [Ping timeout: 264 seconds]
Evil_Bob has quit [Ping timeout: 255 seconds]
Evil_Bob has joined #maemo-leste
pere has joined #maemo-leste
DADFP has joined #maemo-leste
DFP has quit [Ping timeout: 255 seconds]
ceene has quit [Ping timeout: 245 seconds]
sch has quit [Ping timeout: 260 seconds]
pere has quit [Ping timeout: 258 seconds]
<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
<sicelo> ofonod[29468]: drivers/isimodem/network-registration.c:parse_common_info() Short OperName = SZ 02 │ time to empty: 3.6 hours
<sicelo> ofonod[29468]: drivers/isimodem/network-registration.c:reg_status_ind_cb() Full opername is Swazi Mobile │ percentage: 20%
<sicelo> ofonod[29468]: drivers/isimodem/network-registration.c:reg_status_ind_cb() Alternate full opername is Swazi Mobile │ icon-name: 'battery-caution-symbolic'
<sicelo> the caching/injecting is next :-)
DADFP is now known as DFP
branon has joined #maemo-leste
branon_ has quit [Ping timeout: 240 seconds]
ceene has joined #maemo-leste
ceene has quit [Ping timeout: 248 seconds]
pere has joined #maemo-leste
Danct12 has quit [Read error: Connection reset by peer]
neimsaci has quit [Quit: WeeChat 4.1.1]
uvos has quit [Read error: Connection reset by peer]
Danct12 has joined #maemo-leste
jr-logbot` has joined #maemo-leste
Juesto has joined #maemo-leste
peetah_ has joined #maemo-leste
peterM__ has joined #maemo-leste
hexagonwin has quit [Ping timeout: 264 seconds]
akossh has quit [Ping timeout: 264 seconds]
xes has quit [Ping timeout: 264 seconds]
jr-logbot has quit [Remote host closed the connection]
Juest has quit [Ping timeout: 264 seconds]
peterM has quit [Ping timeout: 264 seconds]
eval has quit [Ping timeout: 264 seconds]
Juesto is now known as Juest
eval has joined #maemo-leste
hexagonwin has joined #maemo-leste
peetah has quit [Ping timeout: 264 seconds]
xes has joined #maemo-leste
akossh has joined #maemo-leste
xes has quit [Ping timeout: 240 seconds]
akossh has quit [Quit: Leaving.]