| Wizzup | do we still need our own upower fork? | 00:01 |
|---|---|---|
| Wizzup | We seem to have it for longer history and for better avg power | 00:01 |
| Wizzup | ( https://github.com/maemo-leste-upstream-forks/upower/commits/maemo/beowulf ) | 00:01 |
| Wizzup | (we need to decide this to have mce in upower) | 00:01 |
| buZz | i think freemangordon is already waiting for upstream upower to merge some stuff? | 00:13 |
| Wizzup | sure, but we'll need more. | 00:18 |
| Wizzup | we actually have a lot of upower patches: https://github.com/maemo-leste-upstream-forks/upower/commits/maemo/beowulf | 00:25 |
| buZz | yeah thats a lot | 01:08 |
| Wizzup | most are necessary ;) | 01:13 |
| buZz | i doubt many will go upstream, like the systemd one | 02:00 |
| buZz | so maybe our own fork will just stay needed | 02:00 |
| freemangordon | hmm, I did nothing in upower | 07:16 |
| freemangordon | Wizzup: I think we shall try upower with no patches | 07:34 |
| freemangordon | at least SOC estimation that was implemented there is worse than nothing IMO | 07:35 |
| freemangordon | I had occasional shutdowns because of low battery while applet was reporting 30%-40% or something | 07:36 |
| sicelo | iirc vanilla upower has issues on at least D4 and N900. For N900, the issue exists while battery is not calibrated. i forget exact details, but it's probably that there's no LMD in that case, and it throws upower off | 07:41 |
| sicelo | something similar happens with D4 ... although I haven't used vanilla in a long time there, so I forget exact details now | 07:42 |
| freemangordon | sicelo: ok, we may carry some of the patches, if needed. however, I think all those were done when we were on ascii | 07:45 |
| SuperMarioSF | so i am doing recalibration on battery, I removed the file for full charge capacity for old battery is this correct? | 07:49 |
| sicelo | freemangordon: i am trying to get mtdoops working for capturing the kernel hang due to N900 modem. so far i'm not very successful. do you perhaps know how to make it work? i added `mtdoops.mtddev=log` to the cmdline | 08:04 |
| freemangordon | yep, that should work | 08:39 |
| freemangordon | but, I think you need onenand drivers enabled as well | 08:39 |
| freemangordon | uvos: https://pastebin.com/wtqL02hA | 08:40 |
| freemangordon | calculated Ri, every 30 seconds | 08:40 |
| freemangordon | no filtering whatsoever, just 10 samples, sorted, so lowest and highest are used | 08:41 |
| freemangordon | code itself https://pastebin.com/ySq4dFGA | 08:42 |
| uvos | freemangordon: that looks like the right range values wise | 09:47 |
| uvos | it bounces around alot ofc, but i expect some filtering will vastly improve this | 09:47 |
| uvos | my manually mesured value is 150mOhm so the avg of your values looks to be very close to that | 09:48 |
| freemangordon | uvos: right | 11:02 |
| freemangordon | it has some bad readings (like .038) at times, but filtering will improve that | 11:02 |
| freemangordon | though, under load the average is closer to 0.1 than 0.15 | 11:03 |
| freemangordon | also, I will try on allwinner, as there we have bad PM, so not sure what I will get | 11:04 |
| * freemangordon tries Ri = a * Ri + (1.0f - a) * r; , where a = .8; | 11:12 | |
| freemangordon | not sure what time const 0.8 actually is :) | 11:13 |
| freemangordon | I forgot so much :( | 11:13 |
| Wizzup | freemangordon: no, upower with no patches is a mess | 11:13 |
| freemangordon | even upstream? | 11:13 |
| freemangordon | did we open issues? | 11:13 |
| Wizzup | well, we tried upstream last time, but we can try it again, see the many patches we carry | 11:13 |
| freemangordon | ok, but why didn;t we pester upstream to fix whatever we think is broken? | 11:14 |
| Wizzup | because we were probably still figuring out what we needed | 11:14 |
| freemangordon | I opened one issue (wrongly) and they replied in a day | 11:14 |
| freemangordon | how we will figure out without trying vanilla? :) | 11:14 |
| freemangordon | uvos: right before low voltage power-down Ri was calculated to be ~.19, under load | 11:20 |
| freemangordon | https://pastebin.com/42XP9z0T | 11:20 |
| freemangordon | uvos: did you build fixed charging_sdl? | 11:24 |
| Wizzup | freemangordon: well, we can go with upstream upower in mce, but I am 99% sure things will be broken again | 11:27 |
| Wizzup | I think this should be an issue for another day | 11:27 |
| Wizzup | They also limit power history to only a day or so, iirc, hardcoded | 11:27 |
| Wizzup | spinal's patches drastically improved the situation for sure | 11:27 |
| freemangordon | ok | 11:27 |
| Wizzup | maybe some of it worked around kernels problems, but it also exposes a lot more data iiuc | 11:28 |
| freemangordon | but, at least SOC calculation based on voltage shall be removed | 11:28 |
| Wizzup | I do agree we probably want it upstreamed eventually, or worked out wit upstream | 11:28 |
| freemangordon | it is extremely innacurate | 11:28 |
| Wizzup | SuperMarioSF: I think so @ battery, the wiki also has some info on it I think | 11:29 |
| Wizzup | freemangordon: so shall I just try to rebase our patches on upower then? | 11:29 |
| freemangordon | I guess | 11:29 |
| freemangordon | I have no idea what those patches are about, besides SOC | 11:29 |
| Wizzup | well, there are also patches from me | 11:30 |
| Wizzup | for example: https://github.com/maemo-leste-upstream-forks/upower/commit/58358f13c931d737c8eeda3244a39cd887308a7a | 11:30 |
| Wizzup | and: https://github.com/maemo-leste-upstream-forks/upower/commit/3f9dd1774ac2a19df7560de1eb23ce15d2836690 | 11:30 |
| Wizzup | I think we want both of these | 11:30 |
| freemangordon | why do we need a moon month of history? | 11:32 |
| freemangordon | Wizzup: anyway, please rebase as you think is appropriate | 11:33 |
| freemangordon | I will try to upstream whatever possible | 11:34 |
| freemangordon | do not pull SOC patch though | 11:34 |
| freemangordon | it does more harm than good IMO | 11:34 |
| Wizzup | which one is that? | 11:34 |
| freemangordon | hard to say | 11:36 |
| freemangordon | seems to be spread over several patches | 11:36 |
| Wizzup | do you want me to drop spinals patches for now, and apply what we think we need? | 11:36 |
| freemangordon | https://github.com/maemo-leste-upstream-forks/upower/commit/13edc4622d19056c934bab196661145de8cbce01 | 11:36 |
| freemangordon | and few on top | 11:37 |
| freemangordon | yes, I think that's better approach | 11:37 |
| Wizzup | it seems to suggest that we would need to re-add code to mce | 11:44 |
| Wizzup | (the commit msg) | 11:44 |
| Wizzup | well, mce and battery applet | 11:44 |
| Wizzup | is this something upstream upower added, the estimation? | 11:45 |
| freemangordon | I don;t think so | 11:45 |
| Wizzup | so how do we deal with it then? | 11:46 |
| Wizzup | we want some estimation, right? | 11:46 |
| freemangordon | yes | 11:46 |
| freemangordon | I am working on it ATM | 11:46 |
| freemangordon | but, if we cannot come up with something sane, we'd better have none | 11:47 |
| freemangordon | instead of shutting down the device while displaying 40% full | 11:47 |
| Wizzup | does that happen? | 11:51 |
| freemangordon | every time here | 11:52 |
| freemangordon | when battery is not calibrated | 11:52 |
| Wizzup | I mean, if you're working on it now, I can leave the upower to you, and then just build mce with upstream upower until we get our own | 11:52 |
| freemangordon | not sure | 11:52 |
| Wizzup | it will be a week off at least until we have an image with then a not-well-working battery applet. ;) | 11:52 |
| freemangordon | I don;t know, I am not sure what exactly do we need from those patches we carry, besides estimation and voltage average | 11:53 |
| freemangordon | and yeah, not reading design voltage every time | 11:53 |
| freemangordon | but, I think this should be already fixed upstream | 11:54 |
| freemangordon | if not, we can simply open an issue | 11:54 |
| freemangordon | so, what I think we shall do is to use upstream upower | 11:54 |
| freemangordon | not the one from chimaera | 11:54 |
| freemangordon | and then add whatever we think is needed on top | 11:55 |
| freemangordon | sending patches for upstreaming in the process | 11:55 |
| Wizzup | HEAD or a tag? | 11:55 |
| Wizzup | (from upstream) | 11:55 |
| freemangordon | I guess latest released | 11:56 |
| Wizzup | imo all the properties added by spinal make sense to me | 11:56 |
| freemangordon | but, we shell check if there is something valuable in between | 11:56 |
| freemangordon | could be | 11:56 |
| Wizzup | I think at least until maybe librem/phosh, nobody used upower on mobile | 11:56 |
| freemangordon | but, the question is, do *we* need/use those paroperties? | 11:56 |
| freemangordon | mce maybe? | 11:57 |
| Wizzup | yes, they are used by battery applet and mce | 11:57 |
| freemangordon | battey applet shall not use anything but SOC | 11:57 |
| Wizzup | also at the time upstream upower was really slow in picking up changes | 11:57 |
| Wizzup | like it would take 30s for it to notice anything | 11:57 |
| Wizzup | (plug in, charging) | 11:57 |
| Wizzup | that was partially related to kernel | 11:57 |
| freemangordon | I remember | 11:57 |
| freemangordon | Wizzup: lets do nothing for now, I want to hear from uvos first | 11:58 |
| freemangordon | unless you are on hurry with upower | 11:58 |
| freemangordon | I also need some time to check HEAD vs last release | 11:59 |
| freemangordon | can;t do now, will do later on (in the evening most-probably) | 11:59 |
| Wizzup | well, we just need to -compile- mce in the ci to move on I think, it depends in our upower (1:<version here>) | 12:00 |
| Wizzup | we can do it later if no other things depend on mce | 12:00 |
| Wizzup | but we want updated mce-dev which comes from mce build | 12:00 |
| Wizzup | if I remove '1:' I am pretty sure it will just compile | 12:01 |
| freemangordon | yes, please do | 12:01 |
| freemangordon | we will have issues with dist-upgrade of beowulf later on, but... | 12:01 |
| freemangordon | I wonder why epoch was added in the first place, but well... | 12:02 |
| freemangordon | not much we can do noa | 12:02 |
| freemangordon | *now | 12:02 |
| Wizzup | we added it | 12:02 |
| freemangordon | yes, but why? | 12:03 |
| freemangordon | anyway | 12:03 |
| freemangordon | not important | 12:03 |
| Wizzup | I think we had a debian pkg replace our with an update or something | 12:03 |
| Wizzup | but spinal did it (the epoch change) | 12:03 |
| freemangordon | ok | 12:04 |
| freemangordon | have to run now, ttyl | 12:04 |
| Wizzup | ttyl | 12:09 |
| Wizzup | mce built | 12:09 |
| Wizzup | BlagovestPetrov[: should I fix the build problems in hildon-desktop, or did you have a pr? | 12:21 |
| BlagovestPetrov[ | I will create a PR in ~10-15 min :) | 12:48 |
| Wizzup | bbiab | 12:49 |
| BlagovestPetrov[ | :) | 12:50 |
| BlagovestPetrov[ | it's strange that it has generated Makefile in the repository | 12:51 |
| Wizzup | uvos: I think your leste-config PR might be bad | 12:52 |
| Wizzup | uvos: it has spaces in the sysctl.d file in the line itself | 12:52 |
| Wizzup | I don't think it is accepted that way | 12:52 |
| Wizzup | care to check if your systems actually have this set after reboot? | 12:52 |
| Wizzup | sysctl -a | grep compaction | 12:52 |
| Wizzup | uvos: hm looks like it worked | 12:54 |
| Wizzup | weird | 12:55 |
| BlagovestPetrov[ | Wizzup: I just put ` CFLAGS += "--param max-inline-insns-single=1000" but it's failing with another error | 12:58 |
| BlagovestPetrov[ | checking.. | 12:58 |
| freemangordon | BlagovestPetrov[: please uninline the function | 12:58 |
| BlagovestPetrov[ | ok:) | 12:59 |
| BlagovestPetrov[ | https://github.com/maemo-leste/hildon-desktop/pull/20 | 13:11 |
| uvos | so mce reads alot of stuff in the upower module | 13:14 |
| uvos | but thats just an artifact from that module being backproted form sfos | 13:14 |
| uvos | mce dosent use any information provided by this module anywhere except battery-guard | 13:14 |
| uvos | witch will work fine as long as at least voltage is available | 13:15 |
| uvos | personally i think we need some kind of soc estimation, but i agree that the current implementation is terrible | 13:15 |
| uvos | (for the battery applet) | 13:16 |
| uvos | since afaik only the battery applet cares about soc, another option is to simply add some estimation to this instead of upower (if upstream upower is not frendly) | 13:16 |
| uvos | freemangordon: yeah charging_sdl shout be fixed | 13:20 |
| Wizzup | this is also something we might want: https://github.com/maemo-leste-upstream-forks/upower/commit/4d0c6223ecbe428757942a803ee5f3024d74ad70 | 13:45 |
| Wizzup | I remember it doing wakeups often | 13:45 |
| Wizzup | what about https://github.com/maemo-leste-upstream-forks/upower/commit/ac052c5cc964edf432c00eab007bc6319fff5268 ? | 13:45 |
| Wizzup | and https://github.com/maemo-leste-upstream-forks/upower/commit/3fe5cbc2db32abe25744bac89d20f0614d32d977 ? | 13:46 |
| Wizzup | BlagovestPetrov[: does the debian/changelog need a newline below the first line? | 13:48 |
| Wizzup | BlagovestPetrov[: if you can add that, please, we usually do that | 13:49 |
| Wizzup | uvos: heh, now my bionic said '4 days' | 13:49 |
| Wizzup | so somethin got better | 13:49 |
| uvos | should turn off all compaction timers | 13:57 |
| uvos | as oposed to just nerfing the one | 13:57 |
| Wizzup | it seems to help | 13:57 |
| uvos | dunno if this has any consequences with long uptime | 13:57 |
| Wizzup | well then we can set it to once an hour or something | 13:57 |
| BlagovestPetrov[ | Wizzup: sorry, fixing.. | 13:59 |
| Wizzup | BlagovestPetrov[: ok, lmk | 14:07 |
| Wizzup | I'll probably a few more packages soon because I don't feel like something else :D | 14:07 |
| BlagovestPetrov[ | done | 14:08 |
| BlagovestPetrov[ | btw, which package was providing theme-config? | 14:09 |
| BlagovestPetrov[ | hildon-initscripts still depends on it | 14:10 |
| Wizzup | I think it should be there now? | 14:10 |
| Wizzup | $ apt-cache search theme-config | 14:10 |
| Wizzup | theme-default-settings - Hildon theme definition | 14:10 |
| Wizzup | btw, pkgweb should now show chimaera pkgs too | 14:11 |
| Wizzup | https://maedevu.maemo.org/pkgweb/search?q=mce | 14:11 |
| BlagovestPetrov[ | oh, apt-get update :) | 14:11 |
| BlagovestPetrov[ | nice | 14:11 |
| BlagovestPetrov[ | osso-applet-notificationlight - ok | 14:18 |
| BlagovestPetrov[ | osso-applet-devicelock - ok | 14:18 |
| BlagovestPetrov[ | hildon-status-menu - ok | 14:18 |
| BlagovestPetrov[ | osso-xterm - ok | 14:18 |
| BlagovestPetrov[ | icd2 fails with multiple definitions. checking.. | 14:19 |
| BlagovestPetrov[ | const gchar* icd_iap_state_names[ICD_IAP_MAX_STATES]; | 14:23 |
| BlagovestPetrov[ | this is in the header | 14:23 |
| BlagovestPetrov[ | and it's defined in every file, where the header is included | 14:24 |
| BlagovestPetrov[ | probably, const gchar* icd_iap_state_names[]; should work | 14:24 |
| BlagovestPetrov[ | nope :) it doesn't | 14:25 |
| BlagovestPetrov[ | --allow-multiple-definition would compile it but it doesn't look good in this way | 14:27 |
| Wizzup | meanwhile I made a python script to backup gh repos | 14:29 |
| * uvos read "break" gh repos | 14:31 | |
| Wizzup | lol | 14:32 |
| dsc_ | `curl <github_api_that_lists_repos> | jq <only_repo_urls> | parallel -j10 git clone {}` | 14:32 |
| Wizzup | https://dpaste.com/7Z7VV3XLE.txt | 14:34 |
| Wizzup | this nicely does git clone --mirror and also updates it | 14:34 |
| Wizzup | so we don't actually lose info with the above oneliner :P | 14:34 |
| Wizzup | it also does updating | 14:34 |
| Wizzup | BlagovestPetrov[: will look at icd2 momentarily | 14:35 |
| Wizzup | BlagovestPetrov[: maybe it needs to be made extern, not sure | 14:45 |
| Wizzup | pretty sure extern is the solution here | 14:47 |
| Wizzup | freemangordon: https://github.com/maemo-leste/icd2/pull/11 | 14:51 |
| tmlind | freemangordon, uvos: cool if you guys got the open circuit stuff going :) | 14:51 |
| Wizzup | freemangordon: version is currently 0.99, so I don't want to make it 1.0, I made it 0.99.1 :p | 14:51 |
| uvos | 2040: icd2 v0.9999999999999999 | 14:52 |
| Wizzup | :D | 14:52 |
| uvos | tmlind: i dident do anything | 14:52 |
| BlagovestPetrov[ | sorry, here. That was fast :)) | 14:55 |
| Wizzup | actually took me like 10-15 mins lol | 14:55 |
| BlagovestPetrov[ | :D | 14:57 |
| BlagovestPetrov[ | theme-default-settings is already in the repository | 14:58 |
| BlagovestPetrov[ | I'm following the list | 14:58 |
| BlagovestPetrov[ | and probably leste-config is also fixed | 14:59 |
| BlagovestPetrov[ | https://github.com/maemo-leste-upstream-forks/eg25-manager | 15:01 |
| BlagovestPetrov[ | we have only the debian directory in the release branch | 15:02 |
| Wizzup | yes leste-config is also done | 15:02 |
| Wizzup | brb, coffee time | 15:02 |
| BlagovestPetrov[ | ok:) | 15:03 |
| BlagovestPetrov[ | xorg will be fun :D | 15:11 |
| uvos | xorg should not be a big deal | 15:11 |
| uvos | it has little deps | 15:11 |
| BlagovestPetrov[ | it's an upstream fork | 15:11 |
| uvos | sure | 15:12 |
| BlagovestPetrov[ | and it fails again because of systemd | 15:12 |
| BlagovestPetrov[ | The following packages have unmet dependencies: | 15:12 |
| BlagovestPetrov[ | libelogind0 : Conflicts: libsystemd0 | 15:12 |
| Wizzup | what package? | 15:12 |
| Wizzup | install hildon-base | 15:12 |
| BlagovestPetrov[ | xorg-server | 15:12 |
| BlagovestPetrov[ | ok :) | 15:12 |
| BlagovestPetrov[ | still, it's a dependency in the control file | 15:13 |
| Wizzup | no, install hildon-base | 15:13 |
| Wizzup | and don't bother with xorg-server :) | 15:13 |
| Wizzup | I need to rebase my patches to the debian xorg | 15:13 |
| BlagovestPetrov[ | :) | 15:13 |
| BlagovestPetrov[ | ok, skipping.. | 15:13 |
| Wizzup | did you install hildon-base? | 15:15 |
| Wizzup | it should prevent you from having libsystemd0 installed | 15:15 |
| Wizzup | ever | 15:15 |
| BlagovestPetrov[ | I've installed it | 15:18 |
| BlagovestPetrov[ | strange | 15:18 |
| BlagovestPetrov[ | and alsa-lib also fails in linkling | 15:19 |
| Wizzup | isn't that anther upstream pkg? sounds like it | 15:21 |
| Wizzup | I think you can skip the upstream ones | 15:21 |
| BlagovestPetrov[ | ok | 15:24 |
| BlagovestPetrov[ | it is | 15:24 |
| BlagovestPetrov[ | should I try upower? status-area-applet-battery depends on it | 15:27 |
| Wizzup | uvos: do you remember we why we forked alsa-lib? | 15:27 |
| Wizzup | BlagovestPetrov[: no, we talked about it earlier today | 15:27 |
| uvos | Wizzup: yes | 15:27 |
| Wizzup | I will fix the debian/control file for it for now | 15:27 |
| uvos | there was a bug in alsa-lib that broke the parsing of the alsa volume restore file when this file contained the charecter # | 15:28 |
| uvos | as the mapphone dtmf channel contains this symbol, restoring audio volumes was broken | 15:28 |
| uvos | however this was fixed in, at the time, git alsa | 15:29 |
| uvos | so we build git alsa | 15:29 |
| uvos | i presume this has filtered into chimera | 15:29 |
| BlagovestPetrov[ | oh, ok | 15:29 |
| Wizzup | BlagovestPetrov[: our upower version starts with 1:, if you remove that from the control file, it'll build np | 15:30 |
| BlagovestPetrov[ | ok | 15:30 |
| Wizzup | but no need to make a PR for it | 15:30 |
| BlagovestPetrov[ | yes, it builds | 15:32 |
| Wizzup | we will still need to build xorg at least, they never looked at my patch | 15:34 |
| Wizzup | but it's not critical | 15:34 |
| Wizzup | it's just for touchscreen vibration | 15:34 |
| BlagovestPetrov[ | - rm -f atinout atinout.1 atinout.1.html atinout.spec | 15:42 |
| BlagovestPetrov[ | + rm -f atinout atinout.1.html atinout.spec | 15:42 |
| BlagovestPetrov[ | weird but makefile was removing the man page | 15:43 |
| BlagovestPetrov[ | it's fixed in the bewulf branch | 15:44 |
| Wizzup | BlagovestPetrov[: so should I continue down from leste-config? | 15:44 |
| BlagovestPetrov[ | you can check my file but almost everything was upstream forks | 15:46 |
| Wizzup | ah, ok | 15:46 |
| Wizzup | I got confused because you reported some here | 15:46 |
| Wizzup | btw, looks like debian xorg now depends on logind | 15:46 |
| Wizzup | (e)logind | 15:46 |
| BlagovestPetrov[ | phew | 15:46 |
| Wizzup | it's not a big deal, we can use elogind, it's just that it's annoying in every way | 15:47 |
| Wizzup | so we just need to make it do exactly 0, other than privs mgmt | 15:47 |
| Wizzup | like it would restart our phones when the power button was pressed before | 15:47 |
| freemangordon | Wizzup: hmm, what's wrong with 0.100? | 15:47 |
| BlagovestPetrov[ | :) | 15:47 |
| Wizzup | freemangordon: 1.0 | 15:48 |
| Wizzup | oh | 15:48 |
| Wizzup | I guess we could do 0.100 | 15:48 |
| Wizzup | let me fix | 15:48 |
| freemangordon | otherwise I guess PR is fine | 15:48 |
| BlagovestPetrov[ | atinout - ok ( works on beowulf branch; master is behind )... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/682c8722daadec407abc3357f811fccf9d67b56b>) | 15:48 |
| Wizzup | freemangordon: force-pushed now | 15:49 |
| BlagovestPetrov[ | this is everything you can build below leste-config | 15:49 |
| freemangordon | Wizzup: ok. do you want me to merge it? | 15:49 |
| Wizzup | yep | 15:50 |
| freemangordon | ok | 15:51 |
| freemangordon | uvos: when battery is fully charged, I get values like 0.012846 | 15:52 |
| BlagovestPetrov[ | maemo-security-certman is not compatible with the newest libnss. checking.. | 15:53 |
| Wizzup | BlagovestPetrov[: ok, then just skip and we'll fix | 15:55 |
| BlagovestPetrov[ | ok | 15:55 |
| Wizzup | or fix if you want :D | 15:55 |
| Wizzup | but it's probably nasty | 15:55 |
| Wizzup | (in my experience) | 15:55 |
| BlagovestPetrov[ | crypto.. :D | 15:55 |
| BlagovestPetrov[ | I'll try | 15:56 |
| Wizzup | I did the openssl port from 0.9.x to 1.x | 15:56 |
| Wizzup | that was not fun | 15:56 |
| BlagovestPetrov[ | definitely not :D | 15:56 |
| uvos | freemangordon: you would expect the internal resistance to be lower at high soc and higher at high rates of discharge, but this is too mutch | 15:56 |
| BlagovestPetrov[ | manufacturerID = Nokia Corporation this can be changed :) | 15:56 |
| uvos | freemangordon: maybe just restict mesureing to 3.6-3.9V and call it a day | 15:58 |
| tmlind | Wizzup, uvos: got xt910 booting to kexecboot, it has an empty utags partition | 15:58 |
| tmlind | anybody have an xt912 handy to dump some info? might as well add that too while at it | 15:58 |
| uvos | tmlind: i have xt912 what do you need? | 15:59 |
| uvos | its booted mainline before | 15:59 |
| uvos | (via kexec from android but still) | 15:59 |
| tmlind | uvos: ok just a few things: fdisk -l of /dev/boot/mmcblk1 and dd dump of the utags partition | 16:00 |
| tmlind | oh and if you can check the bpsw partition is empty | 16:00 |
| tmlind | the other info like initramfs offset i just dumped from the stock firmware | 16:01 |
| tmlind | hmm the stock firmware does not have a cdt.bin, so a dump of that partition would help with the partition names :) | 16:02 |
| uvos | no wait i have xt910 (eu version) | 16:02 |
| uvos | i got these confused | 16:02 |
| uvos | xt912 is the us one | 16:02 |
| tmlind | yeah i got them mixed up too few days ago :) | 16:02 |
| uvos | i only have xt910 | 16:03 |
| tmlind | ok np, i'll get an xt912 in few weeks from Wizzup | 16:03 |
| tmlind | hmm seems that xt910 has some yet another key for the power key | 16:03 |
| uvos | maybe its KEY_POWER even xD | 16:04 |
| freemangordon | uvos: well, lets see how calculations will compare to reported level | 16:05 |
| Wizzup | uvos: do you need xt912? | 16:10 |
| uvos | Wizzup: no, im fine with xt910 | 16:10 |
| Wizzup | ok | 16:10 |
| freemangordon | uvos: I was using wrong math, that's why the values | 16:25 |
| Wizzup | never a good idea to use the wrong math :P | 16:29 |
| freemangordon | yeah | 16:30 |
| BlagovestPetrov[ | ke-recv : Depends: ke-recv-l10n-mr or | 16:30 |
| BlagovestPetrov[ | ke-recv-l10n-mr0 but it is not going to be installed | 16:30 |
| BlagovestPetrov[ | there are some missing l10n packages | 16:30 |
| Wizzup | freemangordon: should modem/call stuff go into chimaera or should I make chimaera-devel ? | 16:30 |
| Wizzup | BlagovestPetrov[: ke-recv-l10n-mr0 is already the newest version (7.3.0+m7). | 16:31 |
| Wizzup | try to apt-get install it and see what complains | 16:31 |
| freemangordon | Wizzup: lets go | 16:31 |
| Wizzup | can't parse, want it all in chimaera? | 16:31 |
| BlagovestPetrov[ | https://hastebin.com/yesuqovumo.sql | 16:33 |
| BlagovestPetrov[ | weird | 16:33 |
| freemangordon | sorry, I meant - yes, lets put modem stuff in chimaera | 16:33 |
| uvos | ugh please note the bug where the modem stuff breaks all connections includeing wifi | 16:36 |
| uvos | if the modem dosent come online for any reason | 16:37 |
| uvos | thats a pretty terrible thing to expose stable to imo | 16:37 |
| Wizzup | chimaera is not stable | 16:37 |
| uvos | then maybe build just a devel image | 16:38 |
| Wizzup | imo we should just fix the bug | 16:40 |
| uvos | sure but if you build just a "stable" chimaera im not sure what the path here is besides fixing all bugs imidiatly and then branching a devel then | 16:42 |
| uvos | but that seams overly ambitious since im shure chimaera will have some new bugs that need attention first | 16:42 |
| uvos | while if we start with just a devel chimaera the path makes more sense, build devel, stabilize, and then branch out a chimaera-stable | 16:43 |
| uvos | but do what you like | 16:43 |
| freemangordon | uvos: I think this algo is a bit pessimistic | 16:55 |
| freemangordon | (for calculation of the SOC) | 16:55 |
| uvos | being a bit on the pessimistic side is imo better than being on the optimistic side | 16:57 |
| uvos | depends on how mutch ofc | 16:57 |
| uvos | so i think targeting being slightly pessimistic with soc estimation makes the most sense | 16:57 |
| freemangordon | reports 92% for 99% | 16:57 |
| freemangordon | ok | 16:57 |
| freemangordon | Ri = 0.104746 | 16:58 |
| freemangordon | which looks sane to me | 16:58 |
| uvos | if its most pessimistic at the top end | 16:58 |
| uvos | this is imo alos no problem | 16:58 |
| uvos | since hopefully battery will be callibrated then | 16:58 |
| freemangordon | the problem is it never shows 100 % | 16:58 |
| freemangordon | but yeaah | 16:58 |
| uvos | sure but at least on d4 this is no problem | 16:59 |
| uvos | as callibrated value will take over | 16:59 |
| freemangordon | right | 16:59 |
| uvos | also you could have it show 100% whenever the kernel claims that the battery is fullt | 16:59 |
| freemangordon | well... | 16:59 |
| uvos | i know on d4 the kernel never claims this | 16:59 |
| uvos | for resonable amounts of time | 16:59 |
| freemangordon | do you want the latest version to test? | 17:00 |
| freemangordon | actually, I'll paste it here for whoever wants to | 17:00 |
| uvos | sure i can run it for a bit to see what it reports ri wise | 17:00 |
| freemangordon | https://pastebin.com/YnMv8w12 | 17:01 |
| Wizzup | uvos: I think your algo is a bit pessimistic wrt fixing bugs :P | 17:05 |
| Wizzup | we also still have annoying bugs in non-devel | 17:06 |
| uvos | being a bit on the pessimistic side is imo better than being on the optimistic side | 17:06 |
| uvos | depends on how mutch ofc | 17:06 |
| uvos | so i think targeting being slightly pessimistic with chimaera migration makes the most sense | 17:06 |
| uvos | Wizzup: :P | 17:06 |
| freemangordon | sicelo: could you please build and run what I pasted ^^^ on n900? to compare calculated VS reported value | 17:08 |
| freemangordon | you will have to change BATTERY_FILE define | 17:08 |
| SuperMarioSF | Wizzup , I just sent you the images of XT883, please check mailbox. (105MiB, not attached with mail, but in a OneDrive share link instead.) | 18:30 |
| SuperMarioSF | with some notes attached. | 18:31 |
| Wizzup | it's downloading, thanks | 18:40 |
| Wizzup | the front seems to in a good condition | 18:43 |
| SuperMarioSF | the back.... oof | 18:44 |
| Wizzup | yeah, oh well :) | 18:44 |
| Wizzup | notes look great | 18:44 |
| SuperMarioSF | so sticky, much gunk, wow. | 18:44 |
| Wizzup | yeah, this happens with old plastic sometime I think | 18:45 |
| SuperMarioSF | usually with some skin like texture, which is a thic layer of latex. | 18:46 |
| SuperMarioSF | I have a Lenovo Thinkpad X201i | 18:46 |
| SuperMarioSF | and it suffers the exactly same problem | 18:47 |
| SuperMarioSF | *thin layer of latex | 18:47 |
| SuperMarioSF | it is very diffcult to cleanup the mess. | 18:47 |
| SuperMarioSF | but | 18:48 |
| SuperMarioSF | if the phone was actively used back then, this issue won't be that problematic | 18:48 |
| SuperMarioSF | this also shows the phone is barely used and just sitting in the box for a decade. | 18:49 |
| uvos | oh btw SuperMarioSF | 18:51 |
| uvos | there was another china exlusive (afaik) mapphone | 18:51 |
| SuperMarioSF | ? | 18:51 |
| SuperMarioSF | which one? | 18:52 |
| uvos | xt881 codename Yangtze | 18:52 |
| uvos | this is also i think the last mapphone none of us have :P | 18:52 |
| uvos | at least this device has a chineese regonal rom image | 18:53 |
| uvos | so i presume it was china only | 18:53 |
| uvos | and yeah indeed this is the final mapphone we dont have | 18:54 |
| SuperMarioSF | XT881 | 18:55 |
| SuperMarioSF | product name "Electrify 2" | 18:55 |
| SuperMarioSF | 1GB RAM + 8GB internal storage | 18:55 |
| SuperMarioSF | 1780mAh battery | 18:56 |
| SuperMarioSF | Android 4.0 on OMAP4430 | 18:56 |
| SuperMarioSF | sadly there is almost no item available on second-hand market. | 18:57 |
| SuperMarioSF | the only one seems only have phone itself. | 18:58 |
| SuperMarioSF | because lack of a physical keyboard, this phone may be treated as any "normal" phone, so not popular in collector's terms, thus usually not much sales. | 18:59 |
| uvos | it probubly also dident sell anny | 19:00 |
| SuperMarioSF | maybe. | 19:00 |
| uvos | its mostly uninteresting being almost same as the more common xt91x | 19:00 |
| SuperMarioSF | or they sell many but they all died, due to age and lost of interest. | 19:00 |
| uvos | sure | 19:00 |
| uvos | just maybe interesting from a collectors point of view to have all mapphones | 19:01 |
| tmlind | heh | 19:01 |
| SuperMarioSF | so you actually want one, despite it will only came with phone only? | 19:01 |
| uvos | maybe, how much? | 19:02 |
| Wizzup | Almost everything we get from ebay is just the phone | 19:02 |
| SuperMarioSF | hmmmmm | 19:02 |
| SuperMarioSF | CNY 99 | 19:02 |
| SuperMarioSF | dirt cheap. | 19:02 |
| Wizzup | so 13,37 eur | 19:02 |
| Wizzup | I like that ;) | 19:02 |
| SuperMarioSF | but something weird | 19:02 |
| SuperMarioSF | the listing says it was a "English language phone" | 19:03 |
| uvos | hmm | 19:03 |
| uvos | maybe it was sold somewhere else too | 19:03 |
| SuperMarioSF | and system UI clear shown English. | 19:03 |
| uvos | let me check us | 19:03 |
| SuperMarioSF | Wizzup, wil this time you will get 2 XT883 with maybe almost complete retail box. | 19:04 |
| Wizzup | SuperMarioSF: yeah, that sounds great, I was surprised by the photos that you emailed, the device is so complete. | 19:04 |
| SuperMarioSF | the first one I guess is the complete one, except plastic wraps of course. | 19:04 |
| uvos | there are none on us ebay at least | 19:04 |
| uvos | so no idea | 19:04 |
| freemangordon | uvos: where did you get the formula from? | 19:05 |
| uvos | freemangordon: dunno via pavel | 19:06 |
| freemangordon | hmm | 19:06 |
| uvos | dont know where it came from originally (besides the comment that it comes with) | 19:06 |
| SuperMarioSF | from the listing, the second one may lack of some boring booklets, but earphone, charger, cable is present. maybe lacking one battery (seems only have one). | 19:06 |
| freemangordon | I opened that post | 19:06 |
| freemangordon | only half of the formula is there | 19:07 |
| Wizzup | I have hildon-desktop and hildon-home in my vm | 19:07 |
| freemangordon | :) | 19:07 |
| freemangordon | good boy ;) | 19:07 |
| uvos | ok maybe pavelmachek can enlighten us, if we know how to contact him | 19:07 |
| SuperMarioSF | the second one maybe being used for a little, not good as the first one, but good enough. | 19:07 |
| freemangordon | uvos: via mail, but how did you get it initially? | 19:07 |
| uvos | i pilferd the battery handling code in charging_sdl from https://github.com/pavelmachek/libbattery | 19:08 |
| Wizzup | https:/wizzup.org/chimaera.png | 19:08 |
| Wizzup | https://wizzup.org/chimaera.png | 19:08 |
| Wizzup | BlagovestPetrov[: ^^ | 19:08 |
| freemangordon | nice! | 19:09 |
| Wizzup | we'll get it going in no time | 19:09 |
| uvos | sweet | 19:09 |
| BlagovestPetrov[ | hah | 19:09 |
| BlagovestPetrov[ | nice :)) | 19:09 |
| SuperMarioSF | and good news | 19:09 |
| Wizzup | just apt-get install xorg-server hildon-desktop hildon-home osso-xterm, reboot and then log in via and start them | 19:09 |
| freemangordon | uvos: ok, I'll send him a mail | 19:09 |
| SuperMarioSF | the second one may have much less gunk on the back cover. seems in good condition. | 19:10 |
| Wizzup | note that at this point there is a xorg init script I think, so you won't be able to use console normally | 19:10 |
| Wizzup | SuperMarioSF: great :D | 19:10 |
| Wizzup | SuperMarioSF: I think the back cover is the same as the droid 3, which I have here, back cove rwise | 19:10 |
| SuperMarioSF | oh I noticed the second one's protect film for back side of the screen is present, just missing the pull tab. | 19:11 |
| SuperMarioSF | thanks to weird habits of Chinese people: Not peeling off any protective cover if possible | 19:11 |
| Wizzup | heh | 19:12 |
| SuperMarioSF | 🤣 | 19:12 |
| uvos | not just chinese people, i routinely make fun of my gf for this :P | 19:12 |
| SuperMarioSF | hmmmm | 19:12 |
| SuperMarioSF | maybe for a known fate of reselling these thing? | 19:13 |
| SuperMarioSF | I certainly don't care that much. | 19:13 |
| SuperMarioSF | but I will have extra protection for my devices especially for screen. | 19:14 |
| SuperMarioSF | scratched screen is so painful to watch | 19:14 |
| SuperMarioSF | but I certainly not reselling anything I have, except very rare cases. | 19:15 |
| uvos | for some reason you can buy d4 screen protectors on german ebay, very conviniant | 19:15 |
| SuperMarioSF | and my storage is filled with those strange things. | 19:15 |
| SuperMarioSF | oh | 19:15 |
| uvos | dunno who or why someone would sitting on d4 accesorys in DE | 19:15 |
| SuperMarioSF | In china there is a type of service to customize made screen protection film. | 19:16 |
| uvos | sure but these ship way to fast to be from china | 19:16 |
| SuperMarioSF | oh that is not "ship" | 19:17 |
| uvos | i dont think it would be profitable to produce them here either | 19:17 |
| uvos | SuperMarioSF: sure even air freight | 19:17 |
| uvos | took like 2 days to arive | 19:17 |
| SuperMarioSF | you take your phone, any strange one, the only requirement is having a screen. | 19:17 |
| SuperMarioSF | to a service shop | 19:17 |
| SuperMarioSF | and they cut a customized shape for you | 19:18 |
| SuperMarioSF | just wait about 15min | 19:18 |
| SuperMarioSF | you can leave with new film applied | 19:18 |
| SuperMarioSF | 15min plus maybe 30min of walk time, surely faster than 2 days of shipping | 19:19 |
| uvos | sure no doubt | 19:20 |
| SuperMarioSF | but this type of protection is only a layer of plastic. | 19:20 |
| SuperMarioSF | I usually want a layer of hardened glass | 19:20 |
| SuperMarioSF | which is much diffcult to manufacture and customized. | 19:21 |
| SuperMarioSF | and it seem there is no such thing supplied any more in China. | 19:21 |
| SuperMarioSF | (for D4) | 19:22 |
| SuperMarioSF | but if you want to sell many of them, you can order a whole batch, and they will customize made for you. | 19:22 |
| SuperMarioSF | as long as the screen is flat, they can do it. | 19:23 |
| SuperMarioSF | . | 19:24 |
| SuperMarioSF | wow | 19:24 |
| SuperMarioSF | the replaced battery of my D4 lasted the whole day | 19:24 |
| SuperMarioSF | and have 45% battery left | 19:24 |
| bencoh | wow | 19:24 |
| bencoh | maybe I should really order a new one as well | 19:25 |
| Wizzup | at this point this should be expected maemo leste | 19:25 |
| SuperMarioSF | with 3G modem always online for phone and SMS | 19:25 |
| Wizzup | expected with maemo leste* | 19:25 |
| SuperMarioSF | yup | 19:25 |
| Wizzup | maybe even more | 19:25 |
| SuperMarioSF | but not expected with some old new stock battery replacement | 19:25 |
| Wizzup | mhm | 19:25 |
| SuperMarioSF | the old one only have about 6~8 hours, 1233mAh | 19:26 |
| SuperMarioSF | since this is the first boot up, I haven't able to start calibration yet. | 19:26 |
| Wizzup | wow, that can't have been 1233mAh | 19:26 |
| Wizzup | I get over a day easily on 1081maH | 19:27 |
| Wizzup | mAh* | 19:27 |
| SuperMarioSF | weird... | 19:27 |
| SuperMarioSF | I removed calibration file, so I have to depleate the battery and recharge them up to 100% to gei it done? | 19:27 |
| Wizzup | I think so, ideally we'd have some mode for it :) | 19:28 |
| SuperMarioSF | I forgot how to do that... and I'm not able to find the document for it (maybe the second time) | 19:28 |
| freemangordon | SuperMarioSF: most-probably those 45% are fake | 19:29 |
| freemangordon | if not calibrated, you have no more than 5-8% | 19:29 |
| SuperMarioSF | and there is a weird thing | 19:29 |
| freemangordon | ATM we have a really bad voltage based SOC estimation | 19:30 |
| SuperMarioSF | I first depleated the battery | 19:30 |
| SuperMarioSF | really hard | 19:30 |
| SuperMarioSF | it shut itself down | 19:30 |
| SuperMarioSF | and I am not able to boot it to desktop again, even with power plugged in | 19:30 |
| SuperMarioSF | the reading from my meter shown there is no current usage from power cable during the boot . | 19:31 |
| freemangordon | re-plug the USB cable | 19:31 |
| SuperMarioSF | I tried but it doesn't work. | 19:31 |
| freemangordon | latest kernel seem to have broken something in that regard | 19:31 |
| SuperMarioSF | I have to boot into android side, actually the charger animation | 19:31 |
| freemangordon | the same happened here today | 19:31 |
| SuperMarioSF | at there I can charge | 19:31 |
| SuperMarioSF | at 1.5A | 19:32 |
| freemangordon | yeah | 19:32 |
| freemangordon | we have charger-detection WIP | 19:32 |
| freemangordon | still not in the repos | 19:32 |
| SuperMarioSF | but I have no idea if this can break the calibration | 19:32 |
| Wizzup | that would be good to have, then we can actually leave devices on usbnet and access them remotely :P | 19:32 |
| SuperMarioSF | if I can at least charge it to around 10% from android side, I can boot maemo normally. | 19:33 |
| SuperMarioSF | is this can affect calibration? | 19:33 |
| Wizzup | charge-mode should be able to do this for you too | 19:33 |
| Wizzup | (the charging) | 19:33 |
| SuperMarioSF | so I can just depleate battery, boot to Android charge mode, and charge to 100%, back to maemo, the calibration wil just done at that moment? | 19:34 |
| uvos | no | 19:34 |
| SuperMarioSF | you mean the maemo charge mode? | 19:35 |
| uvos | you have to boot from empty and then charge to full with the mainline kernel | 19:35 |
| uvos | or the other way around | 19:35 |
| SuperMarioSF | then how can I boot from empty state if mainline kernel doesn't use power from power supply? | 19:35 |
| uvos | this works fine here | 19:36 |
| uvos | but i think its broken | 19:36 |
| uvos | because cpcap-charger starts charging on usb plugged irq | 19:36 |
| uvos | or vbus irq, i havce to check the code | 19:36 |
| SuperMarioSF | so I should plug the cable in right after the module loaded? | 19:36 |
| uvos | but point is its a irq | 19:36 |
| uvos | and i dont see how this can not break when the lead is allready plugged on boot | 19:36 |
| freemangordon | uvos: this used to work just fine with 5.18 | 19:37 |
| uvos | i know | 19:37 |
| uvos | but i dont see how this can be not racy | 19:37 |
| uvos | SuperMarioSF: yes | 19:37 |
| SuperMarioSF | OK i will try | 19:37 |
| SuperMarioSF | the cpcap-charger module will load before or after the kernel fb console initialized? | 19:38 |
| freemangordon | uvos: with extcon driver no irq will be needed | 19:38 |
| uvos | freemangordon: great | 19:38 |
| uvos | SuperMarioSF: it probes slightly after | 19:38 |
| SuperMarioSF | oh | 19:38 |
| uvos | i think | 19:38 |
| SuperMarioSF | maybe that is the bad news | 19:38 |
| SuperMarioSF | because I often see it loads and immediately detected a low battery and just shut down | 19:39 |
| SuperMarioSF | I basically have no chance to plug it in | 19:39 |
| buZz | you can plug usb before xorg starts | 19:39 |
| SuperMarioSF | I know | 19:39 |
| buZz | to prevent the autopoweroff from low voltage | 19:39 |
| uvos | buZz: if his battery is below the kernels threshold | 19:40 |
| SuperMarioSF | but that didn't even give me a chance even for xorg | 19:40 |
| SuperMarioSF | I see those low battery message from fb console | 19:40 |
| buZz | oh ok | 19:40 |
| uvos | (should never happen really but ok) that wont help @buZz | 19:40 |
| uvos | SuperMarioSF: in this case charge with android and try again | 19:40 |
| uvos | this time soon after device shuts down due to low battery | 19:41 |
| uvos | or wait for freemangordon to fix usb detection | 19:41 |
| SuperMarioSF | OK | 19:41 |
| SuperMarioSF | I will try first | 19:41 |
| SuperMarioSF | if not working, I wait for it fixed. | 19:42 |
| SuperMarioSF | at least this time I won't depleate it too hard. | 19:42 |
| freemangordon | I think I shall stop waiting upstream and just do whatever I think is sane | 19:42 |
| SuperMarioSF | last time I just ran a stress test on it | 19:42 |
| freemangordon | later on, if they reply in this life, I can change it | 19:42 |
| SuperMarioSF | maybe it was too hard | 19:43 |
| SuperMarioSF | about upstream... | 19:43 |
| SuperMarioSF | Linux maintainers are hard to work with these days... | 19:43 |
| freemangordon | no, as I said, voltage-based SOC estimation we use now is useless | 19:44 |
| freemangordon | hard? I would say impossible, they don;t reply in weeks for 2 liners :( | 19:44 |
| SuperMarioSF | sometimes they reject your thing and say nothing meaningful to solve the problem | 19:45 |
| SuperMarioSF | for example | 19:45 |
| Wizzup | freemangordon: got a moment to help me think about maemo-security-certman ? | 19:45 |
| SuperMarioSF | you have a new hardware design support, you submitted your change and fixed many problem. | 19:45 |
| freemangordon | SuperMarioSF: or this, yes | 19:46 |
| SuperMarioSF | and they rejected your change, even you fixed anything the current state went wrong. | 19:46 |
| Wizzup | freemangordon: in lib/certman/cryptoki_module.c there is a duplicate declaration of some define that is now also defined in nss, it's CRYPTOKI_VERSION_MAJOR and CRYPTOKI_VERSION_MINOR. I'm not sure if we can just use NSS's version, or if we'd need to change our cryptoki implementation using nss to match the version required | 19:46 |
| SuperMarioSF | they say "I haven't seen your hardware is widely used, so support for it will be pointless" like things | 19:46 |
| SuperMarioSF | and their mind is still stopped at a decade ago for that hardware. | 19:47 |
| SuperMarioSF | *similar hardware | 19:47 |
| freemangordon | Wizzup: not sure I can help without looking in the code | 19:48 |
| Wizzup | freemangordon: my guess if that we might want to rename our const and use it, since it's not clear if we will support it | 19:48 |
| Wizzup | freemangordon: right, it's blocking connui-internet | 19:48 |
| freemangordon | sound sane | 19:48 |
| freemangordon | *sounds | 19:48 |
| Wizzup | I suppose I could just do the safe thing and rename? | 19:48 |
| freemangordon | mhm | 19:48 |
| uvos | i submitted the touch screen buttons driver FIVE times to linux-input, with never as mutch as a comment from anyone | 19:49 |
| SuperMarioSF | from I know, there even some racist against some type of people who contribute the code inside the maintainers. | 19:49 |
| uvos | so yeah kernel maintainers, omap folks excepted are pretty hard to get to review stuff | 19:49 |
| SuperMarioSF | no wonder there is too much out-of-tree modules present for new open-source hardware. | 19:50 |
| SuperMarioSF | because they just can't add support for it in mainline because those toxic maintainers. | 19:50 |
| freemangordon | SuperMarioSF: scratch new hardware, I am trying to fix obvious bugs, see https://www.spinics.net/lists/linux-usb/msg233614.html for example | 19:51 |
| freemangordon | this is what we need to have working charger detection | 19:52 |
| SuperMarioSF | the funny thing is, the same person have been rejected, just ported NetBSD for its hardware design, way faster than Linux does. | 19:52 |
| freemangordon | not only on d4, but on any device in general | 19:52 |
| freemangordon | and yet the only comment so far was "atomic notifiers are horrid" | 19:54 |
| SuperMarioSF | hmmm I wonder those maintainer is working in a atomic way :P | 19:55 |
| SuperMarioSF | (workflow about doing the actual changes) | 19:56 |
| sicelo | freemangordon: N900 is bootlooping, so can't test. but I may do so on my postmarketOS install | 20:03 |
| sicelo | mmm, i see glib.h there ... wonder if musl will like that | 20:03 |
| freemangordon | yeah, we don't really need leste for that | 20:04 |
| freemangordon | ummm | 20:04 |
| freemangordon | glib is not libc6 | 20:04 |
| uvos | admittedly confusing with one being called glib and a popular implementation of the other glibc | 20:06 |
| Wizzup | uvos: maybe for new kernel upgrades we should use leste-experimental | 20:09 |
| Wizzup | it's not great to have our n900 devel users have a bootlooping kernel | 20:09 |
| uvos | i can do that | 20:09 |
| Wizzup | great | 20:09 |
| uvos | altho imo we should keep stable closer to devel and tell people who use devel: tough | 20:09 |
| uvos | but ill do what you prefer | 20:10 |
| sicelo | "and tell people who use devel: tough" - i completely disagree. that's like showing middle finger to those people. the point of devel is to get testers, no? | 20:12 |
| uvos | the point of devel is that it can break at any time | 20:12 |
| sicelo | i don't understand why you noticed that it broke n900, but kept quiet about it | 20:13 |
| sicelo | anyway | 20:13 |
| sicelo | freemangordon: sure will do it in a bit | 20:13 |
| uvos | ? i noticed after it was in devel allready | 20:13 |
| sicelo | yes, kept quiet still. | 20:13 |
| uvos | anyhow imo adding exipiramental dose nothign but add another layer, makeing devel stable and expieramental be the new devel | 20:14 |
| sicelo | i waited around two or more days until i upgraded. i was so sure you were not aware of the bootloop | 20:14 |
| sicelo | but yes it's immaterial | 20:14 |
| uvos | i dident know anything was wrong with n900 for any siginificant amount of time... | 20:14 |
| uvos | besides this is pointless, rn we are wating on Wizzup to grab serial output | 20:15 |
| BlagovestPetrov[ | libicd-network-wpasupplicant fails, again because of flags and old gtk. checking.. | 20:15 |
| Wizzup | uvos: ok, let me do it tonight | 20:18 |
| Wizzup | tmlind damned me by giving me his serial ;) | 20:19 |
| tmlind | hehe | 20:20 |
| uvos | same trojan horses Wizzup hands out when it supplies devices :P | 20:20 |
| sicelo | freemangordon: after compiling, needs to be run over a period of time? | 20:24 |
| sicelo | still must boot pmOS though | 20:24 |
| freemangordon | sicelo: well, as soon as you run it it starts printing results | 20:27 |
| freemangordon | new value is calculated and print every 30 seconds | 20:28 |
| uvos | probubly we should test it on a verity of soc on different devcies | 20:29 |
| uvos | ill try xt875 later | 20:29 |
| uvos | maybe tomorrow | 20:29 |
| BlagovestPetrov[ | Wizzup: https://github.com/maemo-leste/libicd-network-wpasupplicant/pull/1 | 20:29 |
| BlagovestPetrov[ | I see that you already made a branch for Chimaera but it was failing for me | 20:29 |
| Wizzup | BlagovestPetrov[: ah just fixed it | 20:32 |
| Wizzup | sorry :( :( | 20:32 |
| Wizzup | I shouldn't get ahead of you :) | 20:32 |
| BlagovestPetrov[ | it's ok :D | 20:32 |
| BlagovestPetrov[ | i'm going to have a dinner and we can sync after | 20:33 |
| Wizzup | cool | 20:33 |
| Wizzup | qt5 will still be some work I bet | 20:34 |
| Wizzup | qt 5.11 to qt 5.15 | 20:34 |
| sicelo | freemangordon: regarding estimating SOC, maybe there'll be some pointers in bme(-replacement) too? fremantle always had a way to know percentage even on newly inserted battery | 20:35 |
| * uvos salvates about qt 5.15 wrt possibilies of apps to use from plamo | 20:35 | |
| Wizzup | is it a big difference? | 20:35 |
| uvos | Wizzup: yes huge | 20:36 |
| uvos | since 5.15 is the final qt5 release | 20:36 |
| Wizzup | good for you, not good for me, having to do the rebasing | 20:36 |
| uvos | it has lots of support | 20:36 |
| Wizzup | :D | 20:36 |
| uvos | Wizzup: :P | 20:36 |
| dsc_ | qt6 is gonna be painful | 20:37 |
| uvos | i presume chimaera dosent have qt6? | 20:37 |
| uvos | otherwise additional outch | 20:37 |
| Wizzup | they removed qt4 | 20:38 |
| Wizzup | in bullseye | 20:38 |
| dsc_ | qt6 is gonna be painful because its not backward compatible with QML "1.0" | 20:38 |
| dsc_ | they rewrote it basically | 20:38 |
| Wizzup | dsc_: speaking of which, openmediaplayer is qml 1.0 but I never got it to work :p | 20:38 |
| Wizzup | and I suspect qt5 will be around for many years to come | 20:38 |
| dsc_ | right | 20:38 |
| dsc_ | oh for sure | 20:38 |
| dsc_ | I think the community is still waiting on qt6 to get stable, just like with qt5, it only got 'usable' starting from 5.7 :P | 20:39 |
| dsc_ | plus some drama around the license changes | 20:39 |
| Wizzup | yup | 20:39 |
| Wizzup | we need to work on out qt5 support in maemo | 20:39 |
| Wizzup | the colour problems still being there is a bit embarrasing | 20:40 |
| Wizzup | and the input method also really needs to happen soon | 20:40 |
| uvos | we need someone who is good with themes i gues | 20:42 |
| uvos | the gtk2 thems are also broken | 20:42 |
| uvos | wrt the buttons | 20:42 |
| Wizzup | where do you see those being broken? | 20:43 |
| uvos | anywhere where they expand beyond the minimal size (eg. pinentry) | 20:43 |
| uvos | iirc this is beacuse the bitmap map is wrong | 20:44 |
| uvos | so the wrong subimages are selected | 20:44 |
| uvos | the qt issue is useing base color on window color instead of window text with window color | 20:45 |
| uvos | the themes/ gtk2 theme translator dose this | 20:45 |
| Wizzup | so I am not sure if this is a theming problem | 20:45 |
| Wizzup | (the gtk scaled buttons) | 20:46 |
| uvos | yes it is at least it renders ok in non maemo themes | 20:49 |
| BlagovestPetrov[ | yeah, qml is completely rewritten | 20:50 |
| BlagovestPetrov[ | most of the qml libs are with different include names | 20:50 |
| Wizzup | qml theming in general is also tricky I think | 20:50 |
| BlagovestPetrov[ | нуфр | 20:51 |
| BlagovestPetrov[ | ops, I mean, yeah | 20:51 |
| freemangordon | uvos: I fixed some of the themes | 20:54 |
| freemangordon | fix shall be ported to other themes as well | 20:55 |
| tmlind | so i just pushed out updated sources for utagboot and buildroot, and new binaries for droid4-kexecboot with initial support for xt910 | 20:56 |
| tmlind | also the binaries are now there for mz609 and mz617 | 20:56 |
| tmlind | utagboot at https://github.com/tmlind/utagboot/commits/master | 20:56 |
| tmlind | buildroot at https://github.com/tmlind/buildroot/tree/mapphone-kexecboot-2017.11 | 20:57 |
| tmlind | note new branch name.. i force pushed the trashed old droid4-kexecboot-2017.11 branch that had my old wlan config files included | 20:57 |
| tmlind | droid4-kexecboot binaries at https://github.com/tmlind/droid4-kexecboot/commits/master | 20:58 |
| tmlind | note the new naming for the utags-*.bin files with the utag partition and the droid4-kexecboot partition in the name | 20:58 |
| tmlind | uvos: so if you have already a xt910 patches somewhere i could give it a try when i get a chance | 20:59 |
| tmlind | i only tested xt910 so it boots to the stock distro from kexecboot | 20:59 |
| sicelo | btw, the droid 4 installation procedure in wiki is up-to-date? i might want to reflash mine | 21:09 |
| freemangordon | sicelo: regarding n900 SOC - there is nothing we can reuse | 21:10 |
| freemangordon | BME is closed source, bme-replacement expects calibration | 21:11 |
| uvos | sicelo: installation procedure is up to date | 21:11 |
| uvos | tmlind: sec ill look for it | 21:11 |
| sicelo | thanks | 21:11 |
| uvos | tmlind: but really i was not anything special | 21:11 |
| uvos | i just took d4 dts from 5.8 or so with mapphone dtsi and removed all the non-essentials and then booted that | 21:12 |
| sicelo | freemangordon: ack | 21:14 |
| tmlind | uvos: ok i'll check the power sources for xt910 | 21:16 |
| uvos | woked ok with the regulator setup of d4 | 21:17 |
| uvos | iirc | 21:17 |
| uvos | at least for a basic boot once it dident explode :P | 21:17 |
| tmlind | ok cool, yeah if you have the patch or dts i'll give it a try at some point | 21:19 |
| uvos | yeah looking for it | 21:20 |
| tmlind | freemangordon, uvos: so with the battery calculation, can the coulomb counter measurement be used? it's a long term p = ui basically, i guess voltage and current still needs to be sampled for resistance estimate? | 21:21 |
| uvos | tmlind: i dont think the counter is usefull for estimation really, you could estimate once and then use the counter from there, but this will give worse results than just allways estimateing | 21:22 |
| uvos | so i dont see how it could be usefully used atm | 21:23 |
| tmlind | ok | 21:23 |
| uvos | well, if you get really fancy you could use the counter while callibrated to write a offset file that gives you a table of the differences between the output of the estimator and the real soc | 21:26 |
| uvos | and then use that when uncallibrated | 21:26 |
| uvos | (essentally create the soc table in the eeprom on the fly) | 21:26 |
| tmlind | yeah i guess | 21:28 |
| tmlind | i think the sampling times for the cpcap iio devices can be configured too if some average voltage or current is needed | 21:29 |
| uvos | oh really? | 21:30 |
| uvos | that would be great | 21:30 |
| tmlind | yeah there are some mystery hw values that seem to relate to the sample frequency and lenght possibly | 21:30 |
| sicelo | freemangordon: my n900 battery isn't calibrated, so i guess that's throwing that program off. anyway, https://paste.debian.net/1262323/ | 21:31 |
| uvos | sicelo: the point of this programm is to work with uncallibrated batteries | 21:32 |
| sicelo | ok | 21:34 |
| uvos | sicelo: its interesting | 21:35 |
| uvos | that you Ri values bounc around so mutch | 21:35 |
| * tmlind zzz | 21:40 | |
| uvos | gn8 | 21:40 |
| sicelo | /* use linear approx. below 3.756V => 50.00% assuming 3.3V => 0% */ ... at least the fg on n900 is programmed for 6% = 3.248V. that's when a calibration cycle completes | 21:46 |
| uvos | 50mV at low soc is mutch less than mesurement error here | 21:47 |
| uvos | so dosent matter | 21:47 |
| freemangordon | sicelo: yes, 'reported 0' is because it is not calibrated | 21:57 |
| freemangordon | but, it would have been good if you can run that on calibrated system | 21:58 |
| freemangordon | I want to see how well estimation behaves compared to real values | 21:58 |
| sicelo | yeah, to see how closely the calculation matches reality | 21:58 |
| sicelo | ack | 21:58 |
| freemangordon | right | 21:58 |
| freemangordon | hmm, how old is that battery? 10 years? | 21:59 |
| sicelo | what's 'r'? | 21:59 |
| freemangordon | currently calculated internal resistance | 21:59 |
| sicelo | i don't remember age. probably 2016 | 22:00 |
| freemangordon | I guess that's why it has so high Ri | 22:00 |
| sicelo | :-) | 22:01 |
| freemangordon | but yeah, it will be interesting to compare calculated vs calibrated | 22:01 |
| sicelo | and works good enough so far, despite n900 not doing pm with linux atm | 22:01 |
| freemangordon | anyway, zzz time, night! | 22:02 |
| sicelo | i'll try, but no promises (re: calibration) since i often need to remove the battery from device | 22:04 |
| vectis | Wizzup: Finally got bluetooth audio on the d4 working. I don't know if it was needed, but the last thing I changed was to install bluez-firmware. | 22:07 |
| Wizzup | vectis: good to know, there's a lot going on but glad to hear it works | 22:07 |
| Wizzup | (a lot going on for me, so I didn't do a write up yet) | 22:08 |
| vectis | Wizzup: No problem, I can see your very busy. | 22:09 |
| Wizzup | if you have some notes, please do share them | 22:09 |
| Wizzup | btw tmlind freemangordon - I didn't forward port the fb_id patch for the droid 4, let's see if we still need it for xorg | 22:10 |
| sicelo | btw, at least on N900, i noticed shutdown is very slow, compared to shutdown while running pmOS. it doesn't bother me, but it's quite curious | 22:16 |
| Wizzup | shutdown can be improved in many ways | 22:17 |
| uvos | it also still hangs on d4 for unkown reasons sometimes | 22:17 |
| sicelo | i believe modem is brought online by cellulard? what starts it, since it doesn't explicitly exist in /etc/runlevels | 22:20 |
| Wizzup | it should have an init script | 22:20 |
| Wizzup | /etc/init.d/cellulard ? | 22:20 |
| sicelo | really odd. even removing that ... system still bootloops (but not system with dead modem) | 22:31 |
| sicelo | i'll disable ofono to test, but just having ofono running doesn't cause issues in pmOS, and even list-modems is fine | 22:32 |
| Wizzup | sicelo: blacklist the module | 22:33 |
| Wizzup | icd2 also powered the modem iirc | 22:33 |
| Wizzup | it just doesn't manage online/offline | 22:34 |
| sicelo | oh, that could be it then. i just thought all this was now in cellulard :-) | 22:35 |
| uvos | Wizzup: freemangordon: so if i want to add new config stuff | 22:53 |
| uvos | that shal be set by a system settings applet | 22:54 |
| uvos | what shal i use? | 22:54 |
| uvos | gconf? gsettings? | 22:54 |
| uvos | something else? | 22:54 |
| uvos | Wizzup: freemangordon: https://github.com/maemo-leste/libhildonmime/pull/3 | 23:07 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
