| Wizzup | uvos: thanks for checking | 00:18 |
|---|---|---|
| Wizzup | can you push this somewhere | 00:18 |
| Wizzup | I'd like to check | 00:18 |
| Wizzup | uvos: what do you mean with lots of other stuff would have to be rebased? | 01:02 |
| Wizzup | uvos: for 6.6+ you mean? | 01:46 |
| uvos | Wizzup: we used a 6.6 rc before | 11:23 |
| uvos | and a lot changed, so almost nothing merges/rebases cleanly on latest stable 6.6 | 11:24 |
| uvos | i was just noteing that | 11:24 |
| Wizzup | understood | 11:24 |
| Wizzup | I would like to put in some effort at least to try to figure out this cpufreq issue once more | 11:24 |
| uvos | i dident rebase anything yet i just did a git rebase and skipped all the conflicts | 11:24 |
| uvos | so theres nothing to push atm | 11:24 |
| Wizzup | so you tried 6.6 without our patches to see if cpufreq would work | 11:24 |
| uvos | i tried 6.6 with limited patches | 11:24 |
| uvos | and 6.9 totaly stock | 11:25 |
| Wizzup | ok | 11:25 |
| uvos | theres nothing about cpufreq in dmesg in either situation | 11:26 |
| uvos | it just dosent load and dosent probe | 11:26 |
| uvos | manually loading the modules dosent make them probe either | 11:27 |
| Wizzup | on my mz617 I get | 11:27 |
| Wizzup | # modprobe cpufreq | 11:27 |
| Wizzup | modprobe: FATAL: Module cpufreq not found in directory /lib/modules/6.6.0-g3e1ba4fc6a7f | 11:27 |
| uvos | probubly something is up with the dtb | 11:27 |
| Wizzup | but I got the name wrong | 11:27 |
| Wizzup | it's cpufreq_dt | 11:27 |
| Wizzup | mhm @ dtb | 11:28 |
| uvos | hmm | 11:28 |
| uvos | cpufreq dosent feature at all in my stock 6.9 dmesg | 11:28 |
| Wizzup | I got it wrong, the module is named cpufreq_dt | 11:28 |
| uvos | i mean dmesg | grep cpufreq dosent show anything so thats covered | 11:28 |
| Wizzup | does it show something on 6.1.76? | 11:29 |
| Wizzup | (cpufreq) | 11:29 |
| uvos | no | 11:30 |
| uvos | but i am expecting an error/warning ofc | 11:30 |
| Wizzup | right | 11:30 |
| Wizzup | I am looking at some other commits like 3fa966ebb08132a90197cc96faa697a7a14873ee and they add a device_type = "cpu"; to cpu@0 nodes | 11:33 |
| Wizzup | I don't know how relevant this is | 11:34 |
| uvos | no idea what its for | 11:34 |
| Wizzup | yeah | 11:34 |
| Wizzup | I'm searching around a bit | 11:34 |
| uvos | modprobe: FATAL: Module cpufreq not found in directory /lib/modules/6.6.0-g3e1ba4fc6a7f | 11:35 |
| Wizzup | did we email the list about this? | 11:35 |
| Wizzup | yeah but it's not called cpufreq | 11:35 |
| Wizzup | it's called cpufreq_dt | 11:35 |
| uvos | as was mentioned before CONFIG_ARM_OMAP2PLUS_CPUFREQ and CONFIG_PM_DEVFREQ are disabled in config | 11:35 |
| uvos | but this is the same as 6.1 | 11:35 |
| uvos | but maybe they got build as a depedancy before that was removed | 11:36 |
| Wizzup | I think we tried to enable these didn't we? | 11:36 |
| Wizzup | I mean worth trying.. | 11:36 |
| uvos | i dont quite remember | 11:36 |
| Wizzup | ok we should enable those | 11:36 |
| uvos | anyhow they remain disabled in stock omap2plus_defconfig | 11:36 |
| Wizzup | I mean for our tests | 11:36 |
| Wizzup | so if I enable those too | 11:39 |
| Wizzup | and run oldconfig | 11:39 |
| Wizzup | it asks me for DEVFREQ_GOV_SIMPLE_ONDEMAND | 11:39 |
| Wizzup | if I want to enable it | 11:39 |
| Wizzup | and for PM_DEVFREQ | 11:39 |
| Wizzup | so yeah, looks like those are disabled too currently | 11:39 |
| Wizzup | I'll build a kernel | 11:40 |
| Wizzup | if we get this to work, would you be up for rebasing to latest 6.6 stable? | 11:41 |
| uvos | sure | 11:41 |
| Wizzup | btw my droid4 has 18 days uptime | 11:41 |
| Wizzup | still solid :) | 11:41 |
| uvos | yeah mine is on 6 days or so | 11:41 |
| uvos | 6.1 has been compleatly solid | 11:42 |
| uvos | do send a patch to the ml if it ends being omap2plus_defconfig being broken | 11:42 |
| Wizzup | of course | 11:42 |
| Wizzup | I want to go to 6.6 just to keep a bit more up to date, and also because my mz617 needs 6.6 and I want to finish the packing for it | 11:42 |
| uvos | yeah sure | 11:42 |
| Wizzup | we should probably also have some 6.9 or higher branch at some point | 11:42 |
| uvos | not sure we gain anything from chaceing mroe than latest stable atm | 11:43 |
| Wizzup | I guess for developing features but you're probably right | 11:43 |
| uvos | er lts i mean | 11:43 |
| Wizzup | I'm going to have the entire weekend off for maemo stuff, so I'm excited to push some things along at least | 11:43 |
| Wizzup | I feel with some additional work we can really improve the lineup, if we can get razr screen to work ok for example | 11:44 |
| uvos | i think it makes more sense to integrate one device for real than to work on lots | 11:45 |
| uvos | the most usefull for that is probubly mz617 | 11:45 |
| Wizzup | that is true | 11:45 |
| Wizzup | the razr just feels very close too, if you catch my drift | 11:45 |
| Wizzup | in any case, kernel building | 11:45 |
| uvos | my intrest has wained a bit since i only have one with a spi modem | 11:46 |
| Wizzup | I can send you ones with usb modems whenever | 11:46 |
| Wizzup | I have a lot | 11:46 |
| uvos | nah :) | 11:47 |
| Wizzup | I mean I did get them to send to folks, but ok :D | 11:47 |
| Wizzup | I've used it the razr for calls and it works | 11:47 |
| Wizzup | s/it the/the/ | 11:47 |
| Wizzup | the battery life is pretty good too | 11:47 |
| Wizzup | arch/arm/boot/dts/ti/omap/motorola-mapphone-common.dtsi:237.30-250.4: ERROR (phandle_references): /ocp/interconnect@48000000/segment@0/target-module@72000/i2c@0/touchscreen@4a: Reference to non-existent node or label "touchscreen_pins" | 11:59 |
| Wizzup | still getting this when making dtbs | 11:59 |
| Wizzup | I think this can probably go since we have this in handset | 12:01 |
| Wizzup | there's also arch/arm/boot/dts/ti/omap/motorola-mapphone-common.dtsi:107.23-138.4: ERROR (phandle_references): /mapphone_touchscreen: Reference to non-existent node or label "touchscreen" | 12:03 |
| Wizzup | ok nvm for now | 12:05 |
| Wizzup | this was just for xyboard mz609 | 12:05 |
| Wizzup | uvos: it's still empty | 12:13 |
| uvos | whats empty? | 12:14 |
| Wizzup | ls /sys/devices/system/cpu/cpufreq | 12:14 |
| Wizzup | Linux maindroid 6.6.0-ga8ce941e80fc #5 SMP PREEMPT Thu May 2 11:53:50 CEST 2024 armv7l GNU/Linux | 12:14 |
| uvos | right ok | 12:14 |
| Wizzup | but the options you mentioned above are enabled | 12:15 |
| uvos | cpufreq_dt loaded? | 12:15 |
| uvos | cpufreq_dt 16384 0 - Live 0x00000000 <- 6.1 | 12:16 |
| Wizzup | wasn't on boot, but when I loaded it, nothing appeared | 12:16 |
| uvos | yeah ok | 12:16 |
| uvos | same bevaivor | 12:16 |
| Wizzup | 12:16 < uvos> cpufreq_dt 16384 0 - Live 0x00000000 <- 6.1 | 12:16 |
| Wizzup | what output is this | 12:16 |
| uvos | /proc/modules from 6.1 | 12:16 |
| uvos | just to show that this is the module used there | 12:17 |
| Wizzup | right | 12:17 |
| Wizzup | at least RET still works on d4 | 12:17 |
| uvos | sure cpuidle works fine | 12:18 |
| uvos | its jut freemangordon | 12:18 |
| uvos | *freq | 12:18 |
| Wizzup | I think we should mail the list | 12:18 |
| uvos | ok | 12:18 |
| Wizzup | I am looking at the diff and a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt was removed | 12:21 |
| Wizzup | since maemo-6.1 and maemo-6.6 | 12:21 |
| Wizzup | this is e576a9a8603f7c6f8fed5159e2fe33f6d67a49e7 | 12:25 |
| Wizzup | dt-bindings: cpufreq: Convert ti-cpufreq to json schema | 12:25 |
| Wizzup | Move the ti-cpufreq binding over to opp and convert the free text binding to json-schema. | 12:25 |
| Wizzup | (this might not matter at all, but...) | 12:26 |
| Wizzup | seems like it might just be documentation convert | 12:27 |
| Wizzup | uvos: I wonder if the problem is that CONFIG_CPUFREQ_DT_PLATDEV=m | 12:43 |
| uvos | what makes you think that? | 12:44 |
| Wizzup | root@maindroid:/sys/module/cpufreq_dt# ls /sys/devices/system/cpu/cpufreq/ | 12:44 |
| Wizzup | ondemand policy0 | 12:44 |
| uvos | works? | 12:44 |
| Wizzup | yup | 12:44 |
| Wizzup | try modprobe cpufreq-dt-platdev | 12:44 |
| uvos | ya | 12:44 |
| Wizzup | # ls /sys/devices/system/cpu/cpu0/cpufreq | 12:45 |
| Wizzup | affected_cpus cpuinfo_min_freq scaling_available_frequencies scaling_driver scaling_min_freq | 12:45 |
| uvos | will later | 12:45 |
| Wizzup | cpuinfo_cur_freq cpuinfo_transition_latency scaling_available_governors scaling_governor scaling_setspeed | 12:45 |
| Wizzup | cpuinfo_max_freq related_cpus scaling_cur_freq scaling_max_freq | 12:45 |
| uvos | so this dosent load on its own? | 12:45 |
| Wizzup | 218a06a79d9a98a96ef46bb003d4d8adb0962056 makes it possible to build it as a module | 12:45 |
| Wizzup | it does not | 12:45 |
| Wizzup | I feel like this is something we could bring up on the ml, no? | 12:45 |
| uvos | yeah for sure | 12:45 |
| Wizzup | ml being mailing list | 12:45 |
| Wizzup | ok, let me just do that now | 12:45 |
| uvos | and set it y for now ofc | 12:45 |
| Wizzup | in our defconfig? | 12:45 |
| Wizzup | let me do that and re-test | 12:45 |
| uvos | sure that should fix the immidate problem no? | 12:45 |
| Wizzup | yes | 12:46 |
| Wizzup | well, glad this worked out :) | 12:46 |
| uvos | ok is should have some time on sunday to do the rebase | 12:46 |
| uvos | *i | 12:46 |
| Wizzup | great, I will be around, let's also pls make sure we pull in the droid 3 stuff | 12:47 |
| Wizzup | rebooting to test | 12:48 |
| arno11 | Wizzup: (for cpufreq) well done man !!! | 12:49 |
| Wizzup | yes, then we can go to 6.6 lts :) | 12:51 |
| arno11 | really cool | 12:53 |
| Wizzup | https://groups.google.com/g/linux.debian.kernel/c/ETrj3gCQzn0?pli=1 | 12:55 |
| Wizzup | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050587 debian just made it built it | 12:56 |
| Wizzup | mailed the ml | 13:03 |
| Wizzup | sicelo: ok, I see some issues with calls too atm, maybe it is 6.6, maybe it is the same you were seeing | 13:08 |
| arno11 | Wizzup: on my device with 6.1.76 (and i forgot to mention it), calls are buggy with TP if you don't launch sphone UI first (after boot). Sometimes it fails 3-4 times before working properly. and then everything is fine (call audio) | 13:17 |
| arno11 | (when i say calls are buggy, i mean audio works sometime only in one way or is crappy/distorded) | 13:19 |
| arno11 | but once sphone UI starts normally, everything is fine (excepting the weird hangup issue) | 13:21 |
| Wizzup | OK | 13:21 |
| uvos__ | yeah tp backend still has issues here too whenever i try it | 13:22 |
| uvos__ | still needs a bit time in the oven before we can promote it thats for sure | 13:22 |
| Wizzup | I am not sure if this is tp but will try to figure out now | 13:22 |
| uvos__ | sure something in the stack, could very well be the kernel | 13:23 |
| uvos__ | the issues i see are the same as arno11, well i cant say that the launch order dose anything | 13:23 |
| uvos__ | but sometimes i get no audio | 13:23 |
| Wizzup | mhm | 13:23 |
| uvos__ | while direct ofono has been 100% for me | 13:23 |
| arno11 | same for me, no troubles with direct ofono | 13:25 |
| uvos__ | arno11: btw what do you mean launch "sphone" | 13:25 |
| uvos__ | it launches itself | 13:25 |
| uvos__ | at boot | 13:25 |
| arno11 | i mean the caller UI | 13:25 |
| uvos__ | really that makes a difference for you | 13:25 |
| uvos__ | thats wierd | 13:25 |
| arno11 | yes | 13:25 |
| arno11 | it works, able to use it normally | 13:26 |
| uvos__ | opening the ui just dose a dbus call to the sphone process to show a window ithas open anyhow | 13:26 |
| Wizzup | on 6.6 ofono backend does not work for me either | 13:26 |
| Wizzup | let me go to 6.1 | 13:26 |
| uvos__ | Wizzup: well its not fully rebased so the modem could just be missing | 13:26 |
| dsc_ | uvos__> still needs a bit time in the oven :D | 13:26 |
| uvos__ | could you check if sphone is runing at boot arno11? | 13:26 |
| uvos__ | dsc_: btw latest jib is really great | 13:27 |
| Wizzup | it does say 'VOICECALL 0' and such | 13:27 |
| dsc_ | oh cool, thanks for letting me know | 13:27 |
| uvos__ | love the ui | 13:27 |
| dsc_ | any wishes still | 13:27 |
| dsc_ | ? | 13:27 |
| uvos__ | dsc_: but opening a new window via context menu dosent seam to work | 13:27 |
| uvos__ | should it? | 13:27 |
| uvos__ | but the context menu looks great now | 13:27 |
| dsc_ | ah hmm | 13:28 |
| dsc_ | yes it should work | 13:28 |
| uvos__ | hmm | 13:28 |
| dsc_ | new menu was wizzup's idea btw | 13:28 |
| dsc_ | with the icons | 13:28 |
| dsc_ | but yes better | 13:28 |
| dsc_ | or maybe it doesnt have icons yet, i forgot | 13:29 |
| arno11 | uvos: yes it runs on boot (because i'm able to receive 'buggy calls' immediately after boot) | 13:29 |
| uvos__ | arno11: ok, behaivor is really wierd then | 13:30 |
| arno11 | yep | 13:30 |
| Wizzup | could maybe relate to vcm somehow | 13:30 |
| Wizzup | uvos__: just tried on mz617, new window works there | 13:30 |
| Wizzup | About however shows nothing :p | 13:31 |
| uvos__ | Wizzup: hmm | 13:32 |
| uvos__ | yeah about dosent work here either | 13:32 |
| uvos__ | generally i cant seam to select anythin in the context menu at all | 13:32 |
| Wizzup | on 6.1 calls worked ok, but I will debug more | 13:35 |
| Wizzup | I need to keep it on 6.1 for the moment because I am expecting a call :D | 13:35 |
| arno11 | :D | 13:35 |
| arno11 | 6.1 is amazingly stable | 13:36 |
| Wizzup | I hope others will be too going forward | 13:37 |
| Wizzup | but we will see :D | 13:37 |
| uvos__ | expirance says d4 random reboots and n900 dosent boot at all :P | 13:37 |
| Wizzup | lol | 13:37 |
| Wizzup | yeah | 13:38 |
| Wizzup | but I think it has gotten better | 13:38 |
| Wizzup | it might get worse when we try to improve pm | 13:38 |
| uvos__ | tmlind: or Wizzup: do you know if the decoupeling of the kenrel serial console with pm landed in 6.6? | 13:39 |
| Wizzup | I don't know but I would be excited if it did | 13:39 |
| kiva | what is that process: temp-reaper ? | 14:04 |
| Wizzup | osso-af-utils: /usr/sbin/temp-reaper | 14:04 |
| kiva | why it has that kind of name? | 14:05 |
| Wizzup | probably this https://github.com/maemo-leste/osso-af-utils/blob/master/src/temp-reaper.c | 14:05 |
| Wizzup | I suppose it deletes regular files in /tmp that weren't touched for a long time if the disk is getting full | 14:05 |
| Wizzup | kind of niche | 14:06 |
| Wizzup | but with year+ uptime of fremantle I suppose it made sense | 14:06 |
| kiva | ah..it really has good reason to that name. | 14:06 |
| kiva | thanks for good answer | 14:06 |
| Wizzup | we might eventually remove some of these things from maemo leste | 14:07 |
| Wizzup | especially if/when they get upstream replacements | 14:07 |
| kiva | nerdcore: About that font size. Pinephone screen resolution is 1440x720, AllWinner support hardware zoom 720x360 screen memory (layer) to 1440x720 screen, but there is not support for that. xrandr have software solution, you can try that. | 14:20 |
| Wizzup | I think he did | 14:56 |
| uvos__ | if you kiss potterings ring you get systemd-tmpfiles which dose exactly the same thing | 15:20 |
| uvos__ | not sure if the sysv/openrc world has something like this too | 15:20 |
| nerdcore | decreasing the xrandr scale value from 1.0 to 0.8 helped. I might try even more scaling another day, and I will try to get some screenshots for the gang here | 15:21 |
| Wizzup | sweet | 15:24 |
| Wizzup | maybe also add it to the pinephone wiki page | 15:24 |
| Wizzup | (ours) | 15:24 |
| Wizzup | uvos__: we also get a sudo replacement then :D | 15:24 |
| arno11 | Wizzup: i opened a new issue (#737) as a reminder for last N900 tweaks | 18:25 |
| arno11 | i forgot appmenu-gtk stuff btw | 18:29 |
| nerdcore | Wizzup: with respect, I would suggest that UI/font scaling is an Accessibility issue not specific to the PinePhone device. | 19:10 |
| Wizzup | I mean, sure, but there's no alternatives to doing what I suggested and it seems like a bigger issue on high dpi screens | 19:30 |
| Wizzup | you can put it on some other page if you want | 19:30 |
| nerdcore | it's not just about high DPI values. As humans get older (which we all do) our eyes go through about 3-4 changes, when we are very young and in puberty and later on in life... So likely each and every one of us will have worse vision at some time in our lives. | 20:14 |
| nerdcore | building accessible systems is not just about supporting people who live with disabilities today, but supporting our own future selves. | 20:15 |
| Wizzup | that's all fine and you get no argument from me, but right now this is the best we can do | 20:19 |
| Wizzup | we are planning to move to gtk3/gtk4 at a later point, but we don't have the man power to do this | 20:19 |
| sicelo | https://www.piggz.co.uk/sites/pgz/blog/sailfish-ofono-26: "upstream Ofono now has all the code needed for supporting voice-calling on the Pinephone, and likely other qmi-compatible devices" | 22:54 |
| sicelo | yay | 22:54 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!