| sicelo | yes. will get around to it though, as i already obtained all the electronic components i need. just need a plan for making contact with the pads | 05:51 |
|---|---|---|
| freemangordon | dsc_: heh, m_quickWidget->setAttribute(Qt::WA_AlwaysStackOnTop); makes it work | 06:48 |
| freemangordon | omg, see https://doc.qt.io/qt-6/qopenglwidget.html | 06:51 |
| freemangordon | "Note: Displaying a QOpenGLWidget requires an alpha channel in...." | 06:51 |
| freemangordon | "If there is no alpha channel, the content rendered by the QOpenGLWidget will not be visible" | 06:52 |
| tmlind | got the mcbsp issue sorted out, disabled some unused devices to free more dma channels. pushed out v6.6 based branch to https://github.com/tmlind/linux/commits/mapphone-pending-v6.6 | 07:49 |
| tmlind | the framebuffer console not updating lcd issue still remains | 07:49 |
| tmlind | pvr stuff seems to behave based on light testing, pushing that out too | 07:49 |
| tmlind | pvr stuff pushed out to https://github.com/tmlind/linux_openpvrsgx/commits/mapphone-pending-pvr-omapdrm-v6.6 | 07:58 |
| tmlind | here's the va_to_pfn() change i made, please check if i missed something.. https://github.com/tmlind/linux_openpvrsgx/commit/215165f141d239ac7ea518c004eaf697ec7d7a1e | 07:59 |
| tmlind | will email that to linux_openpvrsgx list | 07:59 |
| tmlind | mailed, that's it for me probably until the weekend. i'll start posting the pending dts and usb patches so we can at least clear out the major branch merge bottlenecks with the dts files | 08:01 |
| tmlind | at least dmesg -l err,warn helped debugging the audio issue with less errors and warnings to look at now | 08:03 |
| tmlind | sicelo: the ofono d4 serial port modem support should be updated to use ell for raw packet reads and writes and then it could get merged | 08:25 |
| sicelo | ok | 09:22 |
| sicelo | btw, osso contacts has a h-i-m bug ... you can't type a number in the cell field using hwkb when adding a contact. at least that's what i observe on my Droid 4 | 09:29 |
| arno11 | Wizzup: oh there is no qt support for maemo-launcher ? could explain why some apps start in a sec and others in 10 | 10:22 |
| Wizzup | right | 10:25 |
| Wizzup | freemangordon: that's unfortunate @ alpha | 10:27 |
| arno11 | Wizzup: after double-checking, yes it concerns only apps with qt5 deps | 10:41 |
| Wizzup | sicelo: it might be that it's limited to n900 kbd | 11:26 |
| sicelo | yeah anything is possible. but I doubt it's that. | 11:38 |
| Wizzup | what I mean is that it's expecting a certain layout | 11:42 |
| Wizzup | I wonder if we can use XWayland's rootful mode | 12:38 |
| uvos | Wizzup: we could, but it would be monumentally stupid | 13:26 |
| uvos | you loose all the advantages of x, while gaining no advantages | 13:27 |
| dsc_ | freemangordon: ok <_< | 13:30 |
| dsc_ | thanks for debugging that, ill set the flag | 13:30 |
| arno11 | Wizzup: is it ok for you if i cancel the current transitions PR and create a new one with PA daemon.conf only ? | 13:36 |
| Wizzup | sure | 13:43 |
| Wizzup | I am interested in the transitions one too, but let's separate them | 13:43 |
| arno11 | ok, so i'll create 2 different PR's | 13:44 |
| arno11 | and indeed custom transitions is really cool and easy to modify on the fly | 13:44 |
| arno11 | Wizzup: i added 2 different PRs (and closed the old one) | 14:38 |
| Wizzup | thanks | 14:42 |
| Wizzup | uvos: mz615 arrived too, so I could probably try to get various utags later for the models if they are different | 14:48 |
| arno11 | Wizzup: btw is Twinkle still working on your D4 ? can't login my sip account anymore (with 401 unauthorized) on n900 (the account works on other devices) | 15:05 |
| Wizzup | I don't think twinkle should act differently on different devices | 15:06 |
| arno11 | i mean just the sip account works on other devices | 15:06 |
| arno11 | just twinkle shows error on my n900 | 15:07 |
| arno11 | anyway i'll have a look later, i asked just in case you have the same issue | 15:08 |
| Wizzup | I still have to set up my n900 again | 15:15 |
| arno11 | issue solved, forget my question :) | 15:20 |
| arno11 | just a wrong parameter i forgot to remove | 15:21 |
| Wizzup | makes sense | 15:25 |
| Wizzup | lol, qemu goes black every time I make a call and then I have to reboot | 15:46 |
| Wizzup | arg | 15:46 |
| Wizzup | it looks like quectel eg-25 (usb glink from olimex) can emulate a virtual sound card over usb and then calls can be done that way | 16:58 |
| Wizzup | not super interesting but I didn't know | 16:58 |
| Wizzup | uvos: for mz617 or similar, I guess I can open one up and hook its battery connected directly to a lab psu | 16:59 |
| Wizzup | connector* | 16:59 |
| uvos | Wizzup: sure | 17:25 |
| uvos | tmlind: none of the mapphone dtbs compile on your mapphone-pending-v6.6 branch | 17:25 |
| uvos | as allways dtc isent very helpfull: Error: omap4-droid4-xt894.dts:4.1-9 syntax error | 17:26 |
| uvos | thats just #include "motorola-mapphone-xt8xx.dtsi" | 17:27 |
| uvos | i gues the real problem could be in any subsiquent file | 17:27 |
| uvos | ah its because i have to build ti/omap/omap4-droid4-xt894.dtb | 17:37 |
| uvos | whats really confusing about that is that omap4-droid4-xt894.dtb worked just fine with make[3]: Nothing to be done for 'arch/arm/boot/dts/omap4-droid4-xt894.dtb' untill i cleaned the tree | 17:37 |
| uvos | thats really error prone | 17:37 |
| uvos | it was just using the old dtb from 6.1 previously | 17:38 |
| uvos | that feals like a buildsystem bug, if arch/arm/boot/dts/omap4-droid4-xt894.dts dissapears the omap4-droid4-xt894.dtb target should not work, just because a old dtb is lying around | 17:39 |
| uvos | Wizzup: do you know where ci gets what dtbs to build from? | 17:54 |
| uvos | Wizzup: clearly its not this https://github.com/maemo-leste/droid4-linux/blob/1d5c83744ed5a182c3bd615175c9f640765d3092/debian/rules#L4 | 17:54 |
| uvos | Wizzup: anyhow maemo-6.6 is ready for a build as soon as the ci dts situation is cleared | 18:24 |
| uvos | besides the kernel not refreshing the cm display in vt, i dont see any futher issues | 18:24 |
| uvos | this breaks the emergency shell mode but is otherwise inconsequential | 18:26 |
| uvos | d4 tested only ofc | 18:28 |
| uvos | someone has to do n900 | 18:28 |
| uvos | hmm and cpufreq dissapeard in 6.6 | 19:00 |
| uvos | and powermanagement dosent work, no ret | 19:01 |
| uvos | but it dosent work on 6.1 either here it seams | 19:01 |
| ac_laptop | Hello people | 19:17 |
| ac_laptop | Good news: I realised that when my N900 on Leste was idle for a long time (a few hours) it was taking a loooooot of time to leave idle mode. Then it's possible that what I had interpreted as the device being shut down because it had used all its battery was just the device taking a lot of time to respond. I'll make further tests, with the stock battery and a 1430mAh replacement battery that | 19:22 |
| ac_laptop | I've bought. | 19:22 |
| ac_laptop | I've also received my c10 u3 card, I've just installed Leste on it. Suppose I want to put an additional partition on it, do you advise that I run the expand.sh script and then reduce the main partition ? Or that I create the new partition with the size I want and then run the expand.sh script ? | 19:24 |
| sicelo | no need for expand ... jyst do it your own way, e.g. with gparted | 19:27 |
| sicelo | s/expand/expand script/ | 19:27 |
| Wizzup | uvos: yes, I can help add any dtbs, it is a bit hacky | 19:35 |
| Wizzup | uvos: you get no RET ? | 19:35 |
| Wizzup | (in 6.1) | 19:35 |
| uvos | its not the kernel | 19:38 |
| uvos | its userspace | 19:38 |
| uvos | i do get ret before the maemo userspace loads | 19:38 |
| uvos | after that its 300 ish mw and no futher rets | 19:38 |
| Wizzup | so some driver that is used by maemo now keeps kernel awake? | 19:42 |
| uvos | maybe idk | 19:43 |
| uvos | dose it work on your system with the current 6 | 19:43 |
| uvos | .1 kernel? | 19:43 |
| Wizzup | root@maindroid:~# /etc/init.d/droid4-powermanagement status | 19:44 |
| Wizzup | d=2023-11-15|t=19:43:16|i=OFF:0,RET:379348|p=381|c=100|b=none | 19:44 |
| Wizzup | root@maindroid:~# sleep 30 ; /etc/init.d/droid4-powermanagement status | 19:44 |
| Wizzup | d=2023-11-15|t=19:43:51|i=OFF:0,RET:379452|p=183|c=100|b=none | 19:44 |
| Wizzup | Linux maindroid 6.1.48 #1 SMP PREEMPT Wed Aug 30 14:28:56 UTC 2023 armv7l GNU/Linux | 19:44 |
| uvos | hmm | 19:44 |
| uvos | so its something specific to my install | 19:44 |
| uvos | always fun | 19:44 |
| arno11 | ac_laptop: taking lot of time to leave idle is not normal and not a known issue on N900 | 19:47 |
| Wizzup | uvos: looks like it yes | 19:49 |
| arno11 | seems something is slowing done your 0S: just a question, was wifi still On ? | 19:49 |
| Wizzup | uvos: so what is the dtb problem specifically, did they get renamed? | 19:49 |
| uvos | Wizzup: yes | 19:49 |
| uvos | the whole thing got restructured | 19:49 |
| uvos | its ti/omap/* now | 19:50 |
| uvos | bigger issue is cpufreq is just missing with no explenation | 19:50 |
| Wizzup | maybe the config got renamed | 19:52 |
| arno11 | ac_laptop: the only thing i know able to slowing down N900 (a loooot) periodically is apt-worker | 19:53 |
| Wizzup | uvos: what is the 6.x branch | 19:58 |
| uvos | maemo-6.6 | 19:58 |
| uvos | maemo-6.1.y | 19:58 |
| uvos | maemo-6.1 | 19:58 |
| Wizzup | git fetch didn't show it, weird | 19:58 |
| Wizzup | sorry, I meant 6.6 branch* | 19:58 |
| Wizzup | fatal: 'origin/maemo-6.6' is not a commit and a branch 'maemo-6.6' cannot be created from it | 19:58 |
| uvos | huh | 19:58 |
| sicelo | cpufreq is still in kernel. nothing changed there. what exactly are you seeing? | 19:59 |
| uvos | the config is there | 19:59 |
| uvos | but | 19:59 |
| uvos | /sys/bus/cpu/devices/cpu0/cpufreq anf friends dissapeard | 20:00 |
| Wizzup | uvos: the branch also isn't on github | 20:00 |
| sicelo | i've had 6.6 on pmOS for a while. will check when my battery is charged | 20:01 |
| uvos | Wizzup: https://github.com/IMbackK/droid4-linux/tree/maemo-6.6 | 20:02 |
| uvos | its there, havent pushed it to the maemo repo | 20:02 |
| uvos | will now however | 20:02 |
| Wizzup | so the way I remember this works is that we patch scripts/package/builddeb | 20:03 |
| uvos | can remove the rules | 20:03 |
| uvos | its confuseing | 20:03 |
| Wizzup | so you would edit scripts/package/builddeb if the dtbs are renamed | 20:04 |
| Wizzup | what the debian/rules do I have to check but I think we do need them, maybe just not the DTB part of it | 20:04 |
| uvos | powertop suggests tracker-store is using a lot of cpu while idle | 20:05 |
| Wizzup | ah, maybe it's either buggy on your machine, or it's doing it's initial indexing? | 20:06 |
| Wizzup | I had to nuke my tracker state to get it to behave too | 20:06 |
| uvos | where dose it have its state? | 20:06 |
| Wizzup | try | 20:07 |
| Wizzup | tracker reset --hard | 20:07 |
| Wizzup | rm -rf ~/.cache/tracker/ | 20:07 |
| sicelo | cpufreq available on N900 using 6.6 (pmOS ... but distro is irrelevant for kernel) | 20:08 |
| Wizzup | is it the same kernel config? | 20:08 |
| uvos | i mean the related configs are enabled CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y CONFIG_CPUFREQ_DT=m, they are also not renamed | 20:16 |
| uvos | i suspect the problem in omap4 dt | 20:16 |
| ac_laptop | arno11: I'll make some more tests | 20:17 |
| Wizzup | uvos: so they didn't add some setting for cpufreq sysfs or so? | 20:18 |
| ac_laptop | Concerning the fresh install message, the part about install zram-tools and removing /etc/init.d/zram can probably be removed since it's already done. But I guess it's still necessary to configure /etc/default/zramswap ? | 20:20 |
| uvos | Wizzup: looking at drivers/cpufreq/Kconfig i dont see anything | 20:20 |
| ac_laptop | is it relevant to put a value of SIZE=1024 on n900 ? | 20:21 |
| uvos | Wizzup: so killing everything mafw related has improved the pm situation | 20:21 |
| Wizzup | ac_laptop: I think 1024 would be too high | 20:23 |
| ac_laptop | Wizzup: so 256 ? the size of the RAM ? | 20:24 |
| uvos | more than half physical ram is pretty silly | 20:24 |
| uvos | besides its questionable if enableing it at all is good idea | 20:24 |
| uvos | the n900s cpu is really slow, im not sure it needs the extra work | 20:25 |
| uvos | Wizzup: i think "find /proc/sys/net/ -name interval_probe_time_ms | xargs -I% sh -c 'echo -1 > %'" helps a bit | 20:26 |
| uvos | as suggested by tmlind | 20:26 |
| Wizzup | ac_laptop: 512 would be sensible | 20:27 |
| uvos | we could also try setting net.ipv4.neigh.default.interval_probe_time_ms in systctl.d | 20:27 |
| Wizzup | uvos: ah, yes, I think tmlind also mentioned that | 20:27 |
| Wizzup | uvos: see https://github.com/maemo-leste/bugtracker/issues/704 | 20:28 |
| uvos | Wizzup: yeah "as suggested by tmlind" :) | 20:28 |
| Wizzup | if you can make a PR for leste-config for this, that would be great | 20:28 |
| uvos | Wizzup: i think doing it in sysctl is better | 20:28 |
| Wizzup | yes | 20:28 |
| Wizzup | sysctl.d more specifically | 20:28 |
| Wizzup | I think we already have some files there, yeah? | 20:28 |
| uvos | yes | 20:28 |
| uvos | but i have to check if setting just net.ipv4.neigh.default.interval_probe_time_ms works | 20:29 |
| uvos | first | 20:29 |
| uvos | as long as its set before the interfaces are set up it should iiuc | 20:29 |
| Wizzup | brb work mtg | 20:30 |
| ac_laptop | Wizzup, uvos: who should I trust ? :) | 20:43 |
| uvos | ac_laptop: forget about zram, swap on sd/emmc :) | 20:52 |
| freemangordon | right, zram on n900 does more harm than good | 20:52 |
| freemangordon | if there is any good at all | 20:52 |
| freemangordon | arno11: So the only option to improve rendering performance on n900 is DRI3 | 21:00 |
| freemangordon | BTW, I wonder why with omapfb it was faster | 21:01 |
| ac_laptop | wow leste looks *significantly* faster with this new U3 card o_O | 21:02 |
| ac_laptop | dunno if it's U3 or just the quality of the card but the difference is perceptible | 21:03 |
| arno11 | freemangordon: ok, so is there any additional stuff to install or we have just to add it as an option in Device section (in omap.conf) | 21:14 |
| arno11 | ? | 21:14 |
| freemangordon | no, we have to implement support for it in DDX :) | 21:16 |
| freemangordon | or switch to modesetting | 21:16 |
| freemangordon | uvos: hmm... https://gitlab.freedesktop.org/xorg/xserver/-/commit/e573d4ca03756cd7ea37288a7ca7df003ad5c1f8 | 21:16 |
| freemangordon | seems gles2 has finally received some love | 21:18 |
| freemangordon | maybe it makes sense to try ms/glamor again | 21:18 |
| freemangordon | uvos: no idea what's going on, but in the last month there is merged code that was sitting there for years, see https://gitlab.freedesktop.org/xorg/xserver/-/commit/0076671e24670f1ddb151946e490497f171589f0 for example | 21:31 |
| freemangordon | I will definitely git it a shot when I have some spare time | 21:32 |
| freemangordon | *give | 21:35 |
| arno11 | freemangordon: (for DDX) ok, is it complicated to implement ? | 21:49 |
| norayr | very hard to deal with rust softawer. especially when it wants newer crates etc. i tried to package some crates but they want newer compiler... | 21:55 |
| freemangordon | arno11: yes | 21:56 |
| arno11 | ok | 21:56 |
| freemangordon | I would rather try modesetting with glamor | 21:56 |
| arno11 | when you say modesetting you mean KMS ? | 21:57 |
| freemangordon | I mean modesetting DDX | 21:58 |
| freemangordon | https://man.archlinux.org/man/modesetting.4 | 21:58 |
| freemangordon | for example | 21:58 |
| arno11 | ah ok | 21:59 |
| freemangordon | what the? https://gitlab.freedesktop.org/StaticRocket/mesa/-/commits/powervr/kirkstone/22.3.5/?ref_type=heads | 22:58 |
| uvos | perparing to port the new foss pvr rouge code down to sgx? | 23:03 |
| uvos | sounds neat if true | 23:03 |
| freemangordon | uvos: or rather open-sourcing pvr mesa code (the one I re-ed :) ) | 23:11 |
| freemangordon | but seems to be compatible with new mesa | 23:12 |
| uvos | so deleating tracker state and letting it settle for several hours dosent help | 23:32 |
| uvos | the mafw tracker is still using a huge amount of cpu time preventing the device from sleeping | 23:32 |
| uvos | ill try to figure out what its doing tomorrow | 23:32 |
| freemangordon | uvos: mafw != tracker | 23:37 |
| uvos | yeah its gnomes tracker | 23:37 |
| uvos | i know | 23:37 |
| uvos | its used by mafw however | 23:38 |
| freemangordon | there is mafw-tracker-source, but it is merely wrapping tracker | 23:38 |
| freemangordon | yeah | 23:38 |
| freemangordon | It seems tracker has issues | 23:38 |
| freemangordon | I had to fork it already | 23:38 |
| uvos | what dosent have issues | 23:39 |
| freemangordon | FYI https://github.com/maemo-leste-upstream-forks/tracker-miners/commit/0ac3ba4e88b38d2d006286a34cf6c72da9311409 | 23:39 |
| uvos | yeah i saw that | 23:39 |
| uvos | pretty silly | 23:39 |
| freemangordon | also, TI repo has new sgx binaries | 23:40 |
| freemangordon | https://git.ti.com/cgit/graphics/omap5-sgx-ddk-um-linux/log/?h=1.17.4948957/mesa/glibc-2.35 | 23:41 |
| sicelo | looks like i finally got my ofono patch working, https://paste.debian.net/1298261/ | 23:53 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!