| Wizzup | uvos: ping on my sphone changes | 00:04 |
|---|---|---|
| Wizzup | should I make a pr? | 00:20 |
| Wizzup | hm, did I not push it? | 00:20 |
| * Wizzup checks | 00:20 | |
| Wizzup | Ah, no, it's fine, I squashed/rebased | 00:22 |
| uvos | Wizzup: what should i be looking at? | 00:50 |
| uvos | a pr is better to get my attetion | 00:50 |
| uvos | im not going to follow what you do in your branches | 00:50 |
| uvos | wip-rtcom is nolonger wip i gues? | 00:51 |
| Wizzup | yeah | 00:52 |
| Wizzup | I'll make a PR now | 00:52 |
| Wizzup | uvos: https://github.com/maemo-leste/sphone/pull/1 | 00:53 |
| Wizzup | note that the <unkown> to <unknown> change will also affect dbs | 00:54 |
| Wizzup | actually probably not, nvm | 00:54 |
| freemangordon | Wizzup: uvos: is it save to remove/insert sim card while droid4 is powered? | 07:50 |
| freemangordon | Wizzup: also, please elaborate on https://github.com/maemo-leste-upstream-forks/ofono/commit/cbffe1d6d3a1872db5454327a4f8c6f20419bd5f | 08:07 |
| uvos | freemangordon: yes | 10:24 |
| Wizzup | freemangordon: so there are several radio interfaces and what ended up happening is that it'd reset the tech to NULL when it iterated over the interfaces | 10:53 |
| Wizzup | iirc it was probably cdma or something (I'd have to check the logs) | 10:53 |
| Wizzup | so this simple checks if the radio tech is set to anything sensible | 10:53 |
| Wizzup | s/NULL/-1/ | 10:53 |
| Wizzup | simple->simply | 10:53 |
| uvos | whats wrong with haveing those? they may work in some contires after all | 11:05 |
| Wizzup | uvos: huh? | 11:06 |
| Wizzup | the problem is that ofono will report no technology in dbus because it nukes the good one | 11:06 |
| Wizzup | if you're in a cdma place with no 2g then it will use the cdma tech | 11:06 |
| uvos | ok then i read that wrong | 11:06 |
| uvos | i sounded to me like you nixed them | 11:06 |
| Wizzup | freemangordon: so one of the ofono problems that I think are maybe at the root of the problems: on the d4, when you boot with a sim that has a pin, it just will not detect the sim until you issue some operation, like SetProperty Online true, or just restart ofono (and even then it won't always pick it up) | 11:14 |
| Wizzup | on the bionic this particular problem with pin doesn't exist | 11:14 |
| Wizzup | similarly there are other problems I think with messages to ofono "getting lost", or at least they don't make it all the way to the right handlers | 11:15 |
| Wizzup | for example when I set the context to active, it sometimes just times out, unless in the meantime I poke ofono in some other way, like by sending a sms to my other phone number | 11:15 |
| Wizzup | what might be worth trying it setting up the 'regular' qmi modem driver which uses usb only (and uses a lot of pm and doesn't idle well) to see if that shows any of these problems | 11:16 |
| Wizzup | I don't know how to do it anymore, but can try to help to figure it out | 11:16 |
| freemangordon | Wizzup: do you know a way to re-create the issue without rebooting the device? | 11:26 |
| Wizzup | no | 11:26 |
| Wizzup | there are definitely other issues, but not as reproducible as this one | 11:26 |
| freemangordon | did you try to re-plug the card? | 11:26 |
| Wizzup | I did not | 11:26 |
| Wizzup | like if you restart ofono, it will only pick up the modem some of the time | 11:26 |
| freemangordon | ok | 11:26 |
| Wizzup | and if you set Online to false and then back to true, I think it just aborts | 11:27 |
| freemangordon | hmm | 11:27 |
| Wizzup | but that's likely a separate problem | 11:27 |
| uvos | i think you can reboot the modem via the at interface | 11:27 |
| uvos | maybe tmlind remembers | 11:27 |
| uvos | that might simulate a system reboot (if you also restart ofono) | 11:27 |
| Wizzup | I suppose you can unload and reload the kernel module | 11:27 |
| uvos | i dont know if that reboots the modem | 11:27 |
| Wizzup | it definitely powers it, not sure about unload | 11:28 |
| freemangordon | which module? | 11:28 |
| uvos | motorolamodem | 11:28 |
| freemangordon | Wizzup: I see no issues here doing offline<->online | 11:28 |
| freemangordon | but sim has no pin | 11:28 |
| Wizzup | maybe it's powered false/true | 11:29 |
| freemangordon | ok | 11:29 |
| * freemangordon tries | 11:29 | |
| Wizzup | let me try now | 11:29 |
| uvos | i dont think powerd fals true dose anything | 11:29 |
| uvos | at least it dosent change power consumption | 11:29 |
| Wizzup | well it makes it abort iirc | 11:29 |
| uvos | (which cfun dose) | 11:29 |
| uvos | sure but i mean in terms of affecting the modem firmware | 11:30 |
| freemangordon | not here (abort) | 11:30 |
| Wizzup | root@maindroid:~# mdbus2 -s org.ofono /motmdm_0 org.ofono.Modem.SetProperty Powered false | 11:31 |
| Wizzup | ^R | 11:31 |
| Wizzup | [ERR]: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying | 11:31 |
| Wizzup | root@maindroid:~# mdbus2 -s org.ofono /motmdm_0 org.ofono.Modem.SetProperty Powered false | 11:31 |
| Wizzup | [ERR]: There is no method with name org.ofono.Modem.SetProperty on path /motmdm_0! | 11:31 |
| Wizzup | this -might- be expected, perhaps | 11:31 |
| freemangordon | well, I am using ofono scripts | 11:31 |
| Wizzup | no, ofono is gone | 11:31 |
| freemangordon | enable-modem and disable-modem | 11:31 |
| Wizzup | fyi there is /var/log/maemo/ofonod.log | 11:31 |
| freemangordon | but they do the same IIUC | 11:31 |
| Wizzup | you can check if they set powered? | 11:31 |
| freemangordon | lemme check | 11:32 |
| Wizzup | Aug 25 11:30:16 localhost ofonod[2878]: Aborting (signal 11) [/usr/sbin/ofonod] | 11:32 |
| freemangordon | Wizzup: you mean the scripts? | 11:32 |
| freemangordon | modem.SetProperty("Powered", dbus.Boolean(0), timeout = 120) | 11:32 |
| Wizzup | I don't use the scripts, but I doubt it makes a difference, it's just dbus | 11:32 |
| freemangordon | this is disable-modem | 11:32 |
| freemangordon | ok, lemme set pin to that card | 11:33 |
| Wizzup | I doubt the pin matters to the abort | 11:34 |
| Wizzup | but yeah, ok | 11:34 |
| freemangordon | it does not abort here | 11:34 |
| freemangordon | maybe different initial state? | 11:34 |
| freemangordon | like modem is opnline? | 11:35 |
| freemangordon | *online | 11:35 |
| freemangordon | or, could you attach gdb and provide backtrace? that might give me a clue how to repro | 11:35 |
| Wizzup | the modem is online yeah | 11:36 |
| Wizzup | http://dpaste.com/AYTJL8R6R | 11:37 |
| freemangordon | nope. makes no difference | 11:37 |
| Wizzup | it took two tries for me just now | 11:37 |
| freemangordon | well, lemme put sim with pin | 11:37 |
| Wizzup | (see backtrace above btw) | 11:37 |
| Wizzup | looks like it might get RSSI after the modem is off or something silly | 11:38 |
| Wizzup | could relate to our mce mapphone module | 11:38 |
| uvos | well mce only disables rssi | 11:38 |
| freemangordon | no matter what, it should not segfault | 11:38 |
| Wizzup | sure | 11:38 |
| uvos | it segfaults here to | 11:38 |
| uvos | doing this btw | 11:38 |
| uvos | i gues it might be because disable-modem dosent do anything really | 11:39 |
| freemangordon | it does | 11:39 |
| uvos | you can still talk to the modem via qmicli | 11:39 |
| freemangordon | sets powerd ot off | 11:39 |
| uvos | right | 11:39 |
| uvos | but the modem dosent care | 11:39 |
| uvos | if you connect gsm via qmicli "powering it off" via ofono dosent even dissconnect the connection | 11:40 |
| Wizzup | so debugging wise there's etting n_gsm.debug to 0xff | 11:40 |
| Wizzup | and there's the ofono logs that can be made very verbose | 11:41 |
| freemangordon | ok, but I want to repro first | 11:42 |
| uvos | i had to power the modem, online it, enter pin and have it be connected to an operator | 11:42 |
| uvos | before the segfault via off | 11:42 |
| Wizzup | yeah and there's the rssi msg in my backtrace | 11:43 |
| Wizzup | so maybe it relates to locking the device too | 11:43 |
| Wizzup | (which I do often) | 11:43 |
| uvos | i can do the whole seqence with out ever locking the device | 11:44 |
| uvos | so mce should not have issued any modem commands at all in that timespan | 11:44 |
| freemangordon | uvos: does it happen wwith sim without pin? | 11:46 |
| uvos | no idea | 11:47 |
| freemangordon | ok, seems ofono does not detect hot-pluggin a card with pin | 11:58 |
| Wizzup | not even sure if the modem does | 11:59 |
| uvos | in android it dose | 11:59 |
| Wizzup | if you remove the '#' you'll see all modem msgs /etc/modprobe.d/gps.conf:#options n_gsm debug=0xff | 11:59 |
| uvos | takse a couple of second or so tho | 12:00 |
| uvos | so maybe its just becuase android querys something and kicks the modem | 12:00 |
| freemangordon | I have no /etc/modprobe.d/gps.conf | 12:01 |
| Wizzup | freemangordon: sure, make it :) | 12:01 |
| Wizzup | for the record: | 12:01 |
| Wizzup | # cat /etc/modprobe.d/gps.conf | 12:01 |
| Wizzup | #options n_gsm debug=0xff | 12:01 |
| Wizzup | options gnss_motmdm rate_ms=1000 | 12:01 |
| freemangordon | your statement (uncomment line...) implied I shoud already have one :) | 12:02 |
| uvos | Wizzup: how manny seconds should the sphone window stay (after call) | 12:02 |
| uvos | 5s? | 12:02 |
| Wizzup | freemangordon: sry | 12:02 |
| Wizzup | uvos: yeah that's a start I think | 12:02 |
| freemangordon | why it should auto-close at all? | 12:03 |
| uvos | id prefer it to auto-close eventually | 12:03 |
| freemangordon | ok, but why? | 12:03 |
| uvos | so i dont have to do anything when remote hangs up | 12:03 |
| freemangordon | at least make that an option | 12:03 |
| freemangordon | it is like if conversation closes 5s after last message | 12:04 |
| freemangordon | or if the remote party goes offline | 12:04 |
| uvos | i mean a call is totaly different | 12:04 |
| uvos | your unlikely to immidatly call a person you just called again | 12:05 |
| freemangordon | it is not, but lets not go into that :) | 12:05 |
| uvos | besides you cant even do that with this window | 12:05 |
| freemangordon | yous, you should be presented with last calls window ;) | 12:05 |
| uvos | (where talking about the window that shows the mute and hangup buttons here) | 12:05 |
| freemangordon | this is how every dialer around works | 12:05 |
| uvos | it looses validity immidatly when your not in a call | 12:06 |
| freemangordon | yes, and you shoudl be presented with last calls | 12:06 |
| freemangordon | anyway | 12:06 |
| uvos | im not sure what dialer works like this | 12:06 |
| uvos | maybe the fremantle one | 12:06 |
| freemangordon | yes | 12:06 |
| freemangordon | when GF is back, I will check what andoid one does | 12:07 |
| Wizzup | fremantle will close itself if it's not open and you got called | 12:07 |
| freemangordon | sure? | 12:07 |
| Wizzup | otherwise it will stay open at the window is just a stacked window | 12:07 |
| freemangordon | ok | 12:07 |
| Wizzup | freemangordon: the dial window specifically yes | 12:07 |
| Wizzup | err not dial | 12:07 |
| Wizzup | but the call window | 12:07 |
| freemangordon | yeah "in-call" | 12:07 |
| freemangordon | ok | 12:07 |
| uvos | same with android | 12:08 |
| uvos | it kicks you back to the last window | 12:08 |
| uvos | (either contacts or the dialer or nothing) | 12:08 |
| freemangordon | ok | 12:09 |
| uvos | so the only thing sphone dose different is that the dialer closes | 12:10 |
| uvos | (also the delay is missing, android has a delay to) | 12:10 |
| uvos | so you can look at the call time presumably | 12:10 |
| freemangordon | mhm | 12:10 |
| uvos | anyhow delay is now 5 sec | 12:10 |
| uvos | we can also not close the dailer | 12:11 |
| uvos | if you like | 12:11 |
| uvos | Wizzup: ? | 12:11 |
| freemangordon | all dialeres around do it, so I think it makses sense | 12:11 |
| freemangordon | a typo day? | 12:11 |
| uvos | wat si tpo? | 12:12 |
| Wizzup | uvos: I think if the window is not open, and you get called, then no window ought to remain | 12:12 |
| Wizzup | (after 5s) | 12:12 |
| uvos | right | 12:12 |
| Wizzup | if it's open, I'd keep it open | 12:12 |
| uvos | ok | 12:12 |
| uvos | rn it closes as soon as you press call | 12:12 |
| Wizzup | so ideally it would stack :) | 12:12 |
| freemangordon | typo? umm... when you type something wrongly, that's a typo | 12:12 |
| Wizzup | freemangordon: I think it was a joke | 12:13 |
| freemangordon | ah | 12:13 |
| freemangordon | I didn;t even see how it was typed :D | 12:13 |
| freemangordon | I am so used to how uvos type here :p | 12:13 |
| Wizzup | idk most of it is typo free | 12:13 |
| freemangordon | anyway, it seems n_gsm report at least SIM removal | 12:14 |
| Wizzup | right | 12:14 |
| Wizzup | it might take a bit to report sim insertion maybe? | 12:14 |
| freemangordon | lemme put back | 12:14 |
| uvos | bren si realy god at dicodeig | 12:14 |
| uvos | ok ill remove the close | 12:14 |
| uvos | but this makes the call button have very little feedback | 12:14 |
| freemangordon | yep, insertion is reported too | 12:14 |
| freemangordon | https://pastebin.com/g96gfdVq | 12:15 |
| uvos | any ideas on feedback? | 12:15 |
| freemangordon | yep, ofono issue, deffinitely | 12:15 |
| freemangordon | will do some work work and will se what I can do about it | 12:16 |
| uvos | its good that its not the modem fw | 12:16 |
| freemangordon | mhm | 12:16 |
| Wizzup | uvos: if you close the call yourself it can hang up sooner | 12:17 |
| Wizzup | s/hang up/close/ | 12:17 |
| uvos | sure that fixes the feedback on the hangup button | 12:18 |
| uvos | but not the call button | 12:19 |
| uvos | when you press call, nothing happens for a while | 12:19 |
| uvos | as ofono needs to be contacted and then sphone has to spawn a new window | 12:19 |
| uvos | hildon also needs to rotate, takes about 1.5 seconds or so | 12:19 |
| uvos | all in | 12:19 |
| Wizzup | sometimes the button hangs for 30s because of ofono timeouts :P | 12:20 |
| freemangordon | Wizzup: hmm, which ofono branch to use? | 12:32 |
| freemangordon | beowulf-devel? | 12:34 |
| Wizzup | let me look | 12:36 |
| Wizzup | maemo-ofono should be ok | 12:36 |
| Wizzup | https://github.com/maemo-leste-upstream-forks/ofono | 12:36 |
| freemangordon | ok | 12:37 |
| freemangordon | ok, but why is that not in -devel? | 12:38 |
| Wizzup | I think it is | 12:38 |
| freemangordon | maybe that's the reason why it does not segfault her | 12:38 |
| freemangordon | *here | 12:38 |
| Wizzup | we have same ofono everywhere | 12:38 |
| Wizzup | maybe you're looking at a different repo? | 12:38 |
| freemangordon | url = git@github.com:maemo-leste-upstream-forks/ofono.git | 12:39 |
| Wizzup | ii ofono 1:1.34.0-1+2m7.1 armhf Mobile telephony stack (daemon) | 12:39 |
| Wizzup | ofono (1:1.34.0-1) unstable; urgency=medium | 12:39 |
| Wizzup | looks like the right version to me | 12:39 |
| Wizzup | what version do you have? | 12:39 |
| freemangordon | 1:1.34.0-1+2m7.1 | 12:40 |
| Wizzup | so I think you have the same version as maemo-ofono as maemo/beowulf-devel | 12:40 |
| freemangordon | but, git diff shows differences between beowulf-devel and maemo-ofono branches | 12:40 |
| freemangordon | unless I am doing something wrong | 12:40 |
| Wizzup | your beowulf-devel or origin/beowulf-devel | 12:41 |
| freemangordon | umm... | 12:41 |
| freemangordon | oh :) | 12:41 |
| Wizzup | $ git diff --stat origin/maemo/beowulf-devel..origin/maemo-ofono | wc 0 0 0 | 12:42 |
| freemangordon | yeah, it is better now | 12:42 |
| Wizzup | :) | 12:42 |
| freemangordon | there is beowulf-devel branch I think we shall delete | 12:43 |
| freemangordon | but anyway | 12:43 |
| Wizzup | ah yeah | 12:43 |
| Wizzup | heh | 12:43 |
| freemangordon | may I delete that? | 12:43 |
| Wizzup | sure | 12:44 |
| buZz | heh, never noticed that rightclicking actually works on touch? at least in chromium | 13:27 |
| buZz | just holding touchscreen | 13:27 |
| uvos | some apps implement this | 13:32 |
| uvos | firefox to | 13:32 |
| uvos | but its not a universal thing | 13:32 |
| freemangordon | uvos: can I send AT commends to the modem? | 13:33 |
| freemangordon | somehow | 13:33 |
| uvos | freemangordon: well | 13:33 |
| uvos | freemangordon: sorta | 13:33 |
| uvos | freemangordon: so the modem dosent really have a at interface | 13:34 |
| uvos | freemangordon: it has a interface that uses commands that start with at :P | 13:34 |
| freemangordon | ah | 13:34 |
| uvos | (its really quirky) | 13:34 |
| uvos | its on one of the usb ttys | 13:34 |
| uvos | sec | 13:34 |
| freemangordon | do we have it documented somewhere? | 13:34 |
| freemangordon | (commands set) | 13:34 |
| uvos | no | 13:35 |
| uvos | we dont know what it supports | 13:35 |
| freemangordon | as I have the feeling that unsolicited messages shall be enabled | 13:35 |
| uvos | besides messing with android | 13:35 |
| uvos | and seeing what it sends | 13:35 |
| freemangordon | do we have a log somewhere? | 13:35 |
| uvos | its very customized by motorola | 13:35 |
| freemangordon | ok | 13:35 |
| freemangordon | but do we have a log from android boot and communication with the modem | 13:35 |
| uvos | somewhere yeah | 13:35 |
| uvos | yeah | 13:36 |
| uvos | anyhow its on /dev/gsmtty1 | 13:36 |
| uvos | mostly the modem wants you to controll it via qmi | 13:37 |
| uvos | really | 13:37 |
| uvos | realy pali probubly knows best | 13:41 |
| uvos | he wrote a hacked version of ofono that uses the at interface to do sms and calls | 13:41 |
| uvos | it never worked very well | 13:41 |
| uvos | but he probubly knows which at commands work and in how far they dfo | 13:41 |
| uvos | or maybe it was pavel | 13:43 |
| uvos | i dont quite remember | 13:43 |
| freemangordon | pavel | 13:44 |
| freemangordon | hmm, AT+QSIMDET | 13:49 |
| freemangordon | uvos: anyway, do you have that andoid log around to share? | 13:49 |
| uvos | freemangordon: im looking for it | 13:49 |
| freemangordon | ok | 13:49 |
| uvos | i found this | 13:50 |
| uvos | http://uvos.xyz/maserati/stockinfo/call/AT_COMMANDS.txt | 13:50 |
| uvos | stringed from some android libarary iirc | 13:50 |
| uvos | libmoto*ril.so | 13:51 |
| uvos | http://uvos.xyz/maserati/stockinfo/call/ril | 13:52 |
| uvos | if you want to re something | 13:52 |
| uvos | no debug symbols tho | 13:53 |
| uvos | so good luck :P | 13:53 |
| freemangordon | thanks | 13:59 |
| Wizzup | probably not needed though? | 14:09 |
| freemangordon | hmm, AT+UNSOL | 14:17 |
| freemangordon | uvos: so, how to send command while ofono is running? | 14:24 |
| uvos | printf 'U1234AT+UNSOL=1\r' > /dev/gsmtty1 | 14:29 |
| uvos | U1234+UNSOL:OK | 14:29 |
| uvos | works fine here | 14:29 |
| freemangordon | ok | 14:30 |
| uvos | new sphone is on the way btw | 14:32 |
| uvos | @Wizzup | 14:32 |
| uvos | besides the other things the missed calls from the distant past are also fixed | 14:32 |
| freemangordon | hmm, not good | 14:38 |
| freemangordon | either FW or kernel issue | 14:38 |
| freemangordon | (missing sim events) | 14:38 |
| Wizzup | uvos: thx | 14:42 |
| Wizzup | freemangordon: hm, maybe that is why we don't see it on bionic | 14:42 |
| freemangordon | could you capture dmesg log when removing SIM (with n_gsm debug=0xff) | 14:43 |
| Wizzup | I've never tried this | 14:47 |
| Wizzup | I can try | 14:53 |
| Wizzup | (later today) | 14:53 |
| freemangordon | ok | 14:53 |
| freemangordon | tmlind: do you have some android boot log with modem commands tracing? | 15:34 |
| tmlind | freemangordon: i recall you can trace them with logcat if using lineageos kernel | 15:39 |
| freemangordon | do I need serial attached? | 15:39 |
| tmlind | freemangordon: no, adb is enough | 15:39 |
| freemangordon | ok, but isn't it too late? | 15:40 |
| tmlind | freemangordon: you also want to probably enable ts27010 debug if looking at the modem commands | 15:40 |
| tmlind | freemangordon: pretty sure logcat shows you the boot time messages too | 15:40 |
| freemangordon | ok, now I have to dig what is ts27010 and how to enable debug :) | 15:40 |
| freemangordon | tmlind: does current mainline modem driver use apwake gpio? | 15:42 |
| tmlind | let me try to find my notes | 15:42 |
| tmlind | freemangordon: adb shell 'echo 0x7fffffff > /sys/module/ts27010mux/parameters/debug_level' | 15:43 |
| tmlind | that allows you to see the ts27010 serial mux packets to the modem | 15:43 |
| freemangordon | ok, but my concern is that maybe no irq is used from BP->AP | 15:43 |
| tmlind | freemangordon: not sure if we use the apwake gpio.. the gpios are in the dts file | 15:44 |
| freemangordon | perhaps that's why we need to send something in order to receive unsol events | 15:44 |
| * freemangordon checks gpio number in android kernel | 15:44 | |
| tmlind | yeah maybe | 15:44 |
| tmlind | see also what phy-cpcap-usb.c is already doing, maybe it already handles it | 15:45 |
| tmlind | no sorry, wrong phy driver.. the mdm6600 phy driver | 15:45 |
| freemangordon | ok | 15:45 |
| tmlind | phy-mapphone-mdm6600.c | 15:46 |
| freemangordon | ok | 15:46 |
| tmlind | freemangordon: some mdm6600 gpios need to be remuxed to input after initial bootup to use them | 15:48 |
| freemangordon | yep, I see the comments in phy driver | 15:48 |
| freemangordon | but I have to figure out what exactly gpio is needed | 15:49 |
| tmlind | maybe apwake remuxed to input after boot if not done already? | 15:50 |
| tmlind | that should be gpio_149 | 15:51 |
| freemangordon | mdm6600-wake does not increase on SIM insert/remove | 15:52 |
| tmlind | i see /* Reconfigure mode1 GPIO as input for OOB wake */ so modem should already be waking up the soc | 15:53 |
| freemangordon | p, li { white-space: pre-wrap; } /* Reconfigure mode1 GPIO as input for OOB wake */ | 15:53 |
| freemangordon | yep | 15:53 |
| freemangordon | that's exactly "mdm6600-wake" | 15:53 |
| freemangordon | what is "mode1"? | 15:54 |
| tmlind | it could be there's some handler missing in ofono and the message comes from uart just fine | 15:54 |
| tmlind | mode pins tell what usb mode to boot it to i think | 15:54 |
| freemangordon | I see nothing in n_gsm traces | 15:55 |
| freemangordon | (re missing handler) | 15:55 |
| freemangordon | shall I write a simple test program that opens /dev/gsmtty1 and reads? | 15:55 |
| tmlind | ok then maybe sim insert does not trigger anything? it takes really long time with android too to see the sim sometimes | 15:55 |
| freemangordon | ok, but sim remove? | 15:56 |
| tmlind | don't remember if that produces anything | 15:56 |
| freemangordon | in android? | 15:56 |
| freemangordon | hmm | 15:56 |
| tmlind | if you modprobe n_gsm debug=0xff, then you should see the raw packets in dmesg | 15:56 |
| freemangordon | that's why I did | 15:56 |
| tmlind | so probably no need to read /dev/gsmtty1 | 15:57 |
| freemangordon | nothing comes | 15:57 |
| freemangordon | unless you "kick" it by sending some command | 15:57 |
| tmlind | weird | 15:57 |
| freemangordon | hmm, wait | 15:57 |
| freemangordon | see the note before phy_mdm6600_wakeirq_thread | 15:58 |
| freemangordon | "Just use it for debug info only..." | 15:58 |
| tmlind | yeah maybe that triggers and means check status | 15:59 |
| freemangordon | mhm | 15:59 |
| freemangordon | looks like | 15:59 |
| tmlind | oh so you see it trigger when inserting a sim then? | 16:01 |
| freemangordon | no, because it is dev_dbg | 16:01 |
| freemangordon | I am trying to find how to see dev_dbg messages | 16:02 |
| tmlind | #define DEBUG at the top, set loglevel to 8 or smaller i think | 16:02 |
| tmlind | or just change dev_dbg to dev_info temporarily.. | 16:02 |
| freemangordon | what about "echo 'file phy-mapphone-mdm6600.c +p'>/sys/kernel/debug/dynamic_debug/control"? | 16:02 |
| tmlind | yeah that might work | 16:03 |
| freemangordon | ugh, no dynamic_debug it seems :( | 16:03 |
| tmlind | ok | 16:03 |
| freemangordon | but I see irqs increasing | 16:03 |
| tmlind | i need to go deal with feeding, let's hope the oob gpio works :) bbl | 16:03 |
| freemangordon | :) | 16:04 |
| freemangordon | hmm, seems inserting seems gets registered by ofono | 16:06 |
| freemangordon | it just takes lots of time | 16:06 |
| freemangordon | or, it could be because I enabled unsol messages | 16:06 |
| * freemangordon checks | 16:06 | |
| * tmlind waiting for a pizza | 16:21 | |
| * uvos intercepts pizza | 16:21 | |
| freemangordon | tmlind: do you know, where in ofono I shall send 'U1234AT+UNSOL=1' command? | 16:22 |
| freemangordon | it seems this has to be send after every unsol even in order to receive the next one | 16:23 |
| tmlind | no idea, seems it needs a new handler in ofono | 16:23 |
| freemangordon | umm, why handler? | 16:24 |
| freemangordon | the handler is there | 16:24 |
| freemangordon | I just need to send that command when tty is opened | 16:24 |
| tmlind | but something needs to parse the unsol message, then kick the usb interface | 16:25 |
| freemangordon | the parser is already there | 16:25 |
| tmlind | ah | 16:25 |
| tmlind | ok then acking it is needed sounds like | 16:25 |
| freemangordon | see receive_notify in sim.c | 16:25 |
| freemangordon | but, I think before receiving the first notify, the ^^^ commend shall be send | 16:26 |
| freemangordon | to enable unsol events | 16:26 |
| freemangordon | hmm, maybe you are right and this is ACK, lemme try | 16:26 |
| tmlind | afc, only on d4 right now, can't grep | 16:26 |
| freemangordon | ok | 16:26 |
| tmlind | fyi to avoid implementing full modem support over serial at commands, we just kick the usb interface and let the existing code handle things.. | 16:29 |
| freemangordon | umm... I am not sure I understand | 16:29 |
| tmlind | ofono has good qmi support over usb | 16:29 |
| freemangordon | ok | 16:29 |
| tmlind | bbl | 16:30 |
| freemangordon | lets first see that what I think is needed works | 16:30 |
| freemangordon | ok, it seems AT+UNSOL=1 shall be send only once | 18:10 |
| freemangordon | ugh, why it needs 5 minut6es to report sim present? | 18:12 |
| freemangordon | hmm, not, this command must be send every time | 18:16 |
| Wizzup | freemangordon: modem startup time maybe | 18:18 |
| freemangordon | no | 18:18 |
| freemangordon | 10 minutes after boot | 18:18 |
| freemangordon | if there is no AT+UNSOL=1, SIM insertion is not reported | 18:18 |
| Wizzup | not sure how that works | 18:18 |
| Wizzup | do you have a bionic as well? | 18:18 |
| freemangordon | if there is, it is reported maybe a minute after it is inserted | 18:18 |
| freemangordon | no | 18:18 |
| Wizzup | uvos suggested we could try older or newer fw | 18:19 |
| freemangordon | lemme first see if I can make it work properly on d4 | 18:19 |
| Wizzup | :) | 18:20 |
| freemangordon | I just have to find the proper place to put it | 18:20 |
| freemangordon | (command) | 18:20 |
| freemangordon | and I am sure it will work | 18:21 |
| freemangordon | well, sure(tm) :) | 18:21 |
| Wizzup | :) | 18:36 |
| freemangordon | ugh, callback in ofono was not called :( | 18:38 |
| freemangordon | oh, PEBCAK | 18:38 |
| tmlind | freemangordon: so are you seeing AT+UNSOL=1 do anything? | 18:59 |
| freemangordon | still hard to say | 18:59 |
| tmlind | heh | 18:59 |
| freemangordon | yeah, seems ofono has bug so callback does not get called when sim insert is reported | 19:00 |
| freemangordon | investigation ATM | 19:00 |
| tmlind | usually if the modem has something it produces several WAKEUP on the dlci1 | 19:00 |
| tmlind | freemangordon: maybe enable status notifications on dlci1 with AT+SCRN=1, then insert sim and see you that produces any new messages? | 19:02 |
| tmlind | most likely it will just enable network status notfications though | 19:02 |
| freemangordon | lemme first fix ofono bug | 19:03 |
| tmlind | oh ok | 19:05 |
| freemangordon | tmlind: hmm, why g_at_chat_register() in sim.c is called with expect_pdu set to true? | 19:07 |
| tmlind | just a sec.. hmm maybe the sim detection i added only works with bionic firmware? there's a difference in the line break characters between bionic and d4.. | 19:08 |
| tmlind | forgot the details on the expect_pdu, may be related to the different line breaks too | 19:09 |
| tmlind | or could be bug :) | 19:09 |
| Wizzup | it works in bionic I can confirm | 19:10 |
| tmlind | oh ok, might be the line break issue then | 19:10 |
| tmlind | freemangordon: hmm maybe i used the pdu to strip out the moto U1234 packet id's | 19:11 |
| tmlind | some more info on the varying line breaks in "gatsyntax: Allow '\n' to terminate line" | 19:13 |
| tmlind | if d4 produces ~+MSIM= but ofono is not parsing it and bionic is, chances are it's somehow related to the packet line breaks | 19:15 |
| tmlind | hmm or i guess d4 may produce ~+MSIM on a different dlci rather than /dev/gsmtty10 on bionic, seems unlikely though | 19:16 |
| Wizzup | Does n_gsm debug where the command goes? | 19:19 |
| freemangordon | no, it is there | 19:23 |
| freemangordon | tmlind: ^^^ | 19:23 |
| freemangordon | maybe ofono cannot parse the pdu | 19:23 |
| freemangordon | pasring results in G_AT_SYNTAX_RESULT_LINE: | 19:24 |
| freemangordon | not G_AT_SYNTAX_RESULT_PDU | 19:24 |
| tmlind | ok | 19:25 |
| tmlind | btw, i've noticed that doing ifdown wlan0 can hang the device at some point | 19:25 |
| freemangordon | I guess a0000000871002ff47f00189000001ff is the PDU in question? | 19:26 |
| tmlind | not sure | 19:26 |
| freemangordon | https://pastebin.com/9c10jEjz | 19:26 |
| tmlind | ok yeah so the notification is there, and ofono can't parse it somehow | 19:27 |
| freemangordon | mhm | 19:27 |
| freemangordon | on card remove: | 19:28 |
| freemangordon | U0003~+MSIM=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0. | 19:28 |
| freemangordon | this is parsed correctly | 19:28 |
| tmlind | the pdu is the raw packet, but if there's no U1234 in the beginning, then pdu parsing will fail | 19:28 |
| freemangordon | why 1234? | 19:28 |
| tmlind | oh but the packet id is there, U0004 in your pastebin, never mind | 19:28 |
| freemangordon | U0004~+MSIM=1,0,a0000000871002ff47f00189000001ff,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0. | 19:29 |
| freemangordon | on connect | 19:29 |
| tmlind | ok | 19:30 |
| freemangordon | hmm, unplug has one more 'parameter' at the end | 19:30 |
| freemangordon | U0003~+MSIM=0,0, 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0. | 19:30 |
| freemangordon | U0004~+MSIM=1,0,a0000000871002ff47f00189000001ff,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0. | 19:30 |
| tmlind | maybe try reverting or tweaking "gatsyntax: Allow '\n' to terminate line" and see if that helps on d4? | 19:30 |
| freemangordon | ok | 19:30 |
| tmlind | freemangordon: actually rather try reverting "gatsyntax: Allow terminating a PDU with a new line" on d4 and see if that helps | 19:32 |
| tmlind | probably the reason for using pdu parsing rather than line parsing was the varying line breaks.. | 19:34 |
| freemangordon | ugh | 19:34 |
| freemangordon | "~+MSIM=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" | 19:34 |
| freemangordon | there are 2 line feeds | 19:34 |
| freemangordon | why do we need "gatsyntax: Allow terminating a PDU with a new line"? | 19:35 |
| freemangordon | tmlind: I see this is your commit, where did you see the issue it fixes? | 19:36 |
| freemangordon | ok, I am confused | 19:38 |
| freemangordon | in dmesg there is only one 0x0a | 19:38 |
| freemangordon | tmlind: is it possible that tty add new lines becasue of some "terminal line size" or something? | 19:42 |
| freemangordon | *adds | 19:42 |
| freemangordon | ~+MSIM=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 len is 87 | 19:44 |
| freemangordon | ok, terminal seems to be opened in raw mode | 19:51 |
| freemangordon | so, where that additional line feed comes from?!? | 19:51 |
| freemangordon | oh, I see why | 19:59 |
| freemangordon | data comes from the modem on 2 packets | 19:59 |
| freemangordon | https://pastebin.com/xVgthPBJ | 20:00 |
| tmlind | ok, yeah different on d4 and bionic | 20:40 |
| freemangordon | hmm, how to connect adb? | 20:41 |
| freemangordon | I already enabled "developer options" or whatever | 20:41 |
| tmlind | enable usb debugging too? | 20:42 |
| freemangordon | yeah | 20:42 |
| freemangordon | tmlind: there is no /sys/module/ts27010mux/parameters/debug_level | 20:44 |
| freemangordon | ugh | 20:51 |
| freemangordon | I had to connect as root | 20:51 |
| tmlind | it's only there on lineageos kernels, not with the stock kernel | 20:53 |
| tmlind | not enabled in .config for the stock kernel i believe | 20:54 |
| freemangordon | I am on lineageos | 20:54 |
| tmlind | hmm weird | 20:54 |
| freemangordon | I was not connecting as root | 20:54 |
| freemangordon | as root, it is there | 20:54 |
| tmlind | oh ok | 20:54 |
| freemangordon | is there such thing as modprobe.d on android? | 20:55 |
| tmlind | so for the ofono serial read/write, the long term solution is to stop using gatchat and instead use ell to parse the raw packet data | 20:55 |
| tmlind | uvos might know how to enable loading modules | 20:56 |
| freemangordon | tmlind: well, I see no '\r' at the end of the string | 20:56 |
| tmlind | heh annoying | 20:56 |
| freemangordon | and I think this is th eissue | 20:56 |
| freemangordon | tmlind: I want to set ts27010mux parameter early in the boot process | 20:59 |
| tmlind | kernel cmdline? | 20:59 |
| freemangordon | if I only know how to modify it :) | 21:00 |
| tmlind | you can tweak that in droid4-kexecboot boot.cfg i think | 21:00 |
| freemangordon | like, this is some weird bootloader here | 21:00 |
| freemangordon | where is that? any idea? | 21:00 |
| freemangordon | mmcblk1p13? | 21:01 |
| tmlind | so droid4-kexecboot has an option to boot to stock android distro | 21:01 |
| freemangordon | this is what I use | 21:01 |
| freemangordon | and it boots to lineageos | 21:01 |
| tmlind | if you edit that boot.cfg file, it just does pivot root to the stock | 21:01 |
| freemangordon | but, where is that boot.cfg located? | 21:02 |
| tmlind | hmm where do you have lineageos installed/ | 21:02 |
| tmlind | ? | 21:02 |
| freemangordon | that's how I got the device :) | 21:02 |
| freemangordon | I guess Wizzup installed it for me | 21:02 |
| tmlind | ok | 21:02 |
| tmlind | so which boot option did you select for android in the bootloader menu? the "boot to stock android" one? | 21:03 |
| freemangordon | yes | 21:03 |
| tmlind | so mount the boot partition from android, and edit the boot.cfg file for that menu entry and you should be able to tweak the cmdline | 21:04 |
| tmlind | mount the bootloader partition i mean | 21:04 |
| freemangordon | which one is that? | 21:04 |
| freemangordon | /dev/mmcblk1p14 ? | 21:04 |
| freemangordon | this is marked as boot | 21:05 |
| tmlind | /dev/mmcblk1p13 | 21:06 |
| tmlind | but looking at /boot/boot.cfg the cmdline is just "stock", so it's in the boot script instead | 21:06 |
| freemangordon | mount /dev/block/mmcblk1p13 /mnt/boot | 21:07 |
| freemangordon | mount: '/dev/block/mmcblk1p13'->'/mnt/boot': Operation not supported on transport endpoint | 21:07 |
| freemangordon | :( | 21:07 |
| tmlind | oh and looking at sbin/preinit.sh, it just does pivot_root so no way to tweak the cmdline | 21:08 |
| freemangordon | hmm, wait | 21:09 |
| freemangordon | flight mode shall do the trick | 21:09 |
| tmlind | yeah for modem communication | 21:09 |
| tmlind | and you could tweak mmcblk1p13 sbin/preinit.sh to enable debug before the pivot_root | 21:10 |
| tmlind | or you could add a lineageos kexec menu to the boot.cfg on your micro-sd card with a custom cmdline | 21:11 |
| tmlind | hmm actually i forgot if kernel cmdline even works properly with the android stuff.. | 21:11 |
| freemangordon | I cannot mount mmcblk1p13 | 21:12 |
| freemangordon | from android that is | 21:12 |
| tmlind | ok | 21:12 |
| tmlind | you can mount it from m-l kernel though :p | 21:12 |
| freemangordon | well, yeah :) | 21:13 |
| tmlind | or check your micro-sd partitions for boot/boot.cfg file and yeah you can tweak the cmdline there | 21:13 |
| tmlind | multiple boot.cfg file are ok with kexecboot | 21:14 |
| tmlind | but if there's no lineage os kexec entry configured, don't bother wasting time with that | 21:15 |
| freemangordon | ok | 21:18 |
| freemangordon | tmlind: still, do you have any clue where that additional '\n' comes from? | 21:19 |
| freemangordon | for sure the modem does not send it | 21:19 |
| freemangordon | but it gets read from the tty | 21:19 |
| freemangordon | and this additional \n breaks it | 21:19 |
| freemangordon | hmm, it seems android pings the modem every 3 seconds | 21:20 |
| freemangordon | 0416~+RSSI=0,22,99,99,0,0,0 | 21:21 |
| freemangordon | etc | 21:21 |
| tmlind | that's with U1234AT+SCRN=1 set for status notifications | 21:24 |
| freemangordon | ah | 21:24 |
| tmlind | i thought the extra \n comes from d4 firmware? | 21:24 |
| freemangordon | anyway, I don;t see "UNSOL" commend used | 21:24 |
| freemangordon | no | 21:24 |
| freemangordon | it sends \n at the end | 21:25 |
| tmlind | maybe it's a \r in the middle? | 21:25 |
| freemangordon | but, there is one more \n that comes from somewhere else | 21:25 |
| freemangordon | no, it is \n | 21:25 |
| tmlind | is it not in the n_gsm debug=0xff packet dump? | 21:25 |
| freemangordon | it is not | 21:26 |
| tmlind | weird | 21:26 |
| tmlind | you sure? | 21:26 |
| freemangordon | see https://pastebin.com/xVgthPBJ | 21:26 |
| freemangordon | there is only one 0a | 21:26 |
| freemangordon | and this is printed by gdb: | 21:27 |
| freemangordon | "~+MSIM=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" | 21:27 |
| tmlind | not sure why the firmware sends it in multiple pieces, but it's packet data with a size and checksum so should not matter from ts27010 point of view | 21:28 |
| freemangordon | you mean from n_gsm POV guess | 21:29 |
| freemangordon | right, and it seems to process it correctly | 21:29 |
| tmlind | yeah | 21:29 |
| tmlind | so does ofono see the middle \n there too? | 21:30 |
| freemangordon | only ofono sees it | 21:30 |
| freemangordon | and that's why it fails to parese | 21:30 |
| freemangordon | *parse | 21:31 |
| tmlind | hmm | 21:31 |
| freemangordon | hmm ONOCR | 21:31 |
| tmlind | so doing ngsm 10 AT+MSIM? shows the sim with no line break in the middle | 21:32 |
| freemangordon | cfmakeraw does not set that flag | 21:32 |
| tmlind | where 10 is dlci10 | 21:32 |
| freemangordon | so it seems tty outputs \n at col 0 for some reason | 21:33 |
| tmlind | so also with ngsm 10 AT+MSIM? the dmesg shows the data returned in two pieces | 21:34 |
| tmlind | ngsm is my script for doing the commands fyi that adds the U1234 | 21:35 |
| freemangordon | tmlind: lemme try to set ONOCR | 21:35 |
| tmlind | if ngsm 10 AT+MSIM? returns sim data to the terminal with no line break, why would ofono see the line break? | 21:38 |
| tmlind | the line break in the middle i mean | 21:38 |
| freemangordon | where is ngsm script? | 21:38 |
| tmlind | my ngsm script is just: | 21:38 |
| tmlind | timeout 3 /bin/cat /dev/gsmtty${1} & | 21:38 |
| tmlind | busybox usleep 100000 | 21:38 |
| tmlind | printf "U%04i%s\r" $(date +%M%S) ${2} > /dev/gsmtty${1} | 21:38 |
| tmlind | first param is the dlci number, second is the AT command without the U1234 | 21:39 |
| freemangordon | yes, it sees it correctly | 21:42 |
| freemangordon | so no idea what's going on with ofono | 21:42 |
| tmlind | well ofono reads also dlci10, i suspect the middle \n is only in the dmesg | 21:43 |
| freemangordon | there is no \n in dmesg | 21:43 |
| freemangordon | 'middle \n' that is | 21:44 |
| freemangordon | it is only int the ofono vars | 21:44 |
| tmlind | weird | 21:45 |
| freemangordon | mhm | 21:45 |
| tmlind | added by gatchat based on some timeout? | 21:46 |
| freemangordon | I was not able to find any place where '\n' is appended or set | 21:46 |
| freemangordon | lemme attach gdb again | 21:46 |
| tmlind | gdb on ofono? | 21:49 |
| freemangordon | mhm | 21:49 |
| tmlind | ok | 21:50 |
| freemangordon | see https://pastebin.com/4X79tuXs | 21:50 |
| freemangordon | this is ... | 21:50 |
| freemangordon | ridiculous | 21:50 |
| freemangordon | received_data is a callback to g_io_add_watch_full | 21:51 |
| tmlind | not sure if the ngsm packet in two pieces can even be decoded properly until both pieces have arrived :) | 21:52 |
| freemangordon | the packet is there, it is just that there is some additional \n in the middle | 21:52 |
| freemangordon | "U0003~+MSIM=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n", | 21:53 |
| tmlind | maybe it's some n_gsm.c bug | 21:53 |
| freemangordon | this is the whole packet | 21:53 |
| freemangordon | could be, but how to track | 21:53 |
| tmlind | and why would the ngsm script not see it? | 21:53 |
| freemangordon | mhm | 21:53 |
| freemangordon | I think it is some termio thing | 21:53 |
| tmlind | sometimes the ngsm 10 AT+MSIM? data comes back in three pieces looking at dmesg | 21:55 |
| freemangordon | yes, but it seems n_gsm manages to gather it | 21:56 |
| freemangordon | or not? | 21:56 |
| tmlind | yeah output from the script is just fine as is the whole packet in dmesg after the pieces | 21:57 |
| freemangordon | mhm | 21:57 |
| tmlind | could it be some uncleared buffer in ofono? | 21:58 |
| freemangordon | could be | 21:58 |
| freemangordon | lemme try to find | 21:58 |
| tmlind | also check in your dmesg the parsed packet after "<-- 10) C: UIH(F)" is fine when ofono has a problem | 21:59 |
| freemangordon | alredy did | 21:59 |
| freemangordon | *already | 21:59 |
| freemangordon | it is fine | 21:59 |
| tmlind | ok, so is the ofono extra \n always in the same place? | 22:00 |
| freemangordon | not sure | 22:00 |
| freemangordon | still debugging | 22:01 |
| tmlind | to me it seems the parsed packet from kernel should be ok with no extra \n in between, well should | 22:01 |
| tmlind | maybe it somehow depends on the read size? | 22:02 |
| tmlind | fixed line lenght in ofono? :) | 22:03 |
| tmlind | wrapt to 80 chars? :) | 22:03 |
| tmlind | 92 chars? | 22:04 |
| freemangordon | ok, it gets correct data from g_io_channel_read_chars | 22:05 |
| freemangordon | lemme continue debugging | 22:05 |
| tmlind | hmm we skip past the first five chars in the pdu to ignore the U1234, maybe the math goes wrong there for the buffer size | 22:05 |
| freemangordon | what the? this time it is ok | 22:07 |
| tmlind | weird | 22:09 |
| tmlind | maybe i introduced a hard to find bug with the p->hdrlen changes | 22:09 |
| freemangordon | maybe it it gets read in chunks | 22:09 |
| freemangordon | or rather - the bug appears when data is read in chunks | 22:10 |
| freemangordon | and someone appends '\n' | 22:10 |
| tmlind | a good reason to replace gatchat with raw read and write functions using ell | 22:13 |
| tmlind | maybe the change i did for at_chat_handle_command_response() fails to find anything if read in chunks | 22:19 |
| freemangordon | will see | 22:19 |
| tmlind | resp = strstr(line, p->delimiter); | 22:20 |
| tmlind | won't find the delimter and gatchat goes doing what it does | 22:20 |
| freemangordon | why response? | 22:21 |
| freemangordon | this is unsolicited message | 22:21 |
| tmlind | hmm | 22:22 |
| freemangordon | hmm, modem does not report events anymore, rebooting | 22:25 |
| tmlind | not sure but probably gatchat is parsing all the data coming from the line, it's been a while | 22:25 |
| freemangordon | btw, it seems qmimodem received sim insertion notificationm | 22:26 |
| tmlind | ok, zzz time here, ttyl | 22:28 |
| freemangordon | gn | 22:28 |
| Wizzup | btw, lenovo has an arm thinkpad laptop now | 23:50 |
| Wizzup | seems kinda nice, without fans | 23:50 |
| Wizzup | mostly random remark but yeah it's kinda cool | 23:50 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!