| arno11 | Wizzup: is there any particular reason to keep hifi ? then how to properly deal with mic ? | 07:19 |
|---|---|---|
| arno11 | hm, backend management is a bit confusing: able to receive a sip call through ring backend (apparently) with sound in one way | 08:00 |
| arno11 | can't get sound anymore (with both backends) | 08:01 |
| Wizzup | arno11: hifi just means regular mic/speakers, so I think hifi is correct here | 08:17 |
| sicelo | arno11: Wizzup is right. there's no reason to not have mic with hifi | 08:28 |
| Wizzup | It's a confusing term perhaps | 08:28 |
| Wizzup | it just means 'good ol pc audio' | 08:28 |
| Wizzup | like, for video calls, other sip calls, or whatever | 08:28 |
| arno11 | Wizzup: sicelo: sorry my question was unclear: i meant, if we use hifi profile, does it mean we keep mic activated all the time or ? | 08:39 |
| sicelo | maybe think of it this way - on N900 or your pc, what do you need to do before you can record from mic? ;-) | 08:41 |
| sicelo | the answer is - nothing, because (at least in normal cases), you're on HiFi already, and the mic is available/ready for use in that profile too. | 08:42 |
| arno11 | ah, so we are supposed to keep it activated all the time, ok | 08:43 |
| sicelo | of course you can specifically mute it (for privacy reasons, for example), otherwise the profile will normally activate it | 08:43 |
| arno11 | i need to modify n900 hifi profile then | 08:43 |
| arno11 | sicelo: not related but do you think ofono could be the culprit for freeze on startup ? | 08:58 |
| Wizzup | arno11: no mic is not active all the time, just when alsa uses it | 08:58 |
| Wizzup | but yes it should be ready for usde | 08:59 |
| arno11 | ok | 08:59 |
| Wizzup | normally only when userspace uses alsa component it is powered on | 08:59 |
| Wizzup | iuc | 08:59 |
| Wizzup | which is why we had trouble with the modem | 08:59 |
| arno11 | ah ok | 08:59 |
| arno11 | Wizzup: btw i don't remember if you got some freeze on boot (pin entry) on your n900 (before swap troubles ofc) | 09:07 |
| arno11 | sicelo also got it iirc, but it seems to work fine with no sim card inside | 09:08 |
| Wizzup | did you not get there then? | 09:09 |
| Wizzup | these* | 09:09 |
| arno11 | yep | 09:10 |
| sicelo | arno11: i think ofono is well-behaved. you can experiment with `sudo rc-update del ofono default`. | 09:10 |
| sicelo | that'll require you to start ofono manually | 09:10 |
| arno11 | ah ok ty | 09:11 |
| Wizzup | I am not so sure sicelo | 09:11 |
| Wizzup | other services require it so it will get pulled | 09:11 |
| Wizzup | I will try again later today, maybe with serial, and check | 09:12 |
| arno11 | ok | 09:12 |
| arno11 | the issue is a bit random in fact, sometimes it boots fine, and sometimes i need to remove the battery 4-5 times to be able to boot (with sim) | 09:15 |
| arno11 | but maybe that's just my device (and a problem with sim slot maybe) | 09:17 |
| arno11 | or the sim card itself | 09:17 |
| sicelo | iirc ofono is started by openrc on leste, so nothing can activate it. that would have been the case if we used dbus activation, yes | 09:17 |
| sicelo | arno11: i do have the problem, and it's 100% reproducible for me. | 09:18 |
| arno11 | ok | 09:18 |
| sicelo | something You could try is to remove the Pin requirement from the SIM | 09:18 |
| arno11 | what do you mean exactly ? | 09:20 |
| sicelo | the pin entry dialog shows up because your SIM requires Pin. if you disable that on SIM, pin-entry won't come up | 09:20 |
| arno11 | ah scratch that | 09:21 |
| arno11 | yep ok | 09:22 |
| sicelo | in fact that's probably easiest/quickest way to narrow down the cause | 09:27 |
| arno11 | yes indeed | 09:29 |
| arno11 | sicelo: btw is it possible to directly disable it form ofono scripts ? | 09:35 |
| arno11 | *from | 09:35 |
| sicelo | disable pin? yes | 09:36 |
| arno11 | lock-pin ? | 09:38 |
| arno11 | or change-pin maybe ? | 09:40 |
| sicelo | i forgot what it is with ofono scripts, but a direct dbus call would look like: | 09:43 |
| sicelo | busctl call org.ofono /n900_2 org.ofono.SimManager UnlockPin ss pin 1234 (if your pin was 1234, amd n900 modem path was /n900_2) | 09:44 |
| arno11 | ok ty | 09:45 |
| sicelo | ah, there' `unlock-pin` ofono script ;-) | 09:46 |
| arno11 | yes indeed :) | 09:46 |
| arno11 | seems to work | 09:49 |
| arno11 | i'll try to reboot and see | 09:50 |
| arno11 | still got 2 freezes on boot but when it works, boot time is a way faster with no pin | 10:15 |
| uvos__ | did we enable openrc parallelized starting of services? | 10:16 |
| uvos__ | i have that on my d4 but im not sure if i did that | 10:16 |
| uvos__ | if so thats probubly bad for n900 | 10:17 |
| uvos__ | since its constantly close to oom | 10:17 |
| arno11 | interesting | 10:17 |
| sicelo | rc_parallel is disabled | 10:26 |
| arno11 | sicelo: what is clearer now is the moment when it freezes: when H-D is appearing, time + battery + network + desktop icons + widgets are visible after few sec then it freezes few sec later | 11:01 |
| arno11 | btw n900 is not really constantly close to oom, leste even works with no swap on it, just multitasking (let's say 3-4 apps opened) is not usable | 11:31 |
| arno11 | and the device is not faster with no swap (but with all tweaks) meaning imo that swapping is not really slowing down all stuff | 11:34 |
| arno11 | as KREYREN confirmed, the ui is now really responsive with lastest tweaks, even not sure d4 responsiveness is superior with original transitions file. | 11:39 |
| sicelo | d4 is obviously going to be superior :-) | 11:39 |
| arno11 | yep | 11:40 |
| sicelo | but yeah, FUD isn't useful either | 11:40 |
| uvos__ | oom might not be quite right, since there is swap, but it its under constant memory pressure | 12:03 |
| uvos__ | thats not fud its just a fact | 12:03 |
| uvos__ | thanks for confirming that i just enabled the parallelizeing locally | 12:05 |
| arno11 | wow it tooks me almost 40 min to be able to boot... | 13:26 |
| arno11 | i had to finally use fremantle to free up memory a bit in leste, removing mafw stuff from xsession | 13:28 |
| arno11 | and then, able to boot | 13:28 |
| arno11 | so even if memory is ok after boot, seems really near oom during boot as uvos said | 13:29 |
| uvos__ | the way the xsession scripts work is not that great for n900 i gues | 13:31 |
| uvos__ | we launch lots of proccesies in parralell | 13:31 |
| uvos__ | instead maybe should wait for things to stabalise before launching the next thing on n900 | 13:32 |
| arno11 | yes and that's a bit confusing | 13:32 |
| uvos__ | but this is hard to do with xsession | 13:32 |
| uvos__ | we would need some thing to manage user session deamons like systemd can | 13:32 |
| uvos__ | so either that or something custom (very common for desktop des to have something cusom here) | 13:33 |
| uvos__ | anyhow not so tivial changes | 13:33 |
| arno11 | the weird stuff is boot issue is totally random | 13:35 |
| arno11 | sometimes ok, sometimes quite impossible to boot | 13:35 |
| arno11 | anyway, true that we can't add more stuff on boot atm | 13:37 |
| arno11 | btw how to explain that memory is just a problem on boot and not from userspace ? running 20 apps at the same time causes no troubles | 13:58 |
| arno11 | maybe something is wrong with swap on boot? (like no swap) | 13:59 |
| uvos__ | arno11: well swap may activate to late yes, but also having lots of swap used is not a problem per say but having lots of hot pages in swap is because then you are thrashing | 14:09 |
| uvos__ | during boot lots of different stuff is happening so manny pages are hot | 14:10 |
| uvos__ | possibly to manny for the kernel not to end up compleatly stalled | 14:10 |
| uvos__ | once booted you opening alot of apps dosent matter as mutch as long as those apps arnt doing anything and thus need pages swaped in constantly | 14:11 |
| arno11 | ok thx for clarifying | 14:35 |
| arno11 | hm conversations use 35MB in background now, a lot more than previously | 15:25 |
| arno11 | d4dsc: ^^^ any idea why ? | 15:27 |
| arno11 | *uses | 15:27 |
| arno11 | scratch that, back to normal :) | 15:31 |
| dsc_ | arno11: what is normal? :D | 15:32 |
| dsc_ | I'd say 35MB is not so much | 15:32 |
| arno11 | yeah that's the maximum i see, it is usually around 20MB | 15:36 |
| dsc_ | Qt memory alloc greediness depends on several things, its hard to pinpoint when it does what | 15:36 |
| dsc_ | for example, on d4 idle is around 50MB (never 20-30MB) | 15:37 |
| arno11 | ok | 15:59 |
| arno11 | i just wonder how stuff like conversations can use so much memory just for msgs lol | 16:01 |
| bencoh | because of how the underlying toolkit works I'd say | 16:01 |
| bencoh | (toolkit and used widgets) | 16:01 |
| arno11 | ok | 16:02 |
| uvos__ | modern toolkits use alot of memory everywhere a memory/speed tradeoff can be made as speed is gennerally more precious than space on modern devices, that comes in the form of scrolling buffers, holding huge acellerated contexts, holding caches for a veriaty of resources and surfaces. Additionally theres stuff like qtquick that means executeing scripts which in turn means spinning up interpreters, modern theming engines are also scripts whith thair own | 16:07 |
| uvos__ | interpreters. Toolkits must expect that the dpi of any suface may change at any time (eg because it was moved to a diffferent monitor) this also means holding resources for those and it goes on like this | 16:07 |
| uvos__ | really if we want to port leste to a modern toolkit from gtk2 i strongly doubt that continuing support for n900 is possible. | 16:08 |
| uvos__ | of we dont have the resources to move away from gtk2 anyhow atm, so n900 is safe for the forseable future | 16:09 |
| arno11 | yep all of this makes sense | 16:09 |
| uvos__ | to share some expirance from the android world: android 2.x's native toolkit worked very much like gtk2 as in it simply displayed fixed sized pixmaps using the cpu for rendering. | 16:12 |
| uvos__ | in android 4.0 this was changed to ogl accelerated rendering of vector graphics simmilar to how modern linux toolkits like qtquick also work | 16:13 |
| uvos__ | this ment a over night doubleing of the ram requirements of android despite a large amount of optimization effort | 16:14 |
| Wizzup | I don't think gtk3 is ogl accelerated but their theming is more complicated | 16:14 |
| uvos__ | gtk3 is old | 16:14 |
| uvos__ | really old | 16:14 |
| * Wizzup taps out | 16:14 | |
| uvos__ | qwidgets is also mostly unaccelerated | 16:14 |
| sicelo | we'll have to switch N900 to i3 at some point ;-) | 16:14 |
| uvos__ | anyhwo android 4.0 indeed is also the cutoff where the droid1 stopped being usefull (althoug you could bearly runn it) | 16:15 |
| dsc_ | conversations doesnt do qtquick on startup, so only widgets | 16:15 |
| Wizzup | arno11: rtcom-messaging-ui uses more than 35MB on fremantle think | 16:16 |
| Wizzup | I think* | 16:16 |
| dsc_ | however, conversations links against many shared libs, see `ldd`. I think memory usage is due to that also | 16:16 |
| arno11 | Wizzup: oh really ? | 16:17 |
| Wizzup | mhm | 16:17 |
| Wizzup | I don't think leste uses a lot more ram than fremantle | 16:17 |
| arno11 | dsc_: ok | 16:17 |
| uvos__ | well you have to count sphones 20 or so mb too | 16:17 |
| uvos__ | oh messaging ui | 16:18 |
| arno11 | Wizzup: yes probably | 16:18 |
| uvos__ | nvm | 16:18 |
| Wizzup | yes, rtcom-call-ui is the equivalent | 16:18 |
| arno11 | atm the real problem is only on boot, specially after H-D starts to load | 16:20 |
| Wizzup | I think some serial or profiling will help | 16:21 |
| arno11 | otherwise, that's fine in userspace, even probably better than fremantle actually | 16:21 |
| arno11 | Wizzup: yes maybe | 16:21 |
| arno11 | Wizzup: btw is it safe to block conversations from xsession and start it from userspace instead ? (just to free up some mem on boot and see if it helps) | 16:24 |
| sicelo | yes @serial | 16:24 |
| sicelo | otherwise we're groping in the dark | 16:24 |
| dsc_ | yes you can block from xsession | 16:32 |
| dsc_ | or just `rm /usr/bin/conversations` like I do | 16:32 |
| dsc_ | (I generally run debug builds) | 16:32 |
| arno11 | ok thx | 16:34 |
| arno11 | let's try | 16:37 |
| arno11 | to reboot | 16:37 |
| arno11 | ok, it does the trick | 16:47 |
| arno11 | 2 min to boot instead of 4 | 16:48 |
| arno11 | just around 20 sec unresponsive once everything is loaded | 16:48 |
| arno11 | and then everything is ok | 16:49 |
| arno11 | so definitely (near) oom on boot | 16:49 |
| arno11 | i removed mafw and conversations from xsession and start conversations --background from userspace | 16:51 |
| arno11 | will reboot again to doublecheck | 16:55 |
| Wizzup | arno11: it is safe, but remember you might miss smses on boot | 16:55 |
| uvos__ | why whould you miss sms? if there is no one to read the sms they should stay in the buffer no? | 17:12 |
| uvos__ | otherwise you may miss sms anyhow since ofono may start before conversations is ready | 17:12 |
| sicelo | yes, the latter ... ofono will receive the sms immediately and it'll get lost | 17:13 |
| uvos__ | hmm thats bad | 17:13 |
| sicelo | yeah, i've sometimes wondered why ofono handles sms in this way. | 17:14 |
| sicelo | ModemManager stores them itself afaik | 17:14 |
| Wizzup | mission-control will still launch conversations for the incoming messages/channel fwiw | 17:14 |
| uvos__ | none of this helps during boot | 17:14 |
| uvos__ | rn at least using sphone for sms i know ofono starts after sphone | 17:14 |
| uvos__ | but this is just a race | 17:14 |
| uvos__ | *sphone is ready | 17:14 |
| Wizzup | the same is true for tp-ring | 17:14 |
| arno11 | Wizzup: 2 reboots with no issue, that's fine for me with this workaround. now i can continue cmtspeech and ucm stuff :) | 17:15 |
| uvos__ | sure but its just a race it currently winns | 17:15 |
| Wizzup | luckily we have full control over this | 17:15 |
| uvos__ | so we | 17:15 |
| Wizzup | arno11: sounds good | 17:15 |
| uvos__ | who sais that conversations isent stalled on startup | 17:15 |
| uvos__ | due to memory pressure for instance | 17:15 |
| uvos__ | (before its ready to store msgs) | 17:16 |
| Wizzup | it gets startd on startup, so I don't know who said it but it's wrong | 17:16 |
| Wizzup | arno was talking about purpusefully not starting it on boot | 17:16 |
| uvos__ | sure but curretly | 17:16 |
| uvos__ | the n900 stalls for a long time starting converstaions | 17:16 |
| uvos__ | if ofonos startup is not stalled during this time | 17:16 |
| uvos__ | you end up with ofono comeing up before | 17:17 |
| uvos__ | even if it isent happening right now it can happen | 17:17 |
| Wizzup | ofono can be up if the mdeom is not online'd by cellulard | 17:17 |
| Wizzup | which can be done upon h-d ready signal | 17:17 |
| Wizzup | this is not an unsolvable problem | 17:17 |
| uvos__ | and converstaions is guarenteed to be finished before this signal? | 17:17 |
| Wizzup | sure it can be | 17:17 |
| uvos__ | ok but atm no | 17:18 |
| uvos__ | but ok | 17:18 |
| uvos__ | i should finish the modemmanager code for sphone | 17:18 |
| sicelo | ah right - forgot that the modem needs to be online first (and yes it won't online itself). my bad | 17:19 |
| Wizzup | yeah it's not a problem | 17:19 |
| uvos__ | i mean it still kinda is | 17:19 |
| uvos__ | what if sphone/conversations crashes | 17:20 |
| uvos__ | during the restart you could loose sms | 17:20 |
| Wizzup | conversations restarts | 17:20 |
| uvos__ | so? | 17:20 |
| Wizzup | and tp-ring keeps it like I said | 17:20 |
| uvos__ | doseent matter | 17:20 |
| uvos__ | if the first rung after ofono crashes | 17:20 |
| Wizzup | I know you're trying to find flaws in it, but it works, has since n900/fremantle :) | 17:20 |
| uvos__ | during restart it could loose messages | 17:20 |
| uvos__ | no its plain bad | 17:20 |
| * Wizzup sighs and goes to do something else | 17:20 | |
| sicelo | uvos__: solution? | 17:22 |
| uvos__ | sicelo: not sure | 17:23 |
| sicelo | if whoever fetches message from ofono crashes, then yeah, it seems logically unavoidable that the message will get lost forever. | 17:24 |
| sicelo | i guess solution is if ofono stores message until someone has acknowledged collecting it. | 17:24 |
| sicelo | but yeah, this isn't how ofono works currently | 17:25 |
| uvos__ | i gues its not a huge problem if whomever collects messages from ofono is somehing small and simple | 17:25 |
| uvos__ | but its a bit of a defect | 17:25 |
| sicelo | https://marc.info/?l=linux-omap&m=172215643028564&w=2 | 21:50 |
| sicelo | Wizzup: any idea here? I am not sure I understand :-) | 21:51 |
| sicelo | i'm quite sure there's nothing wrong with driver (it's the same driver on Droid 4 btw) ... and mount matrix is documented at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/iio/mount-matrix.txt#n31 | 21:51 |
| sicelo | i'll respond, but just want to be sure i'm not mistaken in my understanding perhaps | 21:52 |
| kiva | uvos: I readed logs about weeks ago and you said: "i dont think anyone uses the pinephone in a major way besides testing even"...well I use! And for everything last 6 months...even banking and streaming tv-news from local broadcasting company web-site. Ok..I use it with Pinephone Keyboard, without it Leste quite hard to use (virtual keyboard is not | 23:45 |
| kiva | show to OS as keyboard device)...with it Leste is the best OS for it. | 23:45 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!