| tmlind | freemangordon: did you still have some question for me? :) | 07:56 |
|---|---|---|
| freemangordon | tmlind: I guess a couple of :), not now though | 07:59 |
| tmlind | freemangordon: ok | 08:00 |
| tmlind | bencoh: the thermal sensor is different between 34xx and 36xx afaik | 08:00 |
| tmlind | bencoh: in case there really is a thermal shutdown capability on 34xx, then mmc1_dat4 may be available depending if data line numbering starts from 0 or 1 as only four data lines are used for mmc1 | 08:01 |
| tmlind | Wizzup, bencoh: maybe check how fremantle has muxed mmc1_dat4/gpio_126 with rwmem -s 16 0x48002150 | 08:08 |
| tmlind | if it's mmc1_dat5/gpio_127 instead, then rwmem -s 16 0x48002152 | 08:09 |
| tmlind | see also 35xx trm page 874 for reference | 08:11 |
| tmlind | also, see if n900 temp sensor ends up getting fixed and enabled, then see also commit 5c3db2d4d4ed ("ARM: dts: motorola-mapphone: Configure lower temperature passive cooling") | 08:30 |
| tmlind | waking up the system once a second is not nice for pm :) | 08:30 |
| tmlind | for the poll time testing with heavy cpu load you can monitor the temperature, for droid4 10 seconds seemed like plenty of time to react | 08:31 |
| freemangordon | tmlind: the point is that omap34 thermal driver doesn't seem to support tshut gpio at all | 09:05 |
| freemangordon | and I wonder what happens if gpios start behaving on OFF mode | 09:05 |
| freemangordon | is it possible the interrupt/oops we see to be tshut gpio irq | 09:06 |
| freemangordon | tmlind: also, why gpio_126? | 09:06 |
| tmlind | freemangordon: the tshut seems to be gpio_127, i think bencoh got the mmc dat line wrong earlier | 09:09 |
| freemangordon | according to n900 schematics, mmc1_data4-mmc1_data7 are not connected | 09:10 |
| tmlind | freemangordon: gpio bank4 is not powered off during off mode, it won't produce any interrupt during off mode, the only way to do that would be based on the padconf interrupt | 09:10 |
| freemangordon | which means gpio_127 is not connected | 09:10 |
| tmlind | yeah duping the gpio_127 padconf value from fremantle kernel would show | 09:11 |
| tmlind | if it's not muxed to gpio_127 mode, then tshut interrupt is not used at all | 09:11 |
| freemangordon | tmlind: I understand, but if we have gpios behaving we could have phantom gpio interrupt, no? | 09:11 |
| freemangordon | tmlind: hmm, well, there seem to be some "comparator" there | 09:12 |
| tmlind | freemangordon: if tshut is a an edge interrupt, there may not be any status to be seen after waking up from off mode | 09:12 |
| tmlind | except ifconfigured as a padconf interrupt | 09:12 |
| tmlind | possibly | 09:12 |
| freemangordon | ugh, this is sim_clk too in mode2 | 09:13 |
| tmlind | so mux to gpio_127 mode, in the dts configure tshut interrupt as the padconf pin interrupt and not as gpio_127 | 09:13 |
| freemangordon | tmlind: I doubt this is used as gpio_127, iiuc sim_clk is used | 09:14 |
| tmlind | see the interrupts-extended configuration for let's say n900 uart | 09:14 |
| tmlind | freemangordon: ok, yeah dumping out the related padconf register from fremantle kernel would show | 09:14 |
| freemangordon | ok, lemme connect to my prod device | 09:15 |
| freemangordon | good that I have devmem2 there :) | 09:15 |
| tmlind | hmm actually, the sim is on the modem, not on 34xx, so unlikely sim_clk is used | 09:16 |
| freemangordon | Value at address 0x48002152 (0x4001f152): 0x7 | 09:17 |
| freemangordon | somebody shall do that on leste | 09:17 |
| freemangordon | Wizzup: ^^^ | 09:17 |
| tmlind | safe mode, not used at all, so yeah experimenting remuxing to gpio_127 and configuring the padconf interrupt as tshut is doable | 09:17 |
| freemangordon | tmlind: any clue what to dump to verify that? | 09:18 |
| freemangordon | ugh, I lost the diagram | 09:20 |
| tmlind | freemangordon: enable padconf register 0x48002152 wake bit manually after muxing to gpio_127 mode and see if you can get 0x48002152 event bit to trigger | 09:21 |
| tmlind | then just start compiling code | 09:22 |
| tmlind | or whatever might trigger overheating, i guess you could tweak the thermal alert values if doable | 09:22 |
| tmlind | see WAKEUPENABLE and WAKEUPEVENT for the padconf, 35xx trm page 769 | 09:23 |
| bencoh | tmlind: ah nice, I didn't check if those were in use indeed :) | 09:24 |
| tmlind | those get automatically handled if a pad is configured as a wakeirq in the dts, like we have for uart3 rx pin for example | 09:24 |
| tmlind | if the padconf as tshut interrupt works, then ti-bandgap.c needs to be updated to understand interrupts property from dts, right now it seems to only understand a gpio pin | 09:29 |
| freemangordon | tmlind: I was not able to find TSHUT trigger temperature configuration in TRM | 09:31 |
| freemangordon | for 3430 that is | 09:31 |
| freemangordon | also, I am not sure i understand Figure 25-1 in the TRM | 09:32 |
| freemangordon | in regards to gpio 127 that is | 09:32 |
| tmlind | hmm my 35xx trm does not seem to have any 25-1 for gpio_127 | 09:34 |
| freemangordon | this is p. 3331 | 09:35 |
| freemangordon | Figure 25-1. General-Purpose Interface Overview | 09:35 |
| freemangordon | SWPU223M – July 2007 – Revised February 2011 | 09:35 |
| freemangordon | this is 34xx, not 35xx | 09:35 |
| tmlind | oh ok, seems to be "Figure 24-1. General-Purpose Interface Overview" for 35xx trm | 09:35 |
| tmlind | i guess the idea is that the tshut could be also handled externally by pmic for example? | 09:36 |
| freemangordon | hmm, yeah, could be | 09:36 |
| tmlind | i guess my question still is: what stops battery charger automatically if battery overheats? | 09:39 |
| freemangordon | sec (phone call) | 09:39 |
| tmlind | Pali: so does the bq2415x autotimer stop charger automatically if not kicked? | 09:44 |
| freemangordon | tmlind: on fremantle it is userspace that does it, afaik | 09:44 |
| freemangordon | on leste I guess noone :) | 09:44 |
| tmlind | freemangordon: well let's hope the bq2415x hardware timer automatically disables the charger if the os is hung | 09:46 |
| freemangordon | I doubt that's the case | 09:47 |
| freemangordon | but yeah, lets wait for Pali | 09:47 |
| tmlind | yeah | 09:47 |
| Pali | tmlind: yes | 09:48 |
| Pali | HW automatically reset charger registers to default values, which disable charging | 09:49 |
| tmlind | Pali: ok good to hear & thanks for confirming | 09:51 |
| Pali | :-) | 09:52 |
| tmlind | so the soc thermal stuff is a completely separate story then | 09:52 |
| tmlind | i guess the worst thing that can happen with the soc thermal failing is the device overheats and hangs or reboots | 09:53 |
| tmlind | so assuming the soc bandgap continuous mode helps with the long polling issue, the poll value could easily be 10 secs instead of 1 sec | 09:54 |
| tmlind | and then if somebody feels like tinkering, configuring the tshut interrupt is doable, but the polling already check the values | 09:55 |
| tmlind | Wizzup: if you can test your known working pm setup with the TI_BANDGAP_FEATURE_CONT_MODE_ONLY patch and increase cpu_thermal dts polling-delay-passive and polling-delay to 10000 ms, and see if n900 still keeps hitting off during idle normally | 09:56 |
| freemangordon | tmlind: sorry, I don;t get it why we need contiguous mode | 09:57 |
| tmlind | Wizzup: or if you have a patch that makes v5.15 enter off mode during idle on n900 normally let me know | 09:57 |
| freemangordon | fremantle kernel uses single mode happily | 09:57 |
| tmlind | freemangordon: i recall getting a bandgap value takes tens or hundreds of ms on omap34xx, just wondering if the continuous mode happens to fix that issue, needs to be traced for some timestamps | 09:58 |
| freemangordon | iiuc it takes 36 sycles | 09:59 |
| freemangordon | *cycles | 09:59 |
| freemangordon | on 32767 Hz | 09:59 |
| tmlind | oh ok, maybe that's only on 36xx then | 09:59 |
| freemangordon | the question is if contiguous mode increases idle current | 09:59 |
| tmlind | well it's only enabled when sampling, not continuously | 10:00 |
| tmlind | the continuous mode may not be needed at all on omap3, just wondering as Wizzup said it blocks idle | 10:00 |
| * tmlind adds some trace_printk to check | 10:01 | |
| tmlind | current values: | 10:07 |
| tmlind | 50.098541: ti_bandgap_restore_ctxt: restore bandgap | 10:07 |
| tmlind | 50.098541: ti_bandgap_force_single_read: wait eocz up | 10:07 |
| tmlind | 50.099121: ti_bandgap_force_single_read: done eocz up | 10:07 |
| tmlind | 50.099121: ti_bandgap_force_single_read: wait eocz down | 10:07 |
| tmlind | 50.100342: ti_bandgap_force_single_read: done eocz down | 10:07 |
| tmlind | with TI_BANDGAP_FEATURE_CONT_MODE_ONLY flag added: | 10:07 |
| tmlind | 4040.103027: ti_bandgap_restore_ctxt: restore bandgap | 10:07 |
| tmlind | 4040.103058: ti_bandgap_force_single_read: wait eocz up | 10:07 |
| tmlind | 4040.103607: ti_bandgap_force_single_read: done eocz up | 10:07 |
| tmlind | 4040.103607: ti_bandgap_force_single_read: wait eocz down | 10:07 |
| tmlind | 4040.104828: ti_bandgap_force_single_read: done eocz down | 10:08 |
| freemangordon | tmlind: single mode works in fremantle kernel, so I think you are right and no need for contiguous mode | 10:08 |
| tmlind | yeah so it seems, maybe it was only an issue on 36xx or maybe 4430.. | 10:09 |
| tmlind | anyways, increasing the dts polling-delay values should be done | 10:10 |
| freemangordon | what was the current one? | 10:11 |
| tmlind | Wizzup: or is the system not entering off during idle if CONFIG_OMAP3_THERMAL=y, or am i confused about that too? | 10:11 |
| tmlind | freemangordon: currently set to 250 / 1000 ms, probably setting both to 10000 should be ok | 10:11 |
| freemangordon | ugh, 250 ms seems a bit fast to me :) | 10:12 |
| tmlind | yeah i wonder if that's some oversampling | 10:12 |
| tmlind | anyways, we restore the context on every exit from a deeper idle state, i wonder if that is needed at all | 10:14 |
| tmlind | at least on 4430 the bandgap register does not seem to lose context | 10:15 |
| tmlind | on omap3 it's in control module that should have automatic restore enabled i think? | 10:15 |
| freemangordon | no idea :) | 10:15 |
| freemangordon | I would trust you on that one | 10:15 |
| tmlind | well let's see if i get sane values after disabling context restore and waiting for off idle | 10:16 |
| tmlind | will check that later on | 10:20 |
| tmlind | hard to say if context is lost as i'm having hard time getting n900 to enter off during idle.. | 11:06 |
| tmlind | yup the context restore is needed, otherwise omap3 context lost counters never increase for off during idle | 11:21 |
| tmlind | Wizzup: so sounds like increasing the dts timeouts is the only thing needed for thermal sensor, no idea what might be causing the crashes you're seeing though | 11:23 |
| tmlind | unless reading the thermal register values somehow produce invalid values that cause some software bug with table index out of range or similar | 11:24 |
| tmlind | see earlier commit 30d24faba053 ("thermal: ti-soc-thermal: Fix bogus thermal shutdowns for omap4430") | 11:25 |
| tmlind | freemangordon: care to check that we really have the right temp table for 34xx compared to fremantle kernel? it seems like it might be the same currently as for 36xx | 11:27 |
| tmlind | oh never mind, the 34xx table is different from the 36xx table, split window comaprison of two copies of 34xx table accident :) | 11:29 |
| freemangordon | tmlind: sorry, cannot do now, RL job :) | 11:40 |
| Wizzup | freemangordon: regarding what you want me to dump (0x48002152) - do you want me to do that with thermal/bandgap enabled or not, and with or without tony's patch | 13:03 |
| Wizzup | tmlind: ok, can do that @ 10000ms with known-working | 13:05 |
| Wizzup | (still reading backlog) | 13:06 |
| Wizzup | tmlind: ok, I'll increase the timeout and re-enable OMAP3_THERMAL and test if it enters idle | 13:07 |
| Wizzup | but yeah, the oopses would still be a problem if I read the backlog correctly | 13:08 |
| tmlind | Wizzup: yeah so for me v5.15 only rarely hits off even with the compact timeout part reverted | 13:08 |
| tmlind | yup | 13:08 |
| Wizzup | tmlind: and if you revert OMAP3_THERMAL ? | 13:08 |
| Wizzup | or rather, disable it | 13:08 |
| Wizzup | (in config) | 13:09 |
| tmlind | well that patch did not cleanly revert against v5.15 | 13:09 |
| tmlind | even with .config change, the timeout is still there, right? | 13:09 |
| tmlind | or are you seeing v5.15 hitting off easily when idle? | 13:09 |
| Wizzup | Yes, my current 5.15 hits OFF easily when in init=/bin/bash and OMAP3_THERMAL=n | 13:09 |
| Wizzup | of course serial has to be detached | 13:10 |
| tmlind | hmm, so with only .config option for compaction disabled? | 13:10 |
| tmlind | i'm seeing 36xx enter off all the time with same kernel.. of course it has much faster cpuidle times configured | 13:11 |
| Wizzup | https://github.com/maemo-leste/droid4-linux/commit/894f9b2f68be41971ef1c2d8adacb3cbc0bfcb05 | 13:11 |
| Wizzup | https://github.com/maemo-leste/droid4-linux/commit/d3b8625fd76fc839fc95e90b9117fafaf2d377bb | 13:11 |
| Wizzup | https://github.com/maemo-leste/droid4-linux/commit/7942557de8e09b9851b19a8c392227b16fa1b74f | 13:11 |
| Wizzup | I believe these three should be enough | 13:11 |
| Wizzup | (you can append .patch to the url to get the patch directly) | 13:11 |
| Wizzup | well technically enabling off mode automatically is not required, but it was a nuisance when testing for me | 13:12 |
| Wizzup | (reverting enabling off mode automatically*) | 13:12 |
| tmlind | ok.. so are you seeing the oopses even with CONFIG_OMAP3_THERMAL disabled | 13:12 |
| Wizzup | yes, I believe that is the case | 13:12 |
| tmlind | hmm but the bandgap should not do anything if CONFIG_OMAP3_THERMAL is disabled? or is there some generic option still doing something? | 13:13 |
| Wizzup | that's a good question, that I don't quite know | 13:15 |
| Wizzup | I only see bandgap as thermal sensor in the omap3-cpu-thermal dtsi | 13:21 |
| Wizzup | tmlind: if you want I can share the commands I run to get the device to enter off mode, are you on some 5.15 based tree? | 13:28 |
| tmlind | Wizzup: i can get it to enter off, but only few times a minute.. sounds like i should try with CONFIG_OMAP3_THERMAL disabled | 13:58 |
| tmlind | yeah v5.15 based tree | 13:58 |
| Wizzup | it takes maybe 15-20 seconds for it to idle for me | 13:59 |
| Wizzup | yeah, give that a try, I think that will make all the difference | 13:59 |
| tmlind | ok | 14:00 |
| tmlind | disabling CONFIG_OMAP3_THERMAL does not seem to make any difference for me, rarely hits off | 14:05 |
| Wizzup | this is with just init=/bin/sh or similar? | 14:06 |
| tmlind | yeah just a minimal init script | 14:06 |
| Wizzup | hm... I think my tree is based on 5.15.2, maybe some other patch introduced another regression | 14:07 |
| tmlind | i'm on v5.15.2 also | 14:08 |
| Wizzup | no modules loaded? | 14:08 |
| tmlind | only rtc_twl, twl4030_wdt and watchdog | 14:08 |
| tmlind | i recall the same setup idling just fine years ago | 14:09 |
| Wizzup | ok, I don't have any loaded, but watchdog built in | 14:09 |
| tmlind | ok | 14:09 |
| tmlind | so how many times approximately are you seeing n900 enter off in a minute? | 14:10 |
| tmlind | tens? | 14:10 |
| Wizzup | sorry, I will have to measure it. I think it would stay in OFF sometimes for 20+ seconds | 14:11 |
| Wizzup | I will measure it momentarily, brb | 14:11 |
| tmlind | ok, i doubt my system sleeps that long compared to my 36xx test board.. | 14:11 |
| tmlind | if it does, that would explain the low off mode counts | 14:12 |
| Wizzup | tmlind: I mean I am just basing that (it stays there for 20+ seconds)_off of looking at my lab psu | 14:25 |
| Wizzup | I just kind assuming that was how it was suppose to be - stay in OFF as long as possible | 14:26 |
| tmlind | right that would be good news indeed :) | 14:40 |
| Wizzup | tmlind: do you want me to measure it still? | 14:54 |
| tmlind | Wizzup: sure when you can, i can't measure on my n900 | 14:54 |
| Wizzup | ok, what do you want measured exactly? | 14:55 |
| Wizzup | just the OFF and RET counts, or also power usage? | 14:55 |
| * Wizzup doing both | 14:59 | |
| Wizzup | tmlind: https://wizzup.org/n900-power.png from boot to idle | 15:05 |
| Wizzup | the spike at the end is me typing this: | 15:06 |
| Wizzup | # grep ^core_pwrdm /sys/kernel/debug/pm_debug/count | cut -d',' -f2, | 15:06 |
| Wizzup | OFF:13,RET:6 | 15:06 |
| Wizzup | this is milli amps at 3.8V btw | 15:07 |
| Wizzup | not mW | 15:07 |
| tmlind | nice :) | 15:12 |
| tmlind | not sure why i'm not seeing off more.. but good to hear you have it working | 15:14 |
| Wizzup | tmlind: it would be better if we both see it working I'd say | 15:14 |
| Wizzup | so what are you seeing now and what would you expect? | 15:15 |
| tmlind | i'm kind of expecting off to happen more often like my 36xx based system is doing, could be n900 manages to sleep a really long time here too.. i should see that from cpuidle stats | 15:19 |
| Wizzup | ok, I could check my setup if it is helpful btw | 15:21 |
| Wizzup | not sure what you check in cpuidle | 15:21 |
| tmlind | not sure if this is a count or time.. but cat /sys/devices/system/cpu/cpu0/cpuidle/state[0123456]/usage | 15:24 |
| tmlind | ah do cat /sys/devices/system/cpu/cpu0/cpuidle/state[0123456]/time | 15:25 |
| tmlind | # cat /sys/devices/system/cpu/cpu0/cpuidle/state[0123456]/time │per_clkdm->per_pwrdm (14) | 15:25 |
| tmlind | 5983795 │cam_clkdm->cam_pwrdm (0) | 15:25 |
| tmlind | 551970976 │dss_clkdm->dss_pwrdm (1) | 15:25 |
| tmlind | 7857910 │192:~# | 15:25 |
| tmlind | 0 │192:~# | 15:25 |
| tmlind | 4222905243 │192:~# | 15:25 |
| tmlind | 0 │192:~# | 15:25 |
| tmlind | oops sorry copy from tmux.. | 15:25 |
| Wizzup | https://dpaste.com/2LZBPSPLJ.txt | 15:26 |
| Wizzup | that's for the last ~30 minutes | 15:27 |
| tmlind | for me state4 is hit way more than state6 | 15:27 |
| Wizzup | oh, I think I know what might be up | 15:28 |
| tmlind | ok | 15:28 |
| Wizzup | try to unload the panel module after you set brightness | 15:28 |
| Wizzup | or apply sre's patch from 'Re: Nokia N900 increased power draw with panel-sony-acx565akm loaded v5.9 and v5.10' | 15:28 |
| tmlind | ah so load panel, then unload? | 15:29 |
| Wizzup | yes, load panel, set brightness, unload | 15:29 |
| tmlind | weird | 15:29 |
| Wizzup | I mailed linux-omap about this too | 15:29 |
| Wizzup | and bisected the regression as well | 15:29 |
| Wizzup | current 5.15.2 panel driver causes the module to never hit 42mW for me (0.11A in that graph, subtract 0.04A for the serial module) | 15:30 |
| Wizzup | I suppose that could be what you're seeing, not sure | 15:30 |
| Wizzup | but it's the one change I did have locally | 15:30 |
| tmlind | hmm not sure how that could affect how often off mode is entered though | 15:31 |
| tmlind | i can see it make a difference to the power consumption :) | 15:32 |
| Wizzup | ok | 15:32 |
| Wizzup | let me mail you my setup | 15:32 |
| tmlind | well i guess i should try with your git branch | 15:32 |
| Wizzup | it's possible that some of your loaded modules case more wake ups? | 15:35 |
| tmlind | i guess | 15:36 |
| Wizzup | with (many) modules loaded and booted to maemo leste recovery mode I can also only hit RET, never OFF | 15:36 |
| Wizzup | I could try to load the ones you have loaded | 15:36 |
| tmlind | heh sure | 15:36 |
| Wizzup | yeah this looks quite different (from quick observation) | 15:37 |
| Wizzup | I'll let it run for 5 mins and share the graph | 15:37 |
| tmlind | ok | 15:38 |
| tmlind | i'm also starting the watchdog with a script | 15:39 |
| tmlind | oh sorry, it's commented out so not starting watchdog | 15:39 |
| Wizzup | https://wizzup.org/n900-power-modules.png | 15:40 |
| tmlind | so not the modules | 15:41 |
| Wizzup | I am not so sure, it seems to use more power for sure | 15:41 |
| Wizzup | I'd have to reboot the device and insert the modules right away, and idle for 5 minutes do have an accurate comparison | 15:42 |
| tmlind | oh ok | 15:42 |
| Wizzup | It's now basically stuck in 0.016A way more often than 0.011A | 15:42 |
| Wizzup | I'll let it run for a while longer... | 15:43 |
| Wizzup | do you use the rtc for something? | 15:43 |
| tmlind | rtcwake -m mem -s 5 | 15:58 |
| Wizzup | interesting, that definitely made some change, let me observe it a bit | 16:00 |
| bencoh | rtcwake should just fire the alarm though | 16:01 |
| bencoh | well, and enter suspend | 16:01 |
| Wizzup | it never hits 0.011A anymore, it's 0.012A | 16:03 |
| Wizzup | otherwise seems mostly stable | 16:03 |
| bencoh | I dunno about your PSU, but usually they aren't that great at measuring output current anyway | 16:04 |
| bencoh | 11mA vs 12mA might just be an accuracy issue | 16:05 |
| Wizzup | well, it was always 11mA befoer | 16:05 |
| Wizzup | but yeah I suppose | 16:05 |
| bencoh | maybe it was 11.9 :) | 16:05 |
| uvos | the least siginifcant digit is allways gona be +-1 on any instrument | 16:05 |
| uvos | just because of quantization alone | 16:05 |
| Wizzup | bencoh: yeah, but it's still -measurable- is what I mean | 16:05 |
| bencoh | in your case it seemed pretty stable indeed ... dunno :) | 16:06 |
| bencoh | anyway, I thought you guys were testing OFF mode? how is rtcwake related? | 16:07 |
| Wizzup | we are trying to figure out what is causing tmlind his device to enter off mode less and also different cpuidle states | 16:07 |
| tmlind | Wizzup: so your kernel branch behaves the same way, must be something in the userspace causing timers | 17:03 |
| Wizzup | hm, I boot with init=/bin/bash | 17:06 |
| Wizzup | [ 0.000000] Kernel command line: root=/dev/mmcblk0p2 rootwait console=ttyS2,115200 verbose earlyprintk debug init=/bin/bash | 17:16 |
| rafael2k | hi everybody - just passing buy - happy the pinephone keybaord will start selling "first weeks of january" | 20:05 |
| rafael2k | ; ) | 20:05 |
| rafael2k | btw, since latest kernel update, about 6 months ago, pinephone is with broken telephony support in kernel... | 20:06 |
| rafael2k | *passing by | 20:08 |
| rafael2k | I finally bought a SIM card with data plan for my pinephone, and now I can confirm latest kernel update long time ago broke telephony, as I suspected. | 20:08 |
| rafael2k | I'll just copy the kernel and modules from mobian and be happy | 20:14 |
| rafael2k | ow yeah, 4G working | 20:41 |
| rafael2k | I made a tarball with the kernel and modules.. just uncompressing in the root directory will work. I'm uploading to the lazy ones which just want maemo working and don't have time (yet) to update the broken kernel shipped: | 20:44 |
| rafael2k | http://173.255.215.196/pinephone/kernel.tar.gz | 20:47 |
| rafael2k | the config is there, in case of a saint want to build a proper package | 20:47 |
| rafael2k | now back to reality - which is url of the dialer someone was developing? | 20:48 |
| uvos | https://github.com/maemo-leste/sphone | 20:53 |
| uvos | https://github.com/maemo-leste/gtk/commit/662fc8c689f13e387494fdfe4046c9d2143ba0bc | 20:53 |
| uvos | freemangordon: ^^^ that dosent really fix the issue tho | 20:53 |
| rafael2k | tks!! | 20:54 |
| rafael2k | http://173.255.215.196/pinephone/maemo.png <- ma 4G is back! | 20:54 |
| rafael2k | ; ) | 20:54 |
| uvos | freemangordon: i mean the ranges work then, but the real issue that the coodinates are different between a widget inside of a hildon-pannable-area and one outside is not solved | 20:54 |
| uvos | this seams to just sweep the real issue under the rug for this one widget | 20:54 |
| uvos | appearanly the favorite solution to any problem for nokia engineers to any problem | 20:55 |
| uvos | *appearanly the favorite solution to any problem for nokia engineers | 20:55 |
| rafael2k | the MTS network is not configured for VoLTE, it uses CSFB and switched to GSM in a voice call. cool | 21:06 |
| rafael2k | sphone is not working yet, but I'm happy I got it up and now I can start debugging things | 21:07 |
| uvos | are you using ofono to start calls? | 21:07 |
| uvos | obv. the prerequisit for sphone working is ofono working | 21:07 |
| uvos | if ofono works but sphone dosent work plase "killall sphone; sphone -v -v -c dialer-open" | 21:09 |
| uvos | and show the log | 21:09 |
| sicelo | rafael2k: nice to see the icon on a real device :-) | 21:09 |
| rafael2k | ofono scripts, yes | 21:11 |
| rafael2k | in /usr/share/ofono | 21:12 |
| rafael2k | lemme try | 21:12 |
| rafael2k | tks uvos | 21:12 |
| uvos | also some description on what dosent work would also be helpfull ofc | 21:13 |
| rafael2k | Unable to transmit dial number via ofono | 21:13 |
| rafael2k | sphone: comm-ofono: Error: GDBus.Error:org.ofono.Error.NotImplemented: Implementation not provided | 21:14 |
| rafael2k | nothing works | 21:14 |
| rafael2k | ; ) | 21:14 |
| rafael2k | receiving a call or originating a call | 21:14 |
| uvos | ofono is running, the modem is enabled and onlined? | 21:15 |
| rafael2k | yeap | 21:15 |
| uvos | could you give the the full log | 21:15 |
| rafael2k | https://pastebin.com/UNrtF8Ug | 21:16 |
| rafael2k | btw, now my head is in "play mode", but I wanna help updating the kernel of pinephone | 21:17 |
| rafael2k | I wanna have my maemo full set before the keyboard arrives home | 21:18 |
| rafael2k | ; ) | 21:18 |
| calx | Does anybody know whether it's possible to use the vanilla Devuan installer if I've got a PINEPHONE with keyboard, mouse, & ethernet? I can do some development, but I'm a n00b at arm64, having dipped my toes in a long time ago but feeling frustrated failing to remember what I used to know. | 21:21 |
| sicelo | calx: to install Leste? or Devuan? | 21:23 |
| calx | To work towards Leste from a minimal Devuan install. | 21:24 |
| uvos | not sure why you would want to do that | 21:25 |
| uvos | and i dont think there is a devuan image for the pp | 21:25 |
| calx | Because I'm accustomed to working from a fairly minimal Devuan environment. | 21:25 |
| uvos | you would have to use the usual method to create a debian/devuan rootfs | 21:25 |
| uvos | and add some kernel of your choosing | 21:25 |
| uvos | just using some generic installer isent how it works in the arm world because we dont have generic kernels or bootloaders | 21:26 |
| rafael2k | uvos: SMS is working! | 21:26 |
| uvos | btw | 21:26 |
| uvos | you have to install rtcom eventlogger modules | 21:27 |
| uvos | but thats untrelated to the voice call problem | 21:27 |
| uvos | thats pretty wierd | 21:27 |
| uvos | i currently dont get why the interface would not exist on pp | 21:27 |
| rafael2k | btw, I'm using the repository package | 21:27 |
| uvos | dose the pp show more than one modem in ofono | 21:27 |
| uvos | ie list-modems? | 21:28 |
| sicelo | if your ultimate goal is Leste, then just start where Leste for PP is today, and improve. Leste is already as minimal as it gets. No bloat at all. of course if your ultimate goal is devuan .. different story | 21:28 |
| rafael2k | just the [ /quectelqmi_0 ] | 21:28 |
| rafael2k | nterfaces = org.ofono.ConnectionManager org.ofono.NetworkRegistration org.ofono.SupplementaryServices org.ofono.NetworkMonitor org.ofono.SmartMessaging org.ofono.PushNotification org.ofono.MessageManager org.ofono.LongTermEvolution org.ofono.RadioSettings org.ofono.MessageWaiting org.ofono.AllowedAccessPoints org.ofono.SimManager org.ofono.VoiceCallManager | 21:29 |
| rafael2k | it seems all there | 21:29 |
| uvos | could you try exercising org.ofono.VoiceCall.dial with dbus-send? | 21:31 |
| uvos | thats the call thats failing for sphone | 21:31 |
| freemangordon | uvos: sorry, I don;t get why you think the issue is not solved | 21:31 |
| freemangordon | hildon-pannable-area has nothing to do with the issue | 21:32 |
| freemangordon | this was a but introduced in upstream gtk and my commit fixed | 21:32 |
| freemangordon | it | 21:32 |
| freemangordon | hildon-pannable-area *does not* receive motion events for GtkRange widgets | 21:33 |
| rafael2k | uvos: yes | 21:33 |
| freemangordon | this https://github.com/maemo-leste/gtk/commit/662fc8c689f13e387494fdfe4046c9d2143ba0bc#diff-890a5aa29b52eca8626a9f83f8447b07bae358f756146ac8ca7f20a2746b333bR154 is the actual fix | 21:34 |
| freemangordon | and this is not part of 'hildonizing' GtkRange | 21:34 |
| freemangordon | my bad that I didn;t do a separate commit | 21:34 |
| uvos | freemangordon: if i place a slider wdiget into a pannable area i get different coordinates origin points in gdb for motion events than if i place it into a gtk_scrolled_window | 21:34 |
| calx | Yeah, I imagine I can start with Leste, strip it, and build it back up to get comf with it. The wiki says to format the card as ext4, is that supposed to be raw ext4 or with a MBR or GUID? | 21:34 |
| uvos | freemangordon: disregarding what the reason is for this | 21:34 |
| freemangordon | uvos: could be, but that's not HPA's fault | 21:35 |
| uvos | i dont see how that would not trip up any custom widgets | 21:35 |
| uvos | that use the events | 21:35 |
| rafael2k | same error | 21:35 |
| sicelo | calx: again - what's your end goal? devuan or leste? if leste, how will stripping it help? of course, ultimately it's your choice what you do, but i'm curious nonetheless | 21:35 |
| freemangordon | also, what makes you think HPA miscalculates event coordinates? | 21:35 |
| rafael2k | ./dial-number .... | 21:35 |
| rafael2k | dbus.exceptions.DBusException: org.ofono.Error.NotImplemented: Implementation not provided | 21:35 |
| uvos | freemangordon: well if i place the widget into any other container it works fine | 21:36 |
| uvos | and the coordinates are allways seseable and the same | 21:36 |
| freemangordon | and what widget does not work fine if you place it in HPA? | 21:36 |
| uvos | if i place it into a HPA the coordinates are very different (alligned to the hpa instad of the child widget) | 21:36 |
| freemangordon | so what? | 21:36 |
| calx | I'm gonna do leste from the start, the wiki just isn't as explicit as I prefer my directions to be. I had an N900 back in the day... man, those were the days! | 21:36 |
| uvos | well hpa behaves differently than any other container in this case, i only know of the slider that uses these events, but any application that implements a custom widget will trip over this if it uses these evetns | 21:37 |
| freemangordon | no, not really | 21:37 |
| calx | I also haven't used IRC in ages. Thanks for replying to me sicelo | 21:38 |
| freemangordon | slider was calling wrong function because of the way it is implementd | 21:38 |
| uvos | if it expects the hpa to work like any other gtk container | 21:38 |
| uvos | yes really | 21:38 |
| freemangordon | argh | 21:38 |
| freemangordon | look at the commit that breaks it | 21:38 |
| rafael2k | uvos: I'll investigate this ofono issue... strange, and nothing related to sphone | 21:38 |
| uvos | i see and understand that commit | 21:38 |
| freemangordon | it has nothing to do with hildon | 21:38 |
| uvos | but it dosent matter | 21:38 |
| freemangordon | sure it does | 21:38 |
| uvos | no | 21:38 |
| freemangordon | see how button-press-event is handles | 21:38 |
| freemangordon | *handled | 21:38 |
| freemangordon | this is original gtk code | 21:39 |
| rafael2k | good ol' AT commands work like a charm | 21:39 |
| rafael2k | :/ | 21:39 |
| freemangordon | the same condition was missing in motion-event code | 21:39 |
| freemangordon | it seems GtkRange uses its own event_window and thus coordinates must be relative to it | 21:40 |
| freemangordon | not to event->window | 21:40 |
| calx | sicelo or whomever, am I supposed to create a disk label of type GPT or MBR, or just format straight to ext4 without a disk label? | 21:42 |
| freemangordon | anyway, if you think there is a bug in HPA, please feel free to open an issue, providing a test case. | 21:42 |
| uvos | freemangordon: right but with the hpa the event is relative to a different window so any widget that expects the event to get like in any other container | 21:42 |
| uvos | now that may be technicly broken | 21:43 |
| uvos | ok | 21:43 |
| uvos | but the fact that it works suggests its gona be used that way in other places too | 21:43 |
| uvos | anyhow its not important | 21:43 |
| uvos | its not like people are implementing gtk2 applications anymore... | 21:43 |
| freemangordon | that one too :) | 21:43 |
| freemangordon | gtk3 supports something like HAP natively, right? | 21:44 |
| uvos | yeah | 21:44 |
| freemangordon | *HPA | 21:44 |
| uvos | any scrolling widget is finger scrollable | 21:44 |
| uvos | hpa is obsolete | 21:44 |
| freemangordon | so we'll drop that anyway when it comes to it | 21:44 |
| calx | This wiki https://leste.maemo.org/PinePhone says "Format the SD card as ext4 using any of your preferred tools." How is a person supposed to pick which way to do it, lol! | 21:44 |
| uvos | yeah | 21:44 |
| freemangordon | uvos: and anyway that frustrating bug is now fixewd | 21:44 |
| uvos | right | 21:44 |
| uvos | thanks | 21:44 |
| freemangordon | np | 21:45 |
| freemangordon | uvos: just one note re HPA and GtkRange: GtkRange receives motion events straight from gdk, hildon has nothing to do with which windows those events come from | 21:47 |
| sicelo | calx: maybe that's outdated. i don't have pp, but there's an image here, http://maedevu.maemo.org/images/pinephone/20210822/ - clearly that one is a matter of using dd, etcher, or whatever similar tool one prefers | 21:47 |
| sicelo | perhaps you can do this, and update the wiki accordingly | 21:47 |
| uvos | freemangordon: yeah i know | 21:47 |
| freemangordon | HPA motion-event callback is not called in case of GtkRange | 21:47 |
| uvos | freemangordon: but the presence of the hpa changes behavior somehow | 21:47 |
| freemangordon | so I would say this is a bug in gtk | 21:48 |
| uvos | freemangordon: very possible yeah | 21:48 |
| uvos | rafael2k: org.ofono.VoiceCallManager.dial | 21:48 |
| uvos | rafael2k: not org.ofono.VoiceCall.dial | 21:48 |
| uvos | sry | 21:48 |
| freemangordon | are you sure GtkRange behaves correctly outside of HPA? | 21:48 |
| freemangordon | in terms of motion-event that is | 21:48 |
| uvos | freemangordon: yes | 21:49 |
| freemangordon | ok | 21:49 |
| uvos | i tried several containers | 21:49 |
| uvos | rafael2k: call is here: https://github.com/maemo-leste/sphone/blob/e5ad31827650099a3cd85ea9a2400cb76633dae9/src/modules/comm-ofono.c#L632 | 21:49 |
| uvos | rafael2k: and the dbus names are here: https://github.com/maemo-leste/sphone/blob/master/src/modules/ofono-dbus-names.h | 21:50 |
| Wizzup | rafael2k: we should bfix our kernel, what is missing? | 21:50 |
| calx | sicelo, ok, I got it now. gonna go try. will be back | 21:52 |
| uvos | freemangordon: also please look at https://github.com/maemo-leste/hildon-status-menu/pull/3 and https://github.com/maemo-leste/libmatchbox2/pull/8 at some point | 21:53 |
| freemangordon | ugh, I was under the impression https://github.com/maemo-leste/hildon-status-menu/pull/3 is already merged | 21:54 |
| Wizzup | calx: btw you can also look at arm-sdk if you don't want the full userspace | 21:54 |
| freemangordon | uvos: please ping me again about those in 3-4 days | 21:55 |
| uvos | freemangordon: ok | 21:55 |
| freemangordon | Wizzup: hi! do you still have questions? or you made some progress with tmlind? | 21:55 |
| rafael2k | uvos: just a sec | 21:57 |
| freemangordon | uvos: in regards to the other PR, honestly, I have no idea what it is about, but I'll try to learn a bit :) | 21:57 |
| uvos | freemangordon: btw https://github.com/maemo-leste/hildon-status-menu/pull/3 has the side effect that hildon-status-menu becomes GPL2+ | 21:58 |
| uvos | instead of LGPL2+ | 21:58 |
| uvos | i assume thats not a problem | 21:58 |
| rafael2k | uvos: kernel is fine, I copied from mobian | 21:58 |
| uvos | (due to the code i took from xface) | 21:58 |
| freemangordon | me too, but anyways I am not the copyright holder :) | 21:58 |
| rafael2k | telephony works | 21:58 |
| rafael2k | (may be not ofono) | 21:59 |
| uvos | freemangordon: who owns copyright dosent matter since combining gpl and lgpl is explicitly allowed | 21:59 |
| uvos | its just a one way street | 21:59 |
| freemangordon | ok then | 21:59 |
| Wizzup | freemangordon: on thermal? | 22:07 |
| rafael2k | Wizzup: we just need an up to date kernel to maemo | 22:08 |
| rafael2k | Wizzup: mobian kernel I'm using right now is work fine (with maemo) | 22:09 |
| rafael2k | I'm just having a issue with ofono, which must be some detail... | 22:09 |
| freemangordon | Wizzup: yes | 22:09 |
| rafael2k | gprs works, sms works... just calls not yet | 22:10 |
| Wizzup | rafael2k: can you file an issue? | 22:12 |
| Wizzup | freemangordon: hmm, well, I think tony suggested to increase timeout which might help with OFF mode, but it doesn't help with oopses | 22:12 |
| freemangordon | right, but maybe oopses are not caused by thermal | 22:14 |
| Wizzup | well disabling it makes them go away | 22:14 |
| rafael2k | Wizzup: yes. lemme know where! | 22:14 |
| rafael2k | ; ) | 22:14 |
| freemangordon | Wizzup: yeah | 22:14 |
| Wizzup | rafael2k: https://github.com/maemo-leste/bugtracker/issues/new | 22:14 |
| freemangordon | Wizzup: well, maybe we shall disable thermal initially, to have 5.15 running | 22:15 |
| freemangordon | and then investigate | 22:15 |
| freemangordon | not sure | 22:15 |
| rafael2k | ok! | 22:15 |
| Wizzup | freemangordon: yeah, I am doing that in our tree | 22:15 |
| freemangordon | great | 22:15 |
| Wizzup | I just need to do commit the dts disables | 22:15 |
| freemangordon | but, what about other devices? | 22:15 |
| freemangordon | ah | 22:15 |
| freemangordon | dts | 22:15 |
| freemangordon | ok | 22:15 |
| Wizzup | freemangordon: we have no other devices that want OMAP3_THERMAL | 22:16 |
| freemangordon | I'll play a bit with it (thermal/TSHUT gpio) once we have a kernal | 22:16 |
| freemangordon | *kernel | 22:16 |
| freemangordon | and once no-CMA scanout buffers are supported | 22:17 |
| Wizzup | yes, that would be nice | 22:17 |
| Wizzup | tmlind: do you want me to test increasing the timeout to 10000? | 22:17 |
| freemangordon | but now I am going to finish my gimlet and have some rest :) | 22:18 |
| freemangordon | night! | 22:18 |
| Wizzup | enjoy :) | 22:18 |
| lel | rafael2k opened an issue: https://github.com/maemo-leste/bugtracker/issues/597 (Maemo current kernel for Pinephone has no telephony support) | 22:20 |
| rafael2k | https://github.com/maemo-leste/bugtracker/issues/597 | 22:20 |
| rafael2k | the issue is with ofono in maemo... | 22:21 |
| rafael2k | voicecalls for the EG25 support seems not there in the shipped version | 22:21 |
| Wizzup | so do we need patched ofono or newer ofono? | 22:23 |
| sicelo | mobian uses modemmanager instead of ofono. anyway, maybe compare what plasma mobile's ofono had ... (they have also switched to MM recently) | 22:23 |
| Wizzup | it's possible most systems do not shit with mainline ofono | 22:23 |
| sicelo | telephony was working fine for plamo with ofono | 22:24 |
| uvos | implementing a mm backend for sphone is really trivial btw | 22:25 |
| uvos | i just lack a device to test it | 22:25 |
| uvos | (ofc we have other stuff that uses ofono) | 22:25 |
| rafael2k | I'll try another distro with ofono to compare | 22:26 |
| Wizzup | maybe just look at the version? | 22:27 |
| rafael2k | easier | 22:27 |
| rafael2k | ; ) | 22:27 |
| sicelo | yeah, you don't need a whole distro :-p | 22:27 |
| sicelo | plus, they're dwindling | 22:27 |
| rafael2k | lemme see what is inside the mobian I borroed the kernel | 22:28 |
| sicelo | that one won't help you. they were using MM since day 1 | 22:28 |
| rafael2k | right | 22:29 |
| sicelo | look at something that used Plasma Mobile, because that was ofono until very recently | 22:29 |
| rafael2k | ok | 22:29 |
| uvos | i dont think anyone uses ofono anymore execpt sfos and us | 22:29 |
| sicelo | just like x11 ... almost no one else uses it (on mobile) anymore. only sxmo did, but they're going wayland too | 22:32 |
| rafael2k | anyone, LTE connection works fine | 22:32 |
| rafael2k | *anyway | 22:32 |
| Wizzup | uvos: sfos is bigger than all others combined I think | 22:32 |
| Wizzup | (just noting) | 22:33 |
| rafael2k | need to fix X11 too.. I'm still with that nasty bug on rendering, but I just use it without accell for some time already... I forget about it | 22:33 |
| uvos | Wizzup: sure but they are soemthing different than the others | 22:33 |
| uvos | they are not really part of mainline linux efforts | 22:33 |
| Wizzup | rafael2k: there are some things to improve it a bit but there are still rendering problems | 22:33 |
| uvos | they are more like android really | 22:33 |
| rafael2k | <- downloading plasma mobile... | 22:33 |
| uvos | sicelo: sure bit with x11 we have a large amount of legacy code we would have to replace | 22:34 |
| uvos | sicelo: with ofono its very little | 22:34 |
| uvos | sicelo: just some icd2 stuff the status icon and sphone really | 22:34 |
| uvos | sicelo: as far as stuff thats currently implemented | 22:34 |
| uvos | sicelo: < 3k lines probubly | 22:34 |
| Wizzup | telepathy-ring | 22:37 |
| uvos | you know what i think about telepathy :P | 22:37 |
| uvos | but yeah | 22:37 |
| uvos | telepathy-ring | 22:37 |
| Wizzup | yes you want to roll your own :p | 22:37 |
| rafael2k | hummm, can not find ofono in plasma image | 22:37 |
| rafael2k | :/ | 22:37 |
| sicelo | Wizzup: actually that's an interesting one - i wonder what plamo is doing with telepathy-* now that they've switched. never looked | 22:38 |
| sicelo | rafael2k: afaik there's not really a plasma image ... they're not a distro. you need to use an image of some distro that provided plamo, e.g. pmos (if they still have older images), or maybe manjaro did? anyway, i guess you need to look at code more than running a specific distro. hopefully the code differences should be quickly apparent | 22:40 |
| uvos | https://pkgs.postmarketos.org/package/master/postmarketos/armv7/ofono | 22:40 |
| uvos | pmos has ofono | 22:40 |
| rafael2k | I'll try a new ofono version | 22:40 |
| uvos | i dont think any ui uses it | 22:40 |
| uvos | but it still has the package | 22:40 |
| rafael2k | will compile a package from sid debian dir | 22:41 |
| uvos | you could also try and install the droid4 ofono | 22:41 |
| uvos | its newer i think | 22:42 |
| sicelo | rafael2k: ofono upstream? | 22:42 |
| uvos | and really nothing about it is mapphone specific | 22:42 |
| sicelo | upstream won't help you :-) | 22:42 |
| rafael2k | sicelo: sid package | 22:42 |
| sicelo | i doubt that'll help you either ;-) | 22:42 |
| rafael2k | with some tweaks for devuan / maemo | 22:42 |
| uvos | rafael2k: try installing the ofono pacakge from the droid4 leste repo first | 22:42 |
| sicelo | anyway, try it | 22:42 |
| rafael2k | uvos: can be, sure | 22:43 |
| uvos | its just a diffrerent ofono version | 22:43 |
| rafael2k | where can I grab it? | 22:43 |
| uvos | that also has moomdm driver | 22:43 |
| uvos | you can just browse the repo | 22:43 |
| uvos | and grab it | 22:43 |
| sicelo | someone else that uses ofono with pp is nemomobile. may also be helpful to see which ofono they use. i can't recall what features they have working thoug | 22:43 |
| uvos | ie https://maedevu.maemo.org/leste | 22:44 |
| rafael2k | tks | 22:44 |
| uvos | https://maedevu.maemo.org/leste/pool/droid4/o/ofono/ | 22:45 |
| uvos | lucky you we build droid4 for arm64 | 22:45 |
| uvos | (this makes no sense :P) | 22:45 |
| rafael2k | ehehehe | 22:46 |
| rafael2k | droid4 uses armhf right? | 22:46 |
| uvos | yes | 22:46 |
| rafael2k | same error | 22:48 |
| uvos | ok | 22:48 |
| rafael2k | dbus.exceptions.DBusException: org.ofono.Error.NotImplemented: Implementation not provided | 22:49 |
| rafael2k | all the rest works, IP, sms, ussd, and so on | 22:49 |
| uvos | 1.32.5 is quite new | 22:49 |
| uvos | so i doubt a never version will help | 22:49 |
| uvos | so you need to go hunting for patches | 22:50 |
| uvos | btw the news post for plamo where the announce the move to mm | 22:50 |
| uvos | explictly calls out bad support for the pp as a reason to switch | 22:50 |
| rafael2k | I saw the post | 22:50 |
| uvos | so maybe it never worked (well) | 22:51 |
| rafael2k | but it is just a f@#$#@ink wiring up | 22:51 |
| rafael2k | I can see in the log it is almost there | 22:51 |
| rafael2k | I get the signal strengh, channel, all the info | 22:51 |
| rafael2k | just not the call control | 22:51 |
| sicelo | Calls were working on plasma + ofono, else plamo wouldn't have been as popular as it got | 22:56 |
| rafael2k | I'm looking the code | 23:00 |
| rafael2k | may be using the atmodem driver... | 23:00 |
| Wizzup | might need udev rules | 23:00 |
| Wizzup | then | 23:00 |
| rafael2k | right now it defaults to the qmimodem | 23:01 |
| rafael2k | (driver) | 23:01 |
| Wizzup | that sounds good? does ofono -ddd or w/e also show that? | 23:02 |
| rafael2k | https://github.com/sailfishos/ofono/ | 23:06 |
| rafael2k | this is interesting ^ | 23:07 |
| rafael2k | I dunno | 23:07 |
| rafael2k | I read a lot about this "rilmodem" | 23:07 |
| sicelo | Isn't ril* something to do with android? | 23:10 |
| calx | Wizzup, thanks for mentioning arm-sdk. I'll try to remember to look into it the next time I've got a few free cycles, or however the cool kids say it | 23:11 |
| sicelo | Anyway, gn! | 23:11 |
| uvos | sicelo: yes ril is the andorid hal for modems | 23:12 |
| uvos | radio interface layer or so | 23:12 |
| calx | sicelo, I've got it up! thanks for your help! Aptitude's up and working and wicd-curses shows connections but doesn't connect, but hey, one out of two ain't bad! Now I just gotta see what mess I can uninstall without breaking everything; probably not much. | 23:13 |
| uvos | we have our won network manager btw | 23:14 |
| uvos | icd2 | 23:14 |
| uvos | *own | 23:14 |
| uvos | using wicd in parrallel with icd2 icd2 is not going to be very pretty | 23:15 |
| calx | I much prefer my network manager to not use X11 | 23:16 |
| uvos | icd2 dosent use x11 | 23:16 |
| uvos | the ui dose sure | 23:16 |
| uvos | but the ui is seperate | 23:16 |
| uvos | ofc | 23:16 |
| calx | Oh, nah? I'll have to read up on it. Thanks for mentioning! :-) | 23:16 |
| calx | gotta go, thanks everybody! | 23:17 |
| rafael2k | right, android shit | 23:18 |
| rafael2k | we need to use the qmi interface | 23:18 |
| rafael2k | there is also a kernel module... it might be there the problem too... | 23:37 |
| Wizzup | did you inspect ofono in debug mode | 23:52 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
