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