| freemangordon | Wizzup: this is the upstream commit https://gitlab.gnome.org/GNOME/glib/-/commit/f065497acfbfe654369945054240918fcee001c3 | 08:07 |
|---|---|---|
| freemangordon | after that date I see only 2.7x.y tags, while chimaera is on 2.66.8 | 08:08 |
| freemangordon | Wizzup: I think the way it to add "-DGLIB_DISABLE_DEPRECATION_WARNINGS" to CI CFLAGS | 08:29 |
| freemangordon | *the way is | 08:29 |
| freemangordon | ther is also -DGTK_DISABLE_DEPRECATION_WARNINGS | 08:31 |
| freemangordon | see https://developer.gnome.org/documentation/tutorials/deprecations.html | 08:33 |
| freemangordon | -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_XX as well | 08:34 |
| freemangordon | Wizzup: any clue? https://github.com/maemo-leste/alarmd/blob/master/debian/control#L6 | 10:55 |
| freemangordon | It looks like an error to me | 10:56 |
| freemangordon | comes from https://github.com/maemo-leste/alarmd/commit/1412cc38d1c2764aaaabf831c1516fc358f8344e#diff-2a13f1344504379e877324d3a0375adcbcb4cb27d7e575ad8f4618a52d6a00e0R6 | 10:57 |
| freemangordon | going to remove | 10:57 |
| buZz | uvos: how/where did you add the ignore_temperature_probe=1 ? | 11:01 |
| buZz | i guess modprobe.conf | 11:03 |
| freemangordon | /etc/modprobe.d/ | 11:05 |
| freemangordon | buZz: ^^^ | 11:05 |
| buZz | right, i made a new file, wrote 'options cpcap_battery ..' etc | 11:07 |
| freemangordon | BlagovestPetrov[: deprecation issues should be fixed, please upgrade your VM and pull latest source code for systemui etc | 11:07 |
| BlagovestPetrov[ | thanks :) | 11:08 |
| Wizzup | freemangordon: ok, I can do that | 11:17 |
| Wizzup | @ glib build flag | 11:17 |
| Wizzup | so we take upstream and add your patch? | 11:17 |
| Wizzup | looks like it's fixed | 11:18 |
| Wizzup | ? | 11:18 |
| sicelo | Wizzup: fun, https://lore.kernel.org/lkml/20221123124620.1387499-1-gregkh@linuxfoundation.org/t/ | 11:19 |
| * sicelo hides | 11:19 | |
| Wizzup | sicelo: lol | 11:20 |
| sicelo | anyway, it remains to be seen how this will end | 11:26 |
| freemangordon | Wizzup: umm, I already fixed https://github.com/maemo-leste/gtk/commit/05cac570ece595db9e459e9c3b62198018faa5ff | 11:39 |
| freemangordon | however, this does not mean we don;t need to ship glib with https://gitlab.gnome.org/GNOME/glib/-/commit/f065497acfbfe654369945054240918fcee001c3 backported | 11:40 |
| freemangordon | could you please pull chimaera glib in our repo? | 11:41 |
| freemangordon | the same way beowulf was pulled | 11:41 |
| freemangordon | do you know where this https://github.com/maemo-leste-upstream-forks/glib was forked from? | 11:42 |
| Wizzup | ok, let me check | 11:58 |
| freemangordon | I guess debian salsa or somesuch | 12:06 |
| Wizzup | freemangordon: yeah just gimme a sec | 12:09 |
| Wizzup | I was not at keyboard | 12:09 |
| Wizzup | https://salsa.debian.org/gnome-team/glib | 12:09 |
| Wizzup | https://packages.debian.org/source/bookworm/glib2.0 | 12:10 |
| Wizzup | https://salsa.debian.org/gnome-team/glib/-/tree/debian/bullseye | 12:10 |
| Wizzup | doesn't seem to be what's actually in bullseye | 12:11 |
| Wizzup | lol | 12:11 |
| Wizzup | https://salsa.debian.org/gnome-team/glib/-/commits/debian/master this I guess | 12:11 |
| Wizzup | freemangordon: what made you say chimaera is on 2.66.8? | 12:13 |
| freemangordon | libglib2.0-0:amd64 2.66.8-1 | 12:14 |
| freemangordon | dpkg -l | grep glib | 12:14 |
| Wizzup | ah! | 12:19 |
| Wizzup | I was looking at bookworm somehow | 12:19 |
| Wizzup | so this then https://salsa.debian.org/gnome-team/glib/-/commits/debian/bullseye | 12:20 |
| Wizzup | freemangordon: so shall I do it? | 12:25 |
| Wizzup | done.. | 12:32 |
| Wizzup | (testing build now) | 12:32 |
| Wizzup | ah, the patch doesn't apply cleanly :) | 12:33 |
| Wizzup | imagine if this was just in git somehow, and we wouldn't have to deal with quilt :D | 12:33 |
| Wizzup | --static guint n_desktop_file_dirs; | 12:37 |
| Wizzup | freemangordon: this is gone from new glib | 12:37 |
| Wizzup | it seems relatively trivial to update the patch, but I won't do it right now, I'll push my wip | 12:39 |
| Wizzup | freemangordon: pushed to maemo/chimaera, please take a look at the build fail when you can, otherwise I can do it in ~30-60 mins | 12:40 |
| freemangordon | Wizzup: we better backport upstream patch | 12:55 |
| freemangordon | I'll do it | 12:57 |
| Wizzup | freemangordon: ok, everything else is set, it just needs a better patch, feel free to rebase and push -f | 13:11 |
| freemangordon | trying to build it in the VM now | 13:13 |
| freemangordon | Wizzup: and what about the other patch? | 13:16 |
| freemangordon | the one that fixes issues on 64bit? | 13:16 |
| freemangordon | was it already in beowulf? | 13:17 |
| Wizzup | freemangordon: I didn't see it in maemo/beowulf | 13:25 |
| Wizzup | maybe it was merged already | 13:25 |
| freemangordon | yeah, that was my question - was it already merged :) | 13:25 |
| Wizzup | probably an ascii thing really :) | 13:26 |
| Wizzup | so yes, I think so | 13:26 |
| freemangordon | ok | 13:27 |
| freemangordon | trying to build glib in CI | 13:27 |
| freemangordon | lets see | 13:27 |
| Wizzup | you fixed the patch then? | 13:27 |
| freemangordon | in my VM it failed in the packaging part | 13:27 |
| Wizzup | where? | 13:28 |
| Wizzup | I'll build it now | 13:28 |
| Wizzup | I cherry-picked + fixes your patches, but might have missed something | 13:28 |
| freemangordon | dh_dwz: error: Requested unknown package libglib2.0-udeb via -N/--no-package, expected one of: libglib2.0-0 libglib2.0-tests libglib2.0-bin libglib2.0-dev libglib2.0-dev-bin libglib2.0-data libglib2.0-doc | 13:28 |
| freemangordon | I dropped beowulf patch and used the upstream one instead | 13:28 |
| Wizzup | ok, yeah, let me fix that | 13:28 |
| Wizzup | I don't think we need to test this in CI really | 13:28 |
| Wizzup | it will fail there too | 13:28 |
| Wizzup | I see the problem in rules I think | 13:29 |
| freemangordon | Wizzup: https://github.com/maemo-leste-upstream-forks/glib/commit/b2294e491ec2bdb91084edc2506e0ee0db689bde | 13:31 |
| Wizzup | tests running atm | 13:31 |
| freemangordon | Wizzup: what about https://phoenix.maemo.org/job/glib-source/9/consoleText | 13:32 |
| freemangordon | ? | 13:32 |
| Wizzup | let me fix udeb first | 13:32 |
| freemangordon | ok | 13:32 |
| Wizzup | I think I have it fixed locally but it's running tests forever | 13:32 |
| Wizzup | 19156985 tests passed, 0 failed pfew | 13:33 |
| freemangordon | :) | 13:33 |
| Wizzup | freemangordon: shall I merge your upstream patch with the one I tried to forward port, so that we don't have a bad patch in history? | 13:34 |
| freemangordon | squash 2 commits? | 13:35 |
| freemangordon | up to you | 13:35 |
| Wizzup | ok | 13:35 |
| freemangordon | in the meanwhile gbp:error: File contains no section headers. | 13:35 |
| Wizzup | I will fix gbp.conf too | 13:35 |
| freemangordon | ok | 13:35 |
| Wizzup | one thing at a time | 13:35 |
| Wizzup | these tests take forever | 13:35 |
| freemangordon | yeah | 13:36 |
| freemangordon | gbp.conf is missing [DEFAULT] on top | 13:38 |
| Wizzup | yes, I know | 13:40 |
| Wizzup | so I didn't get the udeb issue but I changed the rules file during build | 13:40 |
| Wizzup | force-pushed, let's build | 13:42 |
| Wizzup | I'll start it | 13:43 |
| freemangordon | ok | 13:45 |
| Wizzup | running atm | 13:47 |
| freemangordon | looks fine | 14:09 |
| Wizzup | yup | 14:12 |
| Wizzup | ty | 14:12 |
| buZz | i wonder, -can- charge_full even be above charge_full_design ? | 15:14 |
| sicelo | it should generally not | 15:19 |
| buZz | i think this prevents it ; https://github.com/maemo-leste/droid4-linux/blob/maemo-6.1/drivers/power/supply/cpcap-battery.c#L878 | 15:21 |
| buZz | but i now have a 1750mAh reporting BMS , on a 2250mAh battery :) | 15:21 |
| buZz | considering my options here , i could just make charge_full_design writeable? :D | 15:22 |
| buZz | or eh, add a option to charge beyond charge_full_design | 15:24 |
| buZz | oh, 6*x/5 , it allows ~20% higher | 15:25 |
| buZz | i wonder whats the motivation for the 20% , if we could stretch that to 30% , 2250 would fit :P | 15:28 |
| buZz | maybe (4*x)/3 ? | 15:30 |
| tmlind | buZz: maybe add a module option to use a generic battery and ignore the eeprom? | 15:30 |
| tmlind | or a module option to force e960 battery, then we could have a proper profile for it | 15:31 |
| buZz | hmm, well, atm its still charging, takes forever :P | 15:32 |
| buZz | and i'll make charge_full be 2088000 for now (the max this 6/x*5 allows) | 15:34 |
| tmlind | buZz: how about modprobe cpcap-battery batt_type=polarcell_lg_e960 or something similar | 15:37 |
| tmlind | then ignore eeprom, keep the temp sensor in case it's wired to the eb41 pcb | 15:38 |
| tmlind | then additionally ignore_temperature_probe=1 option can be used if using uvos' pcb | 15:39 |
| buZz | would be nice yeah, but this is not my area of expertise :P | 15:39 |
| buZz | a batt_type would be best i guess | 15:40 |
| tmlind | uvos: would the above work for you for module options? | 15:40 |
| Wizzup | freemangordon: sapwood has a commit in -devel that's not in normal beowulf, I think we can move that to normal beowulf, yeah? | 15:46 |
| Wizzup | dsme needs some fixes, will do when I get back | 15:52 |
| Wizzup | Pali: I think I need some help with the u-boot thing that Tom is asking about, I really don't know where to start | 16:59 |
| Pali | hm... I just do not know where to start too... Maybe asking Tom for that? | 17:18 |
| sicelo | OAOB | 17:20 |
| uvos | tmlind: sure yeah @ options | 17:53 |
| uvos | buZz: for now just blacklist the one wire interface module | 17:53 |
| uvos | that way you will not get 1750mAh as charge_full_design instead you will get something really high | 17:54 |
| uvos | the 20% comes from me estimateing how far the callibration may undereport the real capapacity of the battery | 17:55 |
| freemangordon | unless the battery is charged @ 4.35, 1750 is a good estimation | 17:56 |
| freemangordon | mine calibrates @ 1594 | 17:56 |
| Wizzup | uvos: btw I think we might have pm regressions, will need some time to confirm properly | 17:56 |
| uvos | im dose 1800 so yours is a bit wierd | 17:56 |
| uvos | but yeah 1700 is resonable estimation | 17:56 |
| uvos | +-20% especcaly | 17:57 |
| uvos | tollerance | 17:57 |
| freemangordon | uvos: +1 on the PM regressions | 17:57 |
| uvos | as cpcap dose offer | 17:57 |
| buZz | uvos: oh right! thats simple :P | 17:57 |
| freemangordon | uvos: BTW, charge-mode bug appears every time device is connected to charger after low-battery power down | 17:58 |
| freemangordon | please give me some hints how to debug | 17:58 |
| freemangordon | are there logs or something | 17:58 |
| uvos | not really, i would write a wpa_supplicant conf and connect wifi and start ssh before chargeing_sdl starts | 17:59 |
| uvos | then just ssh in and look around | 17:59 |
| uvos | freemangordon: Wizzup: ok, mine has idled at 100mW all day, so im not really seeing it, but ofc this is power_avg, not external mesurement | 17:59 |
| buZz | uvos: is it hdq1w ? | 17:59 |
| uvos | buZz: yes | 17:59 |
| buZz | alright | 17:59 |
| freemangordon | uvos: what to look for? device charges fine, it is just that battery animation stays at one red line and if you deisconnect the charger device is shut down | 18:00 |
| uvos | ok | 18:01 |
| freemangordon | maybe cpcap-battery is probed *after* chargeing_sdl is started? | 18:01 |
| uvos | freemangordon: should not be possible, probing happens afaik shound happen within sysinit | 18:01 |
| uvos | and charging_sdl runs after sysinit | 18:01 |
| uvos | but maybe this is me miss interpreting how openrc should behave | 18:02 |
| uvos | also idk why it should probe later when the battery is low | 18:02 |
| uvos | i gues when poking around: | 18:02 |
| uvos | check if the cpcap sysfs files are resonable | 18:02 |
| freemangordon | I don;t think EPROBE_DEFER has anything to do with runlevels | 18:02 |
| uvos | right defer true | 18:03 |
| uvos | but i think sysinit waits until udev sais its ready | 18:03 |
| uvos | dunno how defer interacts with udev really | 18:03 |
| buZz | hmmz, i added 'blacklist hdq1w' to blacklist-idle.conf , still reading 1740mAh from eeprom it seems | 18:04 |
| uvos | really charging_sld is really simple code wise so i dont quite see how it could missbehave, other than wat you said or cpacp driver misbehaveing. | 18:04 |
| uvos | its callded omap_hdq1w or something like that | 18:05 |
| uvos | iirc | 18:05 |
| buZz | oh | 18:05 |
| freemangordon | buZz: lsmod is your friend | 18:05 |
| buZz | omap_hdq , right | 18:05 |
| buZz | :) | 18:05 |
| uvos | freemangordon: btw | 18:06 |
| uvos | you can runn charging_sdl after boot too | 18:06 |
| uvos | just to check if it behaves ok then too | 18:06 |
| uvos | it has flags to be run in a window in x11 | 18:06 |
| freemangordon | I think it needs some logs added here and there | 18:07 |
| uvos | it logs some stuff | 18:07 |
| uvos | but only to stdout | 18:07 |
| freemangordon | where? | 18:07 |
| uvos | so you could save that somehwere | 18:07 |
| uvos | its not captured in the initscript afaik | 18:07 |
| uvos | you could do that | 18:07 |
| uvos | but it dosent log mutch more than the battery percent | 18:07 |
| freemangordon | it logs to stdout? | 18:08 |
| uvos | which its also showing you | 18:08 |
| uvos | yeah | 18:08 |
| uvos | so it prints to stdout | 18:08 |
| buZz | could put a >> charging_sdl.log on it | 18:08 |
| uvos | you could redirect that somewhere | 18:08 |
| freemangordon | well, I can put some printfs here and tehre | 18:08 |
| uvos | sure | 18:08 |
| freemangordon | ok | 18:08 |
| freemangordon | will do | 18:08 |
| uvos | for one thing | 18:08 |
| freemangordon | oh, I was about to try to implement SOC estimation based on the voltage | 18:08 |
| uvos | whenever charging_sdl runs | 18:08 |
| uvos | pvrk compains about something | 18:09 |
| uvos | might be related to the eventual hang | 18:09 |
| freemangordon | hmmm | 18:09 |
| buZz | ah yez | 18:09 |
| freemangordon | ok, will check | 18:09 |
| freemangordon | where did you get that code from? | 18:09 |
| uvos | charging_sdl? | 18:09 |
| freemangordon | mhm | 18:09 |
| uvos | its from pmos | 18:09 |
| uvos | but i also added quite some stuff | 18:09 |
| uvos | not sure what part of it your asking about | 18:10 |
| freemangordon | I asked in general | 18:10 |
| buZz | ah, meh, blacklisting omap_hdq prevents charging to 4.35v | 18:10 |
| freemangordon | makes sense, no? | 18:10 |
| buZz | welp, beats my purpose anyway :P | 18:10 |
| uvos | sure but i gues he dosent want that | 18:10 |
| buZz | yes i do, obviously :D | 18:11 |
| freemangordon | we *will not* allow you to charge non-HV lipo to 4.35 | 18:11 |
| buZz | right, thats fine | 18:11 |
| buZz | i just want to charge this HV lipo to 4.35 :P | 18:11 |
| freemangordon | I dodn;t get why did you remove 1wire protocol driver | 18:11 |
| freemangordon | *didn't | 18:11 |
| freemangordon | what is the issue? | 18:11 |
| uvos | he has a eb41 pcb/eeprom | 18:12 |
| uvos | on a larger battery | 18:12 |
| uvos | cpcap will discard the callibration | 18:12 |
| uvos | if its to larg | 18:12 |
| buZz | ah, well, cpcap_battery prevents to calibrate the battery to >120% of charge_full_design | 18:12 |
| uvos | ie mutch larger than max_design | 18:12 |
| freemangordon | ah | 18:12 |
| buZz | yeah well, its 28% more | 18:12 |
| freemangordon | well, I guess that shall be fixed in the driver | 18:12 |
| uvos | or you could | 18:12 |
| uvos | you know, change the eeprom | 18:13 |
| buZz | its writeable? | 18:13 |
| freemangordon | isn't it OTP? | 18:13 |
| uvos | idk | 18:13 |
| freemangordon | wait, there are checksums as well | 18:13 |
| buZz | the suggestion was adding a battery definition to override | 18:13 |
| uvos | freemangordon: true but we dont care | 18:13 |
| uvos | so for android yeah | 18:13 |
| freemangordon | yes, we care as android will refuse to charge | 18:13 |
| uvos | sure but buzz might not care about android | 18:13 |
| uvos | this is about a now solution | 18:13 |
| freemangordon | well, yeah | 18:14 |
| uvos | so check if the eeprom is writeable | 18:14 |
| freemangordon | buZz: right, you may try to write | 18:14 |
| buZz | hehe well, its 2088mAh now | 18:14 |
| uvos | and just change the value of so | 18:14 |
| freemangordon | buZz: see driver code for the offset and the value you have to write | 18:15 |
| freemangordon | uvos: btw, what is the rationale behind that 120% restriction? | 18:16 |
| uvos | the callibration sometimes goes totaly bonkers here | 18:16 |
| uvos | if you charge and discarge and charge again | 18:16 |
| uvos | the errors of the charge counter accumulate | 18:16 |
| uvos | its to prevent absurd values form being accepted | 18:17 |
| freemangordon | yeah, voltage based SOC it is | 18:17 |
| uvos | motorola came to same conclusion i gues | 18:17 |
| freemangordon | not only, BME does the same | 18:17 |
| freemangordon | so, I will ask upstream upower if they are willing to accept something like that | 18:18 |
| sicelo | buZz: btw did you upstream the droid4 keymap? | 19:01 |
| tmlind | buZz: if you really want to charge it to 4.35 volt, first change the battery max voltage in sysfs to 4.35, then set the max charger voltage to 4.35 | 19:21 |
| bencoh | do we default to 4.2V now? | 19:21 |
| freemangordon | tmlind: by looking at the code, that should happen automagically if you set the voltage in the charger driver. is that a bug that it does not happen? | 19:21 |
| tmlind | freemangordon: it's that way because of the bloated batteries we had folks report earlier | 19:23 |
| freemangordon | tmlind: maybe I didn;t explain it correctly: | 19:23 |
| freemangordon | IIUC, in charger driver there is a code that set battery driver limit as well | 19:24 |
| freemangordon | so, when you set charger limit to 4.35, it sets battery driver limit to 4.35 as well | 19:24 |
| freemangordon | for some reason this does not work | 19:24 |
| freemangordon | or, I don;t understand how it is supposed to work | 19:24 |
| tmlind | first echo the new desired max value to the battery/constant_charge_voltage | 19:25 |
| tmlind | then allow the charger to use it by echo to usb/constant_charge_voltage | 19:25 |
| freemangordon | yes, but that's not what I am talking about | 19:25 |
| freemangordon | anyway | 19:25 |
| tmlind | well we don't want to allow the charger to set the charge voltage higher unless the allowed battery voltage is configured first | 19:27 |
| freemangordon | ok, but shouldn;t allowed voltage be tied to design voltage? | 19:27 |
| freemangordon | or at least set to design voltage on probe? | 19:27 |
| tmlind | no.. at least i have zero interest ruining my batteries after few monts of connected to a dock or lapdock | 19:28 |
| freemangordon | it will still default to 4.2 | 19:28 |
| freemangordon | because of the charger default | 19:28 |
| tmlind | yeah that's good | 19:28 |
| freemangordon | but having to change 2 things in a special sequence just to charge a battery to a voltage it is designed for lokks like an overkill to me | 19:29 |
| freemangordon | *looks | 19:29 |
| tmlind | no it's not in this case :) | 19:29 |
| freemangordon | also, I would say that holding a mobile phone on a dock for months is not what usually happens to mobiles ;) | 19:30 |
| freemangordon | so this is an edge use-case that shall be taken care of in the charger diver, perhaps, but not a reason to not charge to full capacity | 19:31 |
| freemangordon | but lets not go into that now | 19:31 |
| tmlind | well we don't know how long it takes, few weeks or few months it seems. anything higher than 4.2v you really need to do a statiscically meaningful test for let's say a year to prove that the batteries don't bloat.. so pretty much impossible :) | 19:31 |
| freemangordon | I am much more concerned that neither sre nor greg reply :( | 19:32 |
| tmlind | i'm mostly concerned about people ruining their batteries | 19:32 |
| freemangordon | tmlind: when (and if) it comes to it I will send a patch that fixes that (like I already proposed, it will be really easy to wait for voltage dropping < 4.2 before starting charging again) | 19:33 |
| freemangordon | it will take couple of weeks for that to happen if device is connected to a charger all the time | 19:33 |
| freemangordon | actually, as uvos said, we *must* do the same for 4.2 batteries | 19:34 |
| tmlind | yeah 4.2v batteries probably should have some lower maintenance charge voltage | 19:35 |
| freemangordon | which we don't, basically ruining batteries of those users that did not replace their aged original ones with ordinary LiPo batteries | 19:35 |
| freemangordon | if they keep them connected to a charger that is | 19:36 |
| freemangordon | so, I will make/send a patch for cpcap-charger | 19:36 |
| tmlind | hmm yeah bionic has 4.2v battery, but not sure if that too has had bloating issue | 19:36 |
| freemangordon | why it shouldn't? | 19:37 |
| tmlind | but please not we are not going to enable 4.35v charge by default without proper proof of it not bloating people's batteries | 19:37 |
| freemangordon | we start charging almost immediatelly after full is hit | 19:37 |
| freemangordon | tmlind: as I said, I'll make a patch when and if it comes to it and will try to convinc you and whoever has doubts that it will be ok | 19:38 |
| freemangordon | but, before that I want to understand what the hell is going on and why a simple 2-liner takes 3 weeks to get a "send v2" | 19:38 |
| freemangordon | or, why sre replies to other mails but not mine | 19:39 |
| tmlind | well you need to prove it somehow | 19:39 |
| buZz | tmlind: yeah , https://space.nurdspace.nl/~buzz/maemo/bermbom.sh | 19:40 |
| freemangordon | charger? | 19:40 |
| tmlind | and it might be that it will now just take a lot longer to ruin the battery | 19:40 |
| freemangordon | well, if lot longer is 10 years, I would say we are ok | 19:40 |
| freemangordon | no? | 19:40 |
| buZz | atm it seems the BMS came loose from the cell, having a hard time getting it connected back | 19:40 |
| buZz | might just leave it as-is and fix it later | 19:40 |
| tmlind | freemangordon: 30 devices connected to a charger for a year and i'll be happy :) | 19:42 |
| freemangordon | tmlind: I think I can can easily prove we are fine once I have measured the time needed for a battery to self-discharge to (made-up value) 96% of its design max voltage | 19:43 |
| freemangordon | tmlind: not really needed | 19:43 |
| tmlind | in any case the logic can be there for sure, let's just not enable it unless the user really wants to do it | 19:43 |
| tmlind | note that motorola was in business of selling accessories and batteries, they do not need them to last very long | 19:44 |
| freemangordon | so, if it takes 2 weeks, you will have 24 charge cycles 4.176->4.35 fo year | 19:44 |
| freemangordon | yet those 10yo batteries keep like 900mAh capacity | 19:45 |
| freemangordon | so I would say they did it right for the usual mobile-phone use case | 19:45 |
| tmlind | hmm yeah that's a good point, if the discharge to a maintenance voltage takes so long that charge cycles are very limited | 19:46 |
| freemangordon | I don;t see why not, given that DCP charger detection works :) | 19:46 |
| tmlind | the first bloated case i heard of was android baby monitor use case | 19:46 |
| freemangordon | so device can be fully supplied by the charger only and battery only self-discharges | 19:47 |
| tmlind | anyways, stuff to discuss on the mailing lists | 19:47 |
| freemangordon | also, a dock can be easily detected and different ruls applied there | 19:47 |
| freemangordon | sure | 19:47 |
| freemangordon | the point was that we don;t really need 30 devices and a year to prove :p | 19:48 |
| tmlind | well we should treat all the chargers the same | 19:48 |
| freemangordon | how's that? | 19:48 |
| freemangordon | USB(SDP) - max 500mA | 19:48 |
| freemangordon | DCP - 1800 | 19:48 |
| tmlind | well take the baby monitor example, and no dock. or a trail cam use case (once the camera works) | 19:49 |
| freemangordon | ACA - we have to measure the ID pin to detect what max charging current we can draw | 19:49 |
| freemangordon | tmlind: baby monitor connected to a charger (1500mA min) is perfectly fine | 19:49 |
| freemangordon | because battery will only do self-discharge | 19:50 |
| freemangordon | as the highest current reading I was able to measure here was about 1600 mA | 19:50 |
| tmlind | well that's a theory :) i want to see some real tested-by for a long time for sure in this case | 19:50 |
| freemangordon | hehe :) | 19:51 |
| freemangordon | but yeah, you are right, this is to be discussed over the ML | 19:51 |
| freemangordon | if there is anyone but you to discuss with there | 19:51 |
| freemangordon | I am really worried about the silence | 19:52 |
| tmlind | nah, just people busy with dealing with all the patches | 19:52 |
| freemangordon | will see | 19:52 |
| tmlind | pavel had some strong opinions too about the min and max voltages to preserve batteries | 19:53 |
| freemangordon | I would love to hear his opinions | 19:53 |
| freemangordon | but really, we need charger detection first working | 19:53 |
| freemangordon | before that | 19:53 |
| tmlind | yeah maybe search lore.kernel.org, i think he had some links to too there | 19:55 |
| freemangordon | tmlind: did you see https://www.spinics.net/lists/linux-usb/msg233614.html ? | 19:56 |
| freemangordon | with your maintainer hat on, what am I supposed to do there? | 19:56 |
| freemangordon | fixx the drivers and framework and send a new patch? | 19:57 |
| tmlind | yeah i don't know, it's like all the folks dealing with mobile charging disappeared 10 years ago | 20:02 |
| tmlind | it's like nothing has happened to make things better? | 20:03 |
| tmlind | kind of like the same story as with modem support stuff.. | 20:03 |
| freemangordon | see, it is not that I expect anything but what upstream will accept. once I know what it is, I will send a patch. | 20:05 |
| tmlind | yeah sorry no idea how it should be done for the charger detection.. | 20:05 |
| tmlind | android probably does this all in userspace? | 20:06 |
| freemangordon | yes | 20:07 |
| freemangordon | afaik | 20:08 |
| freemangordon | with the exception that it has extcon driver to detect charger types | 20:09 |
| freemangordon | in android it seems to be called "swith" or something | 20:09 |
| freemangordon | *switch | 20:09 |
| freemangordon | it reports what is connected to the userspace and userspace set max current in the charger driver | 20:10 |
| freemangordon | IIUC | 20:10 |
| tmlind | ok | 20:16 |
| vectis | Hi all. I'm trying to get my D4 to connect to various audio devices that I have with bluetooth, but I can never get connected. I can pair with the devices but when trying to connect, bluetooth manager complains about a protocol not being available. | 21:06 |
| Wizzup | hi | 21:09 |
| Juest | hi, been a few years :) | 21:10 |
| Wizzup | vectis: so... | 21:10 |
| Wizzup | vectis: there's a few things | 21:10 |
| Wizzup | vectis: first, you need to set it to phone class, and then secondly, you need to load the module | 21:11 |
| Wizzup | I have some notes, I'll publish them this week | 21:11 |
| Wizzup | vectis: https://wizzup.org/bluetooth-car.mp4 | 21:11 |
| vectis | Wizzup: I saw the video and that prompted me to try myself. How do you set it to "phone class"? Is the module the pulse one? | 21:14 |
| Wizzup | it's in my notes, sec | 21:15 |
| Wizzup | vectis: Class = 0x005a020c | 21:15 |
| Wizzup | in /etc/bluetooth/main.conf | 21:15 |
| vectis | Wizzup: Thanks, I'll give it a try. | 21:17 |
| Juest | there's no generic image other than virtual machines still? | 21:20 |
| freemangordon | what is "generic image"? | 21:24 |
| freemangordon | a kind of installer? | 21:24 |
| Juest | there's arm64-generic, how about x86_64? | 21:25 |
| Juest | generic as in platform | 21:25 |
| vectis | Wizzup: Still can't connect. | 21:31 |
| Juest | i mean, amd64 and x86 images for running on bare metal devices to be more correct | 21:38 |
| Juest | generic as in device kind* | 21:39 |
| Juest | sorry for the weird wording | 21:39 |
| Wizzup | vectis: can help tomorrow | 21:41 |
| vectis | Wizzup: np :) | 21:43 |
| sicelo | Wizzup: N900 bootloops on Leste with linux 6.1 | 21:54 |
| uvos | sicelo: yeah same here | 21:55 |
| sicelo | oh, i thought you were not aware | 21:55 |
| uvos | Juest: for bare-metal x86 you should be able to just install minimal devuan and install our metapackage | 21:56 |
| uvos | idk if anyone has treid this recently thoug | 21:56 |
| Juest | i can try that i guess | 21:56 |
| Juest | shouldn't it be the same as the virtual machine images? | 21:57 |
| uvos | result should be pretty mutch the same | 22:04 |
| uvos | but ofc you have the benefit of all the stuff the devuan installer provides | 22:04 |
| uvos | functionality wise | 22:04 |
| Wizzup | sicelo: want me to get a trace then? | 22:06 |
| uvos | Wizzup: so do you have an easy way to mesure power consumption | 22:29 |
| uvos | difference in 6.1 that is | 22:29 |
| Wizzup | uvos: well the phone just doesn't really last 2-3 days anymore :) | 22:43 |
| Wizzup | but I don't have my accurate psu here atm | 22:44 |
| uvos | well ok | 22:44 |
| uvos | the compaction timers changed some | 22:44 |
| uvos | im wondering if its related | 22:44 |
| Wizzup | my patch nerfing them is gone, or? | 22:44 |
| uvos | no should be there | 22:44 |
| uvos | but they changed how the timers work | 22:44 |
| uvos | but lets try this: | 22:44 |
| uvos | https://github.com/maemo-leste/leste-config/pull/32 | 22:45 |
| uvos | probubly this is not it tho | 22:46 |
| uvos | but either way we should have this in leste config | 22:46 |
| uvos | anyhow n900 not booting | 22:46 |
| uvos | we need some serial here | 22:46 |
| uvos | or maybe comparing patches with a 6.1 that dose boot | 22:47 |
| uvos | sicelo have a repo? | 22:47 |
| Wizzup | I can help tomorrow | 22:51 |
| uvos | Wizzup: omapconf is not anny less happy than 5.18 | 22:53 |
| uvos | so likely its extra activity of some kind | 22:53 |
| uvos | freemangordon: btw it cant be the probe order with charging-sdl | 23:04 |
| uvos | it opens and closes the files every time it samples the files | 23:04 |
| uvos | so a failure to open the sysfs files the first time would not cause it to fail to work later | 23:05 |
| sicelo | https://gitlab.com/sicelo/pmaports/-/tree/rx51-6.1/device/community/linux-nokia-n900 ... working linux 6.1-rc6 for Nokia N900 | 23:23 |
| uvos | ok there are some extra patches in there we dont have, and we have extra patches not in there | 23:35 |
| uvos | we dont have an equiavlent to 0005-kernel-dma-workaround-n900-modem-oops.patch | 23:37 |
| uvos | but you told me that allready and this should not cause it to not boot | 23:37 |
| uvos | same with 0006-bus-ti-sysc-Add-otg-quirk-flags-for-omap3-musb.patch | 23:37 |
| uvos | and 0009-Revert-partially-Revert-usb-musb-Set-the-DT-node-on.patch | 23:38 |
| uvos | we also dont have 0003-ARM-dts-N900-use-iio-driver-for-accelerometer.patch | 23:38 |
| uvos | but thats def irrelivant | 23:38 |
| uvos | but we have lots of extras too | 23:38 |
| uvos | enable modem and increase cma size, make watchdog built in, tsc2005: disable irqs on suspend, n900: camera: magic bit makes it work, et8ek8: Support for EXPOSURE_ABSOLUTE | 23:39 |
| uvos | so i gues ill sync it up | 23:40 |
| uvos | tomorrow | 23:40 |
| uvos | ttyl | 23:40 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!