| uvos | is dapm simply broken? | 00:06 |
|---|---|---|
| Wizzup | I doubt that it is broken in 6.6 | 00:07 |
| Wizzup | todays log has my and fmgs discussion on it | 00:07 |
| Wizzup | he's using c2c and I think it's never being toggled off | 00:07 |
| uvos | that would break dapm for that chain yes | 00:08 |
| uvos | all the devices in that chain would then never be powerd down | 00:08 |
| Wizzup | I mean, c2c clearly has to work with dapm somehow | 00:08 |
| Wizzup | we just need to figure out how | 00:08 |
| uvos | sure | 00:09 |
| uvos | i mean i dont have time right now | 00:09 |
| uvos | but its easy to check | 00:09 |
| uvos | omapconf shows you what dai are active (on the omap side ofc) and debugfs shows you the snd-soc widgets and the dapm state for those | 00:10 |
| uvos | omap dai blocks ret however so i dont think its that since fmg had some ret | 00:11 |
| Wizzup | I think we checked dapm and saw it's active even outside of a call | 00:18 |
| Wizzup | and it's clearly related because pm was fine before this change on 6.6 | 00:18 |
| Wizzup | I think we just need to figure out how to tell alsa/kernel to not have it on - through some widget or otherwise | 00:18 |
| Wizzup | or maybe our routing is off | 00:18 |
| uvos | i maen as a hack you could break the dapm chain by insterting a fake switch | 00:20 |
| uvos | but i dont think this is the right way | 00:20 |
| Wizzup | so I think having a switch to enable all the call bits would be a great way | 00:21 |
| Wizzup | we could easily switch this with UCM too | 00:21 |
| Wizzup | "Call mode" "On" / "Off" | 00:21 |
| uvos | its not the right way to do it from alsas perpsective | 00:21 |
| Wizzup | so what is the right way to do it for streams that bypass cpu/alsa entirely? | 00:22 |
| Wizzup | https://kernel.org/doc/html/latest/sound/soc/codec-to-codec.html | 00:22 |
| uvos | dapm turns on the nodes on the route when it thinks the source is active and the route is unbroken | 00:22 |
| uvos | the source being a dai | 00:22 |
| uvos | i gues the kernel thinks the dai of the modem is active, we need to figure out how to make it know its not | 00:23 |
| Wizzup | switch seems like a great way imo, since we can toggle it from userspace with ucm without having to parse AT in kernel | 00:24 |
| Wizzup | well, -some- AT at least | 00:24 |
| uvos | doing that is def wrong form a framework perspective | 00:24 |
| uvos | nomater how nice it looks from userspace | 00:25 |
| uvos | but anyhow | 00:25 |
| Wizzup | I suppose this is relevant: | 00:26 |
| Wizzup | Make sure to name your corresponding cpu and codec playback and capture dai names ending with “Playback” and “Capture” respectively as dapm core will link and power those dais based on the name. | 00:26 |
| uvos | also i dont think you can shutdown cpcaps dai this way, at least thats before you could insert a switch in the chain is after the cpcap dai | 00:26 |
| uvos | looking at alsa/snd-soc stuff allways makes me think: this is really compilcated and this lacks features i need :P | 00:29 |
| uvos | also: i dont get how this bit works | 00:30 |
| uvos | skill issue i gues | 00:30 |
| Wizzup | it's not just you :) | 00:30 |
| Wizzup | freemangordon: actually I don't see a pm regression | 10:23 |
| Wizzup | my phone still said 2 days before I went to sleep | 10:23 |
| Wizzup | now it's at 83% | 10:23 |
| Wizzup | so maybe you just solved it :) | 10:29 |
| Wizzup | arno11: ok I see the problem @ version / headrs | 11:50 |
| uvos | Wizzup: is ci fixed? | 11:52 |
| Wizzup | uvos: give it a try, I am still trying to figure out arm64 but I restarted jenkins and it might just work | 11:53 |
| uvos | wonlt the build fail reglardless if one architecture dosent work | 11:54 |
| uvos | ie the repo part wont be triggered? | 11:54 |
| uvos | anyhow i kicked sphone | 11:54 |
| Wizzup | no, others will pass | 11:54 |
| uvos | (pending—Waiting for next available executor) | 11:55 |
| uvos | seams stuck | 11:55 |
| Wizzup | let me check | 11:58 |
| Wizzup | not sure what it is waiting for :D | 11:59 |
| uvos | yeah all the workers are idle | 11:59 |
| Wizzup | they all seem reachable too | 12:01 |
| uvos | mysterious :( | 12:01 |
| Wizzup | I will just kick them all | 12:01 |
| uvos | seams to not have done sphone any good | 12:05 |
| Wizzup | mhm | 12:06 |
| uvos | btw | 12:06 |
| uvos | i hope to implement the framework level changes to sphone to decouple the display name tomorrow | 12:07 |
| dsc_ | PSA jib now has built-in adblock with rules from ublock origin | 12:08 |
| uvos | neat | 12:09 |
| uvos | would you mind if i implement a method to pin websites to the recents thingy | 12:09 |
| dsc_ | sure | 12:11 |
| Wizzup | rebooting the jenkins vm just in case | 12:11 |
| Wizzup | I saw some SEVERE hudson.triggers.SafeTimerTask#run: Timer task hudson.model.Queue$MaintainTask failed | 12:12 |
| dsc_ | uvos: https://github.com/maemo-leste-extras/jib/blob/master/src/popularitymodel.cpp#L28 <== "model" holds these items, the source is SQL but you could inject something here at your discretion | 12:12 |
| dsc_ | but maybe you want a 2nd row for such pins | 12:13 |
| Wizzup | jenkins is ging now | 12:13 |
| Wizzup | try jib in 10-150 mins dsc | 12:13 |
| dsc_ | actually we're talking about bookmarks right now, its already half implemented. There is bookmarkmodel.cpp | 12:14 |
| dsc_ | but not used | 12:14 |
| Wizzup | after that I will build another kernel | 12:14 |
| dsc_ | Wizzup: thanks | 12:15 |
| Wizzup | uvos: so I think today I would like to work on the rtcom logging stuff we discussed, I'll dig through the logs to find the most recent approach we agreed upon, unless you have some other ideas now? | 12:15 |
| uvos | no but that exactly needs the framework changes i would like to do myself | 12:16 |
| uvos | so please work on something today else ill do this tomorrow | 12:16 |
| uvos | *else today | 12:16 |
| uvos | dsc_: if you are implementing bookmarks soon i wolnt bother, i was thinking of pining things as a bookmarks-lite | 12:17 |
| dsc_ | i need half a day to implement bookmarks | 12:18 |
| dsc_ | maybe ill do it tomorrow | 12:18 |
| Wizzup | uvos: ok, ty | 12:18 |
| Wizzup | uvos: no need to do it assuming you're busy, but I think wifi hotspot started to work sometime in the stable 6.1.y patches | 12:25 |
| Wizzup | so I would wager that it doesn't work in stable, but it works on devel kernel | 12:25 |
| Wizzup | maybe we can try to identify that fix commit and pull it in - since 6.6.y doesn't work again | 12:26 |
| uvos | hmm | 12:32 |
| uvos | i kinda doubt there is a commit that fixes this persay since i would expect them to apply this to 6.6 stable too | 12:33 |
| uvos | but bisecting might give a clue why it sometimes works and sometimes dosent | 12:33 |
| uvos | i remember it not working 5.9 or something and then suddenly working in 5.10 again | 12:33 |
| uvos | so this has been flip floping for a while | 12:34 |
| Wizzup | it did not work in 6.1 earlier but does now in -devel | 12:40 |
| uvos | i get that | 12:42 |
| uvos | but i expect fixes to be backported to 6.1 to also be backported to 6.6 | 12:43 |
| uvos | so if a obvious fix patch exists, i expect it would be applied, so i suspect that its not a fix persay but that something is racy, which would explain why it breaks often in random kernel version ranges | 12:43 |
| Wizzup | maybe, I also blame hostapd version changes | 12:50 |
| Wizzup | like maybe it tries to enable wpa3 or something silly | 12:50 |
| Wizzup | arno11: building new kernel with likely header fix | 12:56 |
| arno11 | cool | 12:57 |
| arno11 | i still wonder where slowdown is comming from: conversations or other qt stuff take 25 sec to launch sometimes ! instead of 1 or 2 sec on 6.1 | 13:00 |
| arno11 | how kernel could affect mostly/only qt5 ? | 13:01 |
| uvos | Wizzup: could be | 13:01 |
| uvos | arno11: since the n900 is esstanly oom when launching qt stuf the kernels choices can have a big impact | 13:02 |
| arno11 | it really doesn't seem oom honestly | 13:03 |
| uvos | i mean its fairly deep into swap no? | 13:03 |
| uvos | it was last time i tried | 13:03 |
| uvos | which pages the kenrel decides to ejct makes a big difference here, ofc im just thinking out loud i dont really know why it would change that mutch | 13:04 |
| arno11 | i didn't noticed any diff with swap in 6.6 atm. it usually only uses around 100MB of swap | 13:07 |
| arno11 | and issue is really random | 13:07 |
| arno11 | sometimes it works fine | 13:07 |
| uvos | i maen 100mb of swap is alot on a 256mb machine | 13:08 |
| uvos | but yeah i have no idea about the root cause | 13:08 |
| Wizzup | freemangordon: btw on fremantle I can get xmpp calls ti work with my xmpp server to a certain degree: my n900 can hear my laptop sound, but not vice versa (probably stun rtelated) | 13:10 |
| arno11 | uvos: yes indeed that's a lot but perfectly fine with 6.1 | 13:11 |
| arno11 | Wizzup: yes probably @stun or maybe the mic ? | 13:14 |
| arno11 | ah cool build seems ok, let's try to upgrade again | 13:19 |
| sicelo | arno11: what qt programs give you problems? | 13:23 |
| sicelo | i generally stay away from qt applications anyway (even on desktop), so i haven't really seen the excessive slow downs you mention | 13:25 |
| sicelo | (or I'm just too patient 😃) | 13:25 |
| Wizzup | a lot of maemo leste is qt so.. | 13:26 |
| sicelo | yeah, I'm aware (which is a pity ... Fremantle was mostly gtk) | 13:27 |
| Wizzup | I don't think it's a pity, gtk3 and gtk4 have gotten significantly more memory heavy and sluggish afaict | 13:28 |
| arno11 | sicelo: all qt5 apps but only on 6.6, quite fast on 6.1 | 13:28 |
| Wizzup | and we can't stay on gtk2 forever | 13:28 |
| Wizzup | arno11: try new kernel wrt dkms | 13:29 |
| arno11 | i just finished upgrade, iphb-dkms is ok :) | 13:29 |
| arno11 | need to reboot now | 13:29 |
| sicelo | not really (@gtk3/4 getting worse). at least going by the fact that plasma mobile is still heavier than phosh (gtk3) ... which is funny since plamo is fully accelerated while large parts of phosh/gtk aren't | 13:30 |
| sicelo | arno11: will retest soon on mine | 13:30 |
| uvos | thats qtquick | 13:30 |
| uvos | i find qt widgets alot better than gtk4 and generally lighter too | 13:30 |
| uvos | no suprise given how gtk4 works | 13:31 |
| uvos | but yes quick is extreamly slow | 13:31 |
| arno11 | sicelo: ok | 13:31 |
| sicelo | btw, yesterday evening i was playing with alarms on the d4 ... the face-down-to-silence gesture did not work. known issue? | 13:34 |
| uvos | yes i think so | 13:34 |
| uvos | i dimly remember something missing in mce | 13:35 |
| sicelo | mmm, maybe I'll look into it over the weekend | 13:35 |
| uvos | if you do please add some way to disable this | 13:36 |
| uvos | as i hate this feature on android | 13:36 |
| uvos | (after haveing being bitten by it with my gfs phone being in her handbag a couple of times) | 13:37 |
| sicelo | i suppose accelerometer and proximity are hooked and working via mce, so sounds strange why it shouldn't be working already (i forget if it's based on prox or accel) | 13:37 |
| uvos | iirc its both | 13:37 |
| uvos | and mce sends a special signal for it | 13:38 |
| uvos | but i may be wrong this is all a long time ago | 13:38 |
| sicelo | I'll check. | 13:38 |
| uvos | https://github.com/maemo-leste/mce/blob/23f40478c86cb14c39e5bcf972cef574054f0598/src/modules/iio-accelerometer.c#L55 | 13:43 |
| sicelo | now that we dropped actdead, alarm from powered off state takes much longer to notify user | 13:43 |
| uvos | sicelo: MCE_ORIENTATION_FACE_DOWN is not supported | 13:44 |
| uvos | probubly because it dident translate well to a iio-s-p state | 13:44 |
| sicelo | ah | 13:44 |
| uvos | so you would have to do something more fancy | 13:44 |
| dsc_ | conversations is 50mb resident mem on startup and idle in the background | 13:45 |
| dsc_ | qtquick is only used for chat windows | 13:45 |
| dsc_ | and its +10mb per window | 13:46 |
| dsc_ | </Qt propaganda> | 13:46 |
| sicelo | :-) | 13:47 |
| sicelo | yeah iio-s-p is limited (or limiting) | 13:48 |
| sicelo | the new iio-s-p maintainer is also a maintainer pmos-side. maybe there could be interest in adding more accel states | 13:49 |
| sicelo | actually it's only just face up and face down that's missing ... sounds like something i can add too | 13:57 |
| Wizzup | sicelo: yes please add, I really miss the putting the phone face down\ | 14:02 |
| uvos | are two stucts with the same members except one as some more members at the end guarenteed to have the same padding? | 14:09 |
| Wizzup | maybe, but I wouldn't rely on it | 14:10 |
| Wizzup | ok, calls work on the bionic too | 14:13 |
| Wizzup | well, maybe this is when I switch back to using leste as main phone :) | 14:13 |
| sicelo | silly, but interesting nonetheless ... https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/blob/master/src/orientation.c?ref_type=heads#L5 | 17:07 |
| sicelo | in fact, https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/blob/master/src/orientation.c?ref_type=heads#L5-9 | 17:07 |
| inky | I solved hildon rotation in pascal. Wanted to do with x11 functions but it didnt work out for some reason, ut worked via gtk/gdk calls. | 18:08 |
| arno11 | Wizzup: ok so i tried again 6.6 and...swap seems totaly broken | 18:10 |
| arno11 | i mean vm.swappiness=0 solves the issue | 18:11 |
| arno11 | ofc multitasking is difficult but extrem slowness disappeared entirely | 18:12 |
| arno11 | i really don't know what's the diff with 6.1 excepting known swap bugs | 18:12 |
| sicelo | inky: what hildon rotation you mean? | 18:13 |
| arno11 | and really no idea to solve the issue | 18:14 |
| arno11 | *how to solve | 18:14 |
| arno11 | will investigate more. that's easier with a well responsive device now :P | 18:15 |
| uvos | io might be slow for some reason | 18:15 |
| uvos | i think we had that before | 18:15 |
| arno11 | ah ok | 18:16 |
| uvos | maybe try benchmarking the sdcard between 6.1 and 6.6 | 18:16 |
| arno11 | ah good idea, i have already results for 6.1 | 18:17 |
| arno11 | i'll do that | 18:17 |
| uvos | or i gues emmc rather | 18:17 |
| uvos | since swap is on emmc | 18:17 |
| uvos | unless you changed it? | 18:17 |
| arno11 | nope i use emmc | 18:17 |
| arno11 | and works fine with 6.1 | 18:18 |
| arno11 | but i can try swap on sd + 6.6 | 18:18 |
| arno11 | to check the diff | 18:18 |
| uvos | rather more interesting is to see if io benchmarks are slower on 6.6 | 18:19 |
| uvos | sdcard is on the same interface as emmc anyhow | 18:19 |
| uvos | hard to belive one would be affected but not the other | 18:19 |
| arno11 | yes indeed | 18:19 |
| uvos | swaping on sdcard should be faster in general, as modern sd cards have mutch faster random reads/writes than n900s emmc | 18:19 |
| uvos | but thats a seperate issue | 18:20 |
| uvos | well good modern sdcards anyhow | 18:20 |
| arno11 | yes | 18:20 |
| arno11 | btw i hit sd bus limits with my sd and 6.1 | 18:21 |
| arno11 | let me check 6.6 | 18:21 |
| uvos | for sequential access any sdcard will hit the bus limits | 18:23 |
| uvos | small randoms are more interesting | 18:23 |
| uvos | but my sdcard still hits the bus limit until below 1k blocks | 18:23 |
| arno11 | ah ok | 18:24 |
| uvos | small randoms is also closer to what swap needs | 18:24 |
| uvos | swap tends to need a page here, a page there etc | 18:25 |
| arno11 | results are similar with what i see on 6.1, at least using dd | 18:31 |
| arno11 | *for the sd card | 18:32 |
| arno11 | uvos: with small blocks it seems very slow. what command do you use to bench btw ? | 18:36 |
| arno11 | using hdparm, read seems slow on emmc | 18:50 |
| arno11 | only 5MB/sec | 18:50 |
| Wizzup | is that different on 6.1? | 18:55 |
| gnarface | with emmc it's usually safe to use a larger block size | 18:59 |
| gnarface | that should speed it up, though i'd try to still make it a multiple of the physical block size | 18:59 |
| arno11 | ok | 18:59 |
| gnarface | try something between 1MB and 8MB just make sure it's an even multiple of the physical block size | 18:59 |
| arno11 | ok | 19:00 |
| sicelo | iio-s-p folk say they'd love to have the face-down/up support | 19:03 |
| arno11 | i'll LYK later, need time to compare with 6.1 | 19:04 |
| arno11 | bbl | 19:05 |
| Wizzup | sicelo: great! | 21:29 |
| sicelo | getting unexpected behavior with iio-s-p ... https://paste.debian.net/1323081/ | 21:58 |
| sicelo | code used is https://github.com/maemo-leste-upstream-forks/iio-sensor-proxy/ | 21:58 |
| sicelo | i'm not expecting the values to be different at this point :-/ | 22:07 |
| arno11 | Wizzup: uvos: to make it short, the swap issue is due to emmc itself (with 6.6, not with 6.1) | 22:09 |
| arno11 | i got a well working stuff using sd swap file | 22:09 |
| arno11 | now it is stable | 22:09 |
| arno11 | and almost as fast as 6.1 | 22:10 |
| arno11 | but it took several minutes to swapoff emmc | 22:10 |
| arno11 | maybe something is wrong on boot ? | 22:10 |
| sicelo | sounds all good to me :-) | 22:12 |
| sicelo | it's correct for swapoff to take some time | 22:13 |
| gnarface | why not use zram for swap? just curious | 22:13 |
| arno11 | according to irc logs it was problematic on N900 | 22:14 |
| gnarface | oh, didn't know that | 22:14 |
| arno11 | but i don't know exactly why | 22:14 |
| arno11 | fmg should know | 22:14 |
| sicelo | time to build latest/upstream iio-s-p i guess | 22:14 |
| gnarface | how much ram does it have? maybe it's not enough | 22:14 |
| sicelo | 256MB | 22:15 |
| gnarface | oh. yea, maybe that's why. also, now that i realize you're using a N900, i revise the parameters for optimal dd block size use; 8MB may be too much. some multiple of the physical emmc block size for sure, but maybe start with 2x or 4x and work your way up doing some benchmarks | 22:16 |
| arno11 | with 1MB i got similar results with both 6.1 and 6.6 | 22:22 |
| arno11 | btw, not related but calls works fine with no more hangup issue, boost mode is ok, conversations ok, i still need to kill hsm as usual but apparently no other issues | 22:26 |
| arno11 | so excepting swap, everything seems similar to 6.1 now so i'm happy :) | 22:27 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!