| Wizzup | tmlind: fyi I booted 5.15.6 with no patches applied, just watchdog built in and I got the same panic right away | 11:18 |
|---|---|---|
| Wizzup | https://dpaste.com/FQ6QALNAE.txt | 11:19 |
| Wizzup | when I wrote 'just watchdog built in' I mean omap2plus_defconfig and then: | 11:20 |
| Wizzup | sed -i 's/CONFIG_OMAP_WATCHDOG=m/CONFIG_OMAP_WATCHDOG=y/' .config | 11:21 |
| Wizzup | sed -i 's/CONFIG_TWL4030_WATCHDOG=m/CONFIG_TWL4030_WATCHDOG=y/' .config | 11:21 |
| Wizzup | make -j16 ARCH=arm CROSS_COMPILE=armv7a-hardfloat-linux-gnueabi- oldconfig | 11:21 |
| Wizzup | The panic happens basically as soon as /sbin/init is started it seems | 11:22 |
| mighty17[m] | uvos: `gp2ap002 3-0044: read 70 mA from ADC` yay!! | 11:30 |
| uvos | mighty17[m]: what was the problem? | 11:30 |
| mighty17[m] | dont really know, added #define DEBUG and got the dmesg of driver being loaded | 11:31 |
| uvos | hmm | 11:31 |
| mighty17[m] | seems like driver was looking for adc channels before they were being loaded and causes -517, now with debugs i can confirm that gpadc and gp2a works (partially) | 11:31 |
| uvos | there is still something worn with the adc | 11:31 |
| uvos | if you cant read any of the other channels via sysfs | 11:32 |
| uvos | *wrong | 11:32 |
| mighty17[m] | i can read all other channels as well now :D | 11:32 |
| bencoh | mighty17[m]: you should probably use -EDEFER | 11:32 |
| uvos | yeah | 11:32 |
| uvos | its obv a race | 11:32 |
| uvos | and debug is slowing it down | 11:32 |
| mighty17[m] | https://github.com/torvalds/linux/blob/v5.15/drivers/iio/light/gp2ap002.c#L508 kinda weird driver | 11:33 |
| uvos | its before that | 11:33 |
| uvos | the adc is broken even when you dont have gp2ap loaded at all no> | 11:34 |
| uvos | so the adc needs to probe after something | 11:34 |
| adc | yes, i do | 11:34 |
| mighty17[m] | whoops | 11:34 |
| bencoh | ohnoes, an adc! it talks! | 11:34 |
| adc | :D | 11:34 |
| uvos | "the adc is broken even when you dont have gp2ap loaded at all no" | 11:34 |
| uvos | this is true right? | 11:34 |
| mighty17[m] | uvos: no, i think the adc works fine now | 11:34 |
| adc | haha | 11:34 |
| mighty17[m] | probably some twl6030 and 6032 madness | 11:34 |
| mighty17[m] | i removed gpadc from twl6030 and it works now :P | 11:35 |
| mighty17[m] | but still now the sensor isnt working, i think it needs interrupt for proixmity as well but looks like it clashes with sdmmc2 pins | 11:36 |
| * mighty17[m] uploaded an image: (13KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/egtGkZtSgEYQcXTaFSqNZxCl/image.png > | 11:36 | |
| * mighty17[m] uploaded an image: (13KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/YmVvtKQxMKUcYXfsLflCUTOM/image.png > | 11:36 | |
| Wizzup | tmlind: hm same on 5.10.84 | 11:38 |
| * Wizzup really wondering wth is up | 11:38 | |
| Wizzup | surely it can't just be broken for that long | 11:39 |
| uvos | dunno why not | 11:39 |
| Wizzup | so either you were right and this particular n900 has trouble or the defconfig doesn't work for the rootfs | 11:39 |
| Wizzup | uvos: other folks do ocassionally use it | 11:39 |
| Wizzup | let me try linux-5.7.y | 11:39 |
| uvos | yeah but everyone has trouble and writes custom defconfigs | 11:39 |
| uvos | some omap in soc device driver might be causing this | 11:40 |
| Wizzup | whatever it is, it's not a module | 11:41 |
| Wizzup | it fails before it even loads a module | 11:41 |
| Wizzup | see the trace | 11:41 |
| uvos | ok | 11:41 |
| uvos | yeah i see | 11:41 |
| uvos | defconfig change dosent have to touch a module ofc | 11:41 |
| Wizzup | https://dpaste.com/AR4E99WES.txt | 11:41 |
| uvos | maybe try pmos's config | 11:41 |
| Wizzup | uvos: let me try 5.7 frst | 11:41 |
| uvos | ofc your n900 being broken is possible too, you have several no? | 11:42 |
| Wizzup | yes | 11:42 |
| Wizzup | but it seems to be odd timing so I don't buy that yet | 11:42 |
| Wizzup | If 5.7 also is borked then I will try other n900s | 11:42 |
| Wizzup | or perhaps the new u-boot is somehow making it sad | 11:43 |
| Wizzup | (next level annoyance) | 11:43 |
| uvos | yeah thats possible too | 11:43 |
| uvos | hw initalization state might be different | 11:43 |
| bencoh | that sounds likely even | 11:43 |
| uvos | yeah | 11:43 |
| bencoh | where does it fetches rootfs from? nand? nor? usb? | 11:43 |
| uvos | would make sense with fmg not having problems | 11:43 |
| uvos | he used umiage with old uboot | 11:43 |
| Wizzup | bencoh: rootfs is sdcard | 11:44 |
| bencoh | ah | 11:44 |
| Wizzup | uvos: he also had trouble but iirc that was perhaps just watchdog related | 11:44 |
| Wizzup | anyway let's not jump to conclusions, I'll try the older u-boot after 5.7 if it doesn't work | 11:44 |
| bencoh | Wizzup: does uboot fetches an initramfs from sdcard and copies it to RAM, or does the kernel uses some partition as root= ? | 11:44 |
| uvos | latter | 11:45 |
| Wizzup | sdcard | 11:45 |
| Wizzup | just root= | 11:45 |
| Wizzup | no initramfs | 11:45 |
| Wizzup | and the dtb is attached atm still | 11:45 |
| bencoh | hmm, a uboot issue is a bit less likely then | 11:45 |
| bencoh | since the kernel should init the sdcard from scratch | 11:45 |
| Wizzup | well the trouble starts when /sbin/init is loaded, idk if that means fs access or something else | 11:45 |
| Wizzup | but it can also happen later depending on the stance of the moon :) | 11:46 |
| uvos | uboot providing a different hw state might make the kernel trip over some previously masked bug it had | 11:46 |
| Wizzup | yeah | 11:46 |
| bencoh | uvos: yeah, it still sounds likely, just less than what I had in mind at first | 11:46 |
| bencoh | (s/likely/possible/ at least) | 11:48 |
| Wizzup | 5.7 seems immune to the problem so far | 11:53 |
| Wizzup | 5.7 idles at 0.11A with 3.8V in off mode at least :) | 11:55 |
| Wizzup | (without addition off mode changes) | 11:56 |
| Wizzup | addional* | 11:57 |
| Wizzup | anyway -- separate issue... | 11:57 |
| uvos | thats terrible no? | 11:57 |
| bencoh | yeah | 11:57 |
| bencoh | :) | 11:57 |
| uvos | worse than d4 in ret :P | 11:57 |
| Wizzup | sorry I mistyped again | 11:57 |
| Wizzup | 0.011A | 11:57 |
| bencoh | oh | 11:57 |
| uvos | ok | 11:57 |
| uvos | more like it | 11:57 |
| bencoh | that's better | 11:57 |
| Wizzup | it's a bit better than d4 | 11:57 |
| bencoh | (still 3x than fremantle, but heh :) ) | 11:58 |
| bencoh | (make it 4) | 11:58 |
| Wizzup | that'll be fun to debug for sure | 11:58 |
| bencoh | what, the rootfs/whatever issue on > 5.7 kernels? | 11:59 |
| Wizzup | I've booted 7 times now and haven't seen it yet | 11:59 |
| Wizzup | on 5.10 and 5.15 I hit it basically right away (but also not always) | 11:59 |
| Wizzup | this is on the stable branches of both though | 11:59 |
| Wizzup | not sure if I can bisect two stable branches | 11:59 |
| uvos | as long as n900 has no other bugs between 5.7 and 5.10 it should not be too hard to automate. | 12:01 |
| uvos | use the n900 debug kit to check on serial if it booted, power cycle the lab supply vi rs232 if it dident | 12:02 |
| Wizzup | uvos: except that I need to take out the sd card every time ;) | 12:02 |
| Wizzup | well, for every kernel | 12:02 |
| uvos | Wizzup: not really | 12:03 |
| uvos | uboot can load the kernel via usb or? | 12:03 |
| Wizzup | not sure | 12:03 |
| Wizzup | but it also stays powered over usb | 12:03 |
| bencoh | with DFU and a power-controlled usb hub it would work | 12:04 |
| Wizzup | I think with a bit of luck I can just do it somewhere today | 12:04 |
| Wizzup | but yes automation would be good | 12:04 |
| Wizzup | I was hoping to get one of those breakout microsd cards or something | 12:05 |
| Wizzup | https://opencircuit.shop/Product/MicroSD-card-breakout-board-plus | 12:05 |
| Wizzup | wait that's not it :) | 12:05 |
| sicelo | Wow @ 5.7 off mode | 12:05 |
| Wizzup | so does it make sense to do a git bisect between two stable branches? | 12:11 |
| uvos | not really, but i suspect 5.7.0 and 5.10.0 would show the same issues or? | 12:13 |
| Wizzup | maybe | 12:14 |
| Wizzup | I can try that then | 12:14 |
| Wizzup | btw: https://linux-automation.com/en/products/usb-sd-mux.html | 12:14 |
| Wizzup | damn they ask 90 euro lol | 12:14 |
| uvos | Wizzup: using uboots ability to load the kernel from tftp makes more sense no? | 12:15 |
| Wizzup | uvos: do you mean tftp over usb somehow? | 12:16 |
| Wizzup | I don't know if that works really | 12:16 |
| uvos | Wizzup: yeah | 12:16 |
| Wizzup | we'd have to work on u-boot and musb first | 12:16 |
| uvos | Wizzup: i dont either but it looks like everthing is there | 12:16 |
| uvos | dident musb work> | 12:16 |
| uvos | ? | 12:16 |
| uvos | looks like uboot can also load the kernel over uart | 12:18 |
| uvos | altho loading the 115200 is not going to be fun | 12:18 |
| uvos | *kernel | 12:18 |
| Wizzup | musb never really works :P | 12:19 |
| Wizzup | there is serial over usb and I think maybe it can do file transfer | 12:19 |
| Wizzup | I think pali tried that with latest u-boot | 12:19 |
| Wizzup | so that could potentially work | 12:19 |
| Wizzup | but that on its own is probably as much work as bisecting this by hand | 12:19 |
| Pali | it acts as normal serial device | 12:20 |
| Pali | so you can do file transfers | 12:20 |
| Wizzup | right | 12:20 |
| Pali | u-boot supports xmodem, ymodem and kermit | 12:20 |
| uvos | using kermit dosent look to hard | 12:20 |
| Pali | in u-boot run command: loadb | 12:20 |
| Pali | and then start kermit file transfer application | 12:21 |
| Pali | gkermit works fine | 12:21 |
| Wizzup | ok | 12:21 |
| Wizzup | I guess I'll need to figure out modules still | 12:21 |
| uvos | just build it static maybe | 12:22 |
| Pali | note that speed is limited by usb itself... this terminal is not speed-capable, so you cannot set e.g. speed 115200 | 12:22 |
| uvos | (if a static 5.10.0 kernel has same issue) | 12:22 |
| Wizzup | uvos: yes, but unfortunately even that can currently lead to other problems | 12:22 |
| uvos | no doubt | 12:22 |
| Wizzup | I'd rather fix this first | 12:22 |
| Wizzup | then look at no module builds | 12:22 |
| Wizzup | Pali: check | 12:23 |
| Wizzup | brb | 12:23 |
| uvos | i gues another option is using the trick i use when bisecting d4 | 12:26 |
| uvos | i just boot a known good kernel and scp over the test kernel and kexec it | 12:26 |
| Wizzup | uvos: so I think 5.7.0 has problems with detecting the sd card because of this card detect nonsense | 12:53 |
| Wizzup | maybe that was merged earlier and this is yet another unrelated issue | 12:54 |
| Wizzup | yeah that got into 5.4 | 12:55 |
| Wizzup | oh, the mmc numbering is different in 5.7 compared to 5.7.y | 12:56 |
| * Wizzup flips table | 12:57 | |
| uvos | all of this is good reason to get uboot kermit automated testing to work | 13:01 |
| uvos | so we can have a n900 in the debug kit at all times tracking master. | 13:01 |
| uvos | but yeah looks like a total mess for you | 13:01 |
| uvos | maybe manually bisect manually and try 5.8 and see if that boots :P | 13:02 |
| Wizzup | ok so no I was wrong, the order didn't change, it just doesn't find the sd card | 13:02 |
| Wizzup | yeah going to try 5.8 first, maybe it doesn't have this problem | 13:02 |
| uvos | i seam to remembner something like that yeah | 13:02 |
| Wizzup | and yes, this is a reason to have ci/automated testing | 13:03 |
| uvos | 5.8 was a golden kernel on d4 - absolutly no issues :P | 13:03 |
| Wizzup | lol | 13:03 |
| Wizzup | https://shop.pimoroni.com/products/microsd-extension-cable maybe something like this is useful as well | 13:05 |
| Wizzup | 5.8 seems to boot as well | 13:19 |
| Wizzup | still has a ton of drm backtraces, but I guess it was just really broken then | 13:19 |
| Wizzup | same for 5.9; but that doesn't hit off mode | 13:45 |
| Wizzup | (didn't check 5.8 for fof mode) | 13:45 |
| Wizzup | tmlind: hmm 5.10 (no stable patches applied) also has oops that looks very much like the one we're seeing in 5.10.y and 5.15.y - https://dpaste.com/G3LLXJBTX.txt | 14:11 |
| Wizzup | but it might not be the same, so that will make the bisect quite annoying :( | 14:11 |
| Wizzup | tmlind: what about 0a27398d8969f0def188ab46f932ea1366874bd4 ? | 14:13 |
| Wizzup | that is ec76c2eea903947202098090bbe07a739b5246e9 upstream | 14:14 |
| Wizzup | tmlind: hm on top of v5.10 I tried to revert 21b2cec61c04bd175f0860d9411a472d5a0e7ba1 (the commit that ec76c2eea903947202098090bbe07a739b5246e9 tries to fix) and when I do that I get the same oopses as I get on 5.10.y and 5.15.y | 14:20 |
| Wizzup | tmlind: also, your test setup, does it use sd cards? | 14:35 |
| Wizzup | hm, looks like v5.9 ... v5.10 diff also has a commit that enables off mode automatically | 14:56 |
| Wizzup | ok, getting closer | 15:05 |
| bencoh | do you think your issue is related to off mode? | 15:07 |
| bencoh | if so you could disable the idle state(s) | 15:08 |
| bencoh | and see if it fixes it | 15:08 |
| Wizzup | I emailed linux-omap with some info | 15:10 |
| Wizzup | the problem is not ec76c2eea903947202098090bbe07a739b5246e9 | 15:10 |
| Wizzup | It looks like it was introduced between v5.9 and v5.10 though, but if I bisect that I'll have to revert another commit all the time that causes another regressi | 15:11 |
| Wizzup | on | 15:11 |
| Wizzup | I suppose that's feasible, just not sure if that's standard practice | 15:11 |
| uvos | Wizzup: sure git bisect has a option to carry a patch for you | 15:17 |
| uvos | hopefully your commit is non invasive | 15:18 |
| Wizzup | this being a race and all I might be unlucky but reverting fb2c599f056640d289b2147fbe6d9eaee689f1b2 on top of v5.10 (with the other regression reverted as well) makes the boot problem go away | 15:19 |
| uvos | sure | 15:20 |
| uvos | might also happen at any point during the bisect | 15:21 |
| uvos | causeing false bad commits | 15:21 |
| Wizzup | I didn't do a bisect | 15:21 |
| Wizzup | I just took v5.10 and figured that commit might cause the problem | 15:22 |
| Wizzup | so I reverted it.. | 15:22 |
| Wizzup | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fb2c599f056640d289b2147fbe6d9eaee689f1b2 maybe the PWRDM change | 15:25 |
| Wizzup | going to try our 5.15 with pvr again, with this patch reverted | 15:25 |
| Wizzup | uvos: btw the 0.011A is reported should be 0.007A since the serial module uses 0.004A when idle | 15:31 |
| Wizzup | that is the board that I got from tony | 15:32 |
| Wizzup | but yeah | 15:32 |
| bencoh | I was wrong about fremantle being 3x better battery-wise btw, I thought that bq scripts reported in mW, but it shows mA as well ... so I get | 15:43 |
| bencoh | 8~12mA when idling | 15:43 |
| Wizzup | right, my test was with init=/bin/sh | 15:43 |
| bencoh | (modem on) | 15:43 |
| Wizzup | so it's not quite comparable | 15:44 |
| bencoh | ah | 15:44 |
| Wizzup | I can try to fire up fremantle later | 15:44 |
| Wizzup | bencoh: if we were hitting OFF modem and 0.007A with leste and UI I'd be buying beers now and get drunk tonight ;) | 15:44 |
| Wizzup | 0.07A* | 15:44 |
| bencoh | :D | 15:44 |
| Wizzup | (not sure why I keep mistyping this) | 15:44 |
| bencoh | ah | 15:44 |
| bencoh | so 70mA? | 15:44 |
| Wizzup | 0.007A sorry :( | 15:45 |
| bencoh | :D | 15:45 |
| Wizzup | hehe | 15:45 |
| bencoh | you should just move to mA | 15:45 |
| bencoh | for idle it makes more sense | 15:45 |
| Wizzup | yeah | 15:45 |
| bencoh | (even for non-idle states actually) | 15:46 |
| Wizzup | I should just connect the power supplies to my laptop again and use my tools | 15:47 |
| Wizzup | better then doing mental calculations when distracted | 15:47 |
| bencoh | :) | 15:47 |
| Wizzup | decisive minute incoming... :) | 15:48 |
| Wizzup | lol, tklock keeps waking up in idle | 15:50 |
| bencoh | hmm | 15:50 |
| bencoh | I | 15:50 |
| Wizzup | in any case, I am pretty confident that reverting fb2c599f056640d289b2147fbe6d9eaee689f1b2 makes the problems go away! | 15:51 |
| bencoh | I'm pretty certain it doesn't on fremantle, and iirc it was REed | 15:51 |
| bencoh | anyway, nice :) | 15:51 |
| bencoh | well, "nice" that you found it ... the fact that it doesn't work is kinda sad | 15:52 |
| Wizzup | I don't think it means that OFF mode doesn't work | 15:53 |
| Wizzup | we can hit it just fine in init=/bin/sh | 15:53 |
| Wizzup | I think there is some other interaction that makes things go bad | 15:53 |
| Wizzup | maybe the PWRDM change Andreas made | 15:53 |
| Wizzup | see https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/ | 15:53 |
| bencoh | hm | 15:53 |
| Wizzup | arh.. | 15:53 |
| Wizzup | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fb2c599f056640d289b2147fbe6d9eaee689f1b2 | 15:53 |
| bencoh | the commit itself is quite simple :) | 15:54 |
| bencoh | but it could be interactions with other components yeah (pvr?) | 15:54 |
| Wizzup | no, it's not with powervr for sure | 15:56 |
| Wizzup | all my testing was without powervr | 15:57 |
| Wizzup | 5.7,5.8,5.9,5.10,5.10.y,5.15.y - tried all without powervr | 15:57 |
| uvos | for all the pvr bashiing we do pvr_k so far has really not been the cause of any issues. | 15:58 |
| Wizzup | hehe | 15:59 |
| bencoh | :) | 15:59 |
| Wizzup | freemangordon: btw I think maybe the d4 resource crash is because of rotation, maybe try to do some automated rotation test | 16:00 |
| Wizzup | freemangordon: just a hunch though | 16:00 |
| bencoh | you could spawn "stress" commands with various random arguments (cpu/io/vm) for random period of times and add sleeping periods in between to try to reproduce the issue with init=/bin/sh | 16:00 |
| bencoh | (for instance) | 16:00 |
| Wizzup | what problem is this exactly? | 16:00 |
| bencoh | ? | 16:00 |
| Wizzup | bencoh: so I don't know why this commit causes the problems, but I know that we already hit off mode on n900 in init=/bin/sh ... ah I see, you're suggesting that it only happens in OFF mode and some interactions | 16:01 |
| bencoh | that's more or less what you suggested as well | 16:01 |
| bencoh | so trying to simulate various loads from a single-user shell might help reproducing it | 16:02 |
| Wizzup | well, I am not sure if the problem still exists with this commit reverted | 16:02 |
| bencoh | (basically forcing idle transations with various load patterns) | 16:02 |
| Wizzup | it manifested itself even without off mode ever being hit on leste UI | 16:02 |
| Wizzup | and it enabled it based on some dts compatible entry | 16:02 |
| bencoh | I mean, keep the patch in, boot to single-user shell | 16:02 |
| bencoh | and try to make the issue appear | 16:03 |
| bencoh | ah | 16:03 |
| Wizzup | so it's possible that the PWRDM change is simply what causes the problems | 16:03 |
| Wizzup | I'll wait for Andreas/Tony to comment first, I can continue with my stuff with this commit reverted | 16:03 |
| Wizzup | so next thing: with /etc/init.d/n900-powermanagement start, gpio_keys falsely reports slide changes | 16:04 |
| Wizzup | https://dpaste.com/A3HDEQ3VS | 16:05 |
| Wizzup | # sleep 5; /etc/init.d/n900-powermanagement status | 16:09 |
| Wizzup | d=2021-12-08|t=17:09:24|i=OFF:0,RET:0|p=731|c=NA|b=ST_SDRC,ST_OMAPCTRL | 16:09 |
| Wizzup | lame... :-) | 16:09 |
| Wizzup | no more blockers, but also no RET/OFF | 16:09 |
| Wizzup | oh | 16:09 |
| Wizzup | (ke-recv was 'busy') | 16:10 |
| dsc_ | is there a file manager for maemo? | 16:41 |
| sicelo | Wizzup: in your mail, "PS: Nikolaus - might be worth getting that N900 going some time soon. ;-)" ... i guess you meant Sebastian? :) | 16:41 |
| Wizzup | no | 16:41 |
| Wizzup | Nikolaus reached out last week saying he had a n900 and asked how to set it up | 16:42 |
| Wizzup | dsc_: there is a proprietary one that freemangordon said he would RE, and there's a qt one called 'hamsterfiler' | 16:42 |
| Wizzup | we haven't ported the qt one yet | 16:42 |
| sicelo | ah, ok | 16:42 |
| * sicelo wonders why suddenly he doesn't get linux-omap emails on his inbox | 16:42 | |
| Wizzup | sicelo: nikolaus emailed off list | 16:43 |
| uvos | dsc_: we also have liri-files | 16:43 |
| bencoh | sicelo: too many bounces maybe | 16:43 |
| Wizzup | sicelo: I just CC'd sre because I thought he wanted to know since I mentioned this in the modem email | 16:43 |
| uvos | dsc_: works farily fine on mapphone | 16:43 |
| sicelo | i have to re-check the subscription. maybe it went into digest mode or something | 16:43 |
| Wizzup | sicelo: plus when he mailed me he included andreas (who authored the commit that caused the regression) | 16:43 |
| Wizzup | so I figured it'd make sense to loop them in | 16:44 |
| uvos | http://uvos.xyz/maserati/screenshots/2020-06-17-200351_960x540_scrot.png | 16:44 |
| uvos | upps | 16:45 |
| bencoh | oops indeed | 16:45 |
| uvos | i think this happens every year :P | 16:45 |
| bencoh | :] | 16:45 |
| Wizzup | lol | 16:45 |
| dsc_ | $ liri-files | 16:46 |
| dsc_ | QQmlApplicationEngine failed to load component | 16:46 |
| dsc_ | qrc:/qml/main.qml:24 module "Fluid.Controls" is not installed | 16:46 |
| dsc_ | :> | 16:46 |
| uvos | dsc_: hmm | 16:46 |
| uvos | dsc_: upps again | 16:46 |
| uvos | dsc_: apt search liri fluid | 16:46 |
| dsc_ | ah | 16:46 |
| uvos | dsc_: theres a package for that | 16:46 |
| uvos | should be in depends ofc | 16:46 |
| dsc_ | yeah `liri-fluid` specifically | 16:47 |
| uvos | http://185.53.129.145/maserati/screenshots/2020-06-17-200351_960x540_scrot.png | 16:47 |
| dsc_ | yeah I'm running it currently, looks pretty good! | 16:47 |
| Wizzup | it doesn't follow the maemo theme, but yeah, that's a common qml problem I think | 16:47 |
| uvos | right and the liri stuff explicitly apes android | 16:48 |
| dsc_ | missing some stuff like "open" | 16:48 |
| uvos | not sure what you mean by open | 16:49 |
| uvos | it uses xdg-open to open anything you click on | 16:49 |
| dsc_ | Unable to detect a launcher for 'file:///home/user/conversations/README.md' | 16:50 |
| dsc_ | ah k | 16:50 |
| dsc_ | no mime handler for that or whatever | 16:50 |
| Wizzup | probably | 16:50 |
| dsc_ | might make my own file explorer with QtWidgets | 16:55 |
| uvos | the qt maemo one exists | 16:55 |
| dsc_ | no reason for this to be QML and also kinda seems like it is targetted towards desktop usage idk we'll see | 16:55 |
| Wizzup | maybe look at hamster filter | 16:55 |
| uvos | might be easier to port | 16:56 |
| Wizzup | http://maemo.org/packages/view/hamsterfiler/ | 16:56 |
| dsc_ | ah | 16:56 |
| dsc_ | well yeah thats some gtk stuff most likely | 16:57 |
| dsc_ | ah no, Qt | 16:57 |
| dsc_ | alright ill take a looksie | 16:58 |
| bencoh | yeah, I was quite certain it was a gtk-one as well | 16:58 |
| bencoh | gtk app* | 16:58 |
| bencoh | it's very lean/fast/nice imo :) | 16:58 |
| dsc_ | apparently Qt :) | 16:59 |
| bencoh | ueaj | 16:59 |
| bencoh | yeah* | 16:59 |
| Wizzup | I haven't used hamsterfiler yet | 16:59 |
| bencoh | I hardly use any file browser anyway, but it's cool | 16:59 |
| uvos | btw gnome files also works pretty well | 17:00 |
| uvos | if something is needed immiatly | 17:00 |
| dsc_ | yeah its not super important but i'm hyped @ the prospect of creating apps for my future linux mobile phone | 17:00 |
| bencoh | :) | 17:01 |
| uvos | then again it wont work without https://github.com/maemo-leste/libmatchbox2/pull/8 | 17:01 |
| uvos | ahem | 17:01 |
| dsc_ | my droid 4 magically started working... nice | 17:02 |
| bencoh | wait, I thought qt/gtk wer efine with it? | 17:02 |
| bencoh | were* fine with the WM_HINTS thing | 17:03 |
| bencoh | or is that just because they were patched on fremantle? | 17:03 |
| uvos | this is something else entirely | 17:03 |
| bencoh | ah | 17:03 |
| bencoh | nevermind then | 17:03 |
| uvos | windows that are csd get renderd at fullscreen resolution | 17:03 |
| uvos | but hildon still draws the bar on top | 17:03 |
| uvos | makeing things unusable | 17:03 |
| freemangordon | Wizzup: so, reverting off mode patch fixes it? | 17:08 |
| freemangordon | and even with that patch reverted we still hti off mode? | 17:08 |
| Wizzup | freemangordon: yes | 17:10 |
| Wizzup | freemangordon: not with h-d and full leste booted, but with minimal env | 17:10 |
| freemangordon | hmm | 17:10 |
| Wizzup | I suspect the powerdomain change as I stated before, but maybe it just masks another issue | 17:11 |
| bencoh | wait, how do you get OFF mode without the patch? | 17:11 |
| dsc_ | maybe ill create an app that decorates your desktop with daily cute animals (options for cat/bunny/dogs) | 17:11 |
| freemangordon | yeah | 17:11 |
| Wizzup | bencoh: via debugfs | 17:11 |
| dsc_ | (yes I'm bored) | 17:11 |
| bencoh | ah, nevermind :) | 17:11 |
| Wizzup | bencoh: see droid4-pm and n900-pm repos | 17:11 |
| freemangordon | dsc_: you know h-h supports animated(video) wallpapers? | 17:11 |
| bencoh | ohnoes :D | 17:12 |
| dsc_ | freemangordon: interesting, it plays .mp4 in a loop? | 17:12 |
| dsc_ | great for battery life! | 17:12 |
| freemangordon | not sure about what format it requires | 17:12 |
| dsc_ | ok thanks | 17:12 |
| freemangordon | dsc_: I think this is called "Live Wallpaper" | 17:13 |
| freemangordon | Wizzup: anyways, I am too busy ATM with RL job, hopefully next week things will get better | 17:15 |
| Wizzup | freemangordon: all good, I think I can continue with this commit reverted | 17:15 |
| uvos | freemangordon: heh, android has these too since 2009/2.0 i think | 17:15 |
| Wizzup | freemangordon: the point was to have pvr on 5.15 on n900 | 17:15 |
| uvos | freemangordon: never seen anyone use them outside of retail estabilshments | 17:15 |
| uvos | stupid things | 17:15 |
| dsc_ | :D | 17:15 |
| Wizzup | off mode is secondary, and this patch didn't improve it for us | 17:15 |
| Wizzup | dsc_: what about desktop widgets, those might be useful | 17:15 |
| Wizzup | we have a calendar widget for example | 17:16 |
| bencoh | iirc those were a battery hog on fremantle as well, unfortunately | 17:16 |
| Wizzup | but but animated matrix (the movie) backgrounds! | 17:16 |
| freemangordon | never used it, but is a nice feature to have | 17:17 |
| bencoh | but it's a cool idea | 17:17 |
| Wizzup | it could be nice for wall mounted tablets or something | 17:17 |
| freemangordon | https://talk.maemo.org/showthread.php?t=45728 | 17:17 |
| bencoh | I vaguely remember troubleshooting it years ago, and iirc the bottomline was that having desktop widgets prevented hildon from sleeping properly (ie it wokeup way more) | 17:18 |
| Wizzup | it depends on how the widget behaves I think | 17:18 |
| Wizzup | the calendar one is fine | 17:18 |
| uvos | also desktop command widget seams fine | 17:18 |
| bencoh | oh, the TMO/leste forum is getting some activity, nice :) | 17:19 |
| uvos | but the way the widgets work is _terrible_ imo | 17:19 |
| freemangordon | what is terrible about it? | 17:20 |
| uvos | having random packages load plugins into hildon-home is a bad idea form a reliablity perspective | 17:20 |
| bencoh | uvos: actually iirc I tried desktop command widget back then | 17:20 |
| uvos | and it forces a toolkit on the widgets | 17:20 |
| uvos | the widgets should just be embeded x windows | 17:20 |
| bencoh | (but heh, it was ... years ago) | 17:20 |
| uvos | or pixmaps the widget sends | 17:20 |
| freemangordon | oh, you force xorg | 17:20 |
| uvos | wayland has the same window embeding | 17:21 |
| uvos | and the toolkits abstract it | 17:21 |
| freemangordon | what about wayland? :P | 17:21 |
| uvos | so no | 17:21 |
| freemangordon | also, how is that going to work on windows? | 17:21 |
| uvos | should work on windows to | 17:21 |
| uvos | really | 17:21 |
| freemangordon | great | 17:21 |
| uvos | if you want | 17:21 |
| freemangordon | anyways, I am not in a mood to be productive :) | 17:22 |
| freemangordon | So lets not distract others at least | 17:22 |
| * freemangordon is afk | 17:22 | |
| dsc_ | anyway to get "the battery status" via terminal command? | 18:00 |
| dsc_ | or some other way to visually know what the battery charge is | 18:00 |
| Wizzup | yeah... this is a bit tricky | 18:01 |
| Wizzup | upower has the info, but mce also some | 18:01 |
| dsc_ | I'm hooked into USB power, so the battery icon will animate, but it wont actually show the charge | 18:02 |
| dsc_ | ah, thanks | 18:02 |
| Wizzup | calibration takes time | 18:02 |
| tmlind | Wizzup: so if reverting fb2c599f056640d289b2147fbe6d9eaee689f1b2 makes things behave, sounds like the system enters some idle mode during init before things are ready or something like that | 18:26 |
| tmlind | Wizzup: maybe try to enable off mode automatically only with a late_initcall? | 18:27 |
| Wizzup | tmlind: what do you mean, late initcall? do you mean through init script? | 18:28 |
| Wizzup | that works | 18:28 |
| tmlind | hmm well omap2_common_pm_late_init() is already late_initcall it seems and that ends up calling omap3_pm_init() | 18:30 |
| Wizzup | well, doing it through debugfs works ok | 18:30 |
| tmlind | maybe twl is not fully initialized at that point yet? | 18:30 |
| Wizzup | also this sometimes caused problems way later in the boot process, like 300s in | 18:31 |
| Wizzup | so I think there's something else that this commit is also affecting | 18:31 |
| Wizzup | maybe wrt module loading | 18:31 |
| tmlind | if twl4030_power_probe() has not completed before deeper idle states the regulator voltages will be all wrong for idle modes | 18:33 |
| Wizzup | sorry brb 15 mins | 18:33 |
| uvos | dsc_: cat /sys/class/power_supply/battery/voltage_now | 18:47 |
| dsc_ | uvos: dir `/sys/class/power_supply/` is empty | 18:51 |
| uvos | what device? | 18:51 |
| dsc_ | d4 | 18:51 |
| uvos | cat /proc/modules | grep cpcap ? | 18:51 |
| uvos | something is very wrong on your device | 18:51 |
| dsc_ | no 'cpcap' | 18:52 |
| uvos | dmesg please | 18:52 |
| uvos | so no cpcap_battery cpcap_charger? | 18:53 |
| dsc_ | sorry.. wrong terminal, that was QEMU /me changes hostname | 18:53 |
| uvos | lol | 18:54 |
| dsc_ | voltage_now = 3870000 | 18:54 |
| uvos | right you can use the voltage to estimate charge | 18:54 |
| dsc_ | ok hehe | 18:54 |
| Wizzup | uvos: anything you want me to test on pp? | 21:17 |
| Wizzup | -experimental mesa works on PP | 21:24 |
| Wizzup | we should probably try the new X release, see if modesetting gets any better | 21:24 |
| Wizzup | freemangordon: you had tried to build a new X, right? | 23:29 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
