| freemangordon | Wizzup: will you have time to test my modem shutdown patch? I will provide kernel/modules | 07:24 |
|---|---|---|
| freemangordon | Wizzup: http://46.249.74.23/leste/d4/modem_patch/ | 08:16 |
| freemangordon | hmm, seems battery applet either does not get or ignores th elow signal | 09:33 |
| freemangordon | I see no "battery low" warnings, despite the kernel signals | 09:34 |
| uvos__ | must have broken very recently | 09:39 |
| uvos__ | as it def used to work | 09:39 |
| freemangordon | uvos__: yeah, will try to find what's going on | 11:31 |
| buZz | now that we have omap_hdq loaded again, shouldnt we also have the new kernel? | 11:57 |
| buZz | or was why we blacklisted it invalid in general? even on the older kernel | 11:57 |
| freemangordon | because it was causing power draw with the default parameters | 12:07 |
| freemangordon | for the new kernel - there is a bug I introduced in cpcap-battery, want to have that fixed first | 12:08 |
| freemangordon | and modem driver fix needs testing | 12:09 |
| buZz | the modem shutdown you linked before? | 12:14 |
| freemangordon | yes | 12:22 |
| Wizzup | uvos__: btw, how do I best preserve the batteries for the all the d4s? | 12:33 |
| Wizzup | leave them empty? | 12:33 |
| uvos__ | 40-60% soc | 12:33 |
| uvos__ | as with all lipos | 12:34 |
| uvos__ | (state of charge) | 12:34 |
| Wizzup | ok | 12:34 |
| Wizzup | won't they drain over a few weeks? | 12:34 |
| uvos__ | no | 12:34 |
| uvos__ | the will drain | 12:34 |
| uvos__ | but it takes very long | 12:35 |
| uvos__ | if you dont have one | 12:35 |
| uvos__ | buy a rc charger imax b6 or so | 12:35 |
| uvos__ | those can parallel storage charge lots of batteries at a time | 12:35 |
| Wizzup | ok | 12:36 |
| uvos__ | they have open source fw are programmable and can also drain, i would have the battiers at storage voltage | 12:36 |
| uvos__ | and then use it to discarge to 10% before sending the stuff to people per mail | 12:37 |
| uvos__ | thats the ideal way of doing things anyways | 12:37 |
| uvos__ | any of the ones supported by this https://github.com/stawel/cheali-charger would be good charger wise, dosent have to be a b6 | 12:38 |
| Wizzup | The imax b6 sounds fine | 12:49 |
| uvos | carefull there are chinese fakes | 12:51 |
| Wizzup | I was looking at buying it from a dutch shop | 12:53 |
| Wizzup | https://www.shogun.nl/imax-b6ac-multilader-nimh-lipo.html | 12:53 |
| uvos | ok | 12:53 |
| uvos | just dont buy from aliexpress or ebay (generally) most are fake | 12:53 |
| Wizzup | ok | 12:53 |
| uvos | thats the ac variant (thats fine) | 12:53 |
| Wizzup | they seem to look different even on some dutch shops | 12:54 |
| Wizzup | https://www.bol.com/nl/nl/p/imax-b6ac-v2-professional-balance-charger-discharger/9200000125024248/ | 12:54 |
| uvos | yeah no idea sorry, as you can imagine i bought mine like 15 years ago (at hobbyking) | 12:56 |
| uvos | they still have it https://hobbyking.com/de_de/skyrc-imax-b6-v2-60w-6a-1-6s-dc-charger-discharger.html?queryID=9641dbd193598df54f2d5d8e5f2b28f4&objectID=85860&indexName=hbk_live_products_analytics | 12:56 |
| uvos | this one is real for sure | 12:57 |
| uvos | well mine isent a v2 | 12:57 |
| uvos | not sure what the difference is | 12:57 |
| Wizzup | this also says skyrc: https://www.bol.com/nl/nl/p/imax-b6ac-v2-professional-balance-charger-discharger/9200000125024248/ | 12:57 |
| Wizzup | weird, ok, yeah | 12:58 |
| Wizzup | funny how it's much cheaper @ hobbyking | 12:58 |
| freemangordon | isn't 3.7/3.8 V the 'transport' voltage a battery shall be charged to before being put on the shelf? | 12:58 |
| uvos | its 40-60 soc | 12:58 |
| uvos | but yeah thats around that voltage wise | 12:58 |
| freemangordon | 3.7 for normal, 3.8 for HV | 12:59 |
| uvos | there are other chemistries too | 12:59 |
| uvos | life etc | 12:59 |
| uvos | but yes | 12:59 |
| freemangordon | yeah, I am talking about 'normal' ones | 12:59 |
| freemangordon | li-ion/li-po | 13:00 |
| freemangordon | point is that it is hard to charge 40-60% without knowing the capacity ;) | 13:00 |
| uvos | the chargers mesure it :) | 13:01 |
| freemangordon | don't they need a full recharge cycle? | 13:01 |
| uvos | yeah they do that (its an option anyways) | 13:01 |
| uvos | you can also tell it | 13:01 |
| freemangordon | not really, for 10yo battery :) | 13:01 |
| freemangordon | what am I trying to say is that it is way easier to charge to 3.7 or 3.8 and call it a day | 13:02 |
| Wizzup | sure, but for 60+ batteries it's nice to have a device do it for you | 13:03 |
| Wizzup | as opposed to running leste on all just to get it to a certain point etc | 13:03 |
| uvos | welli gues you could wirte a userspace script | 13:03 |
| uvos | that charges to that point and then shuts off | 13:03 |
| uvos | and runn that on the deivces | 13:03 |
| uvos | still easier to have the b6 do it for you | 13:03 |
| freemangordon | sure, but still it will be easier to tell the charger "charge to 3.8" | 13:03 |
| freemangordon | and faster | 13:03 |
| Wizzup | in any case | 13:03 |
| Wizzup | I'm not going to do in this week for sure | 13:03 |
| freemangordon | uvos: btw, we have at least 2 issues that might result in a hange | 13:05 |
| uvos | cpcap and? | 13:05 |
| freemangordon | one is the bug I have introduced in cpcap-battery | 13:05 |
| freemangordon | pvr | 13:05 |
| uvos | what exactly? | 13:05 |
| uvos | ants related? | 13:05 |
| freemangordon | I had PVR_K: ... traces this morning | 13:06 |
| freemangordon | device was still alive (like, I was able to connect with ssh) | 13:06 |
| freemangordon | but UI was frozen | 13:06 |
| uvos | yeah i have that | 13:06 |
| freemangordon | no ants | 13:06 |
| uvos | well besides the trace | 13:06 |
| uvos | ususally thats the issue where xorg is in drmioctl | 13:07 |
| uvos | *stuck | 13:07 |
| uvos | or charging-sdl | 13:07 |
| freemangordon | and in xorg there were lots of PVR2DQueryBlitsComplete failed with error code: -8 (Blit not complete) | 13:07 |
| uvos | ok | 13:07 |
| uvos | maybe different issue | 13:07 |
| freemangordon | and PVR2DBlt failed with error code: -2 (Device unavailable) | 13:07 |
| freemangordon | didn;t check what xorg does | 13:07 |
| freemangordon | maybe it is the same issue manifesting in a different way | 13:07 |
| freemangordon | but I would bet on issue in pvr blobs | 13:08 |
| freemangordon | I think it is a good idea to see why SGX recovery does not kick | 13:08 |
| uvos | maybe its the same issue that causes pvr to hang in neverball even.. | 13:08 |
| uvos | what do i know | 13:08 |
| freemangordon | someday | 13:08 |
| freemangordon | yeah, could be | 13:08 |
| freemangordon | but in theory SGX shall recover from lock-up | 13:09 |
| freemangordon | hopefully there should be newer userspace at some point | 13:09 |
| freemangordon | lets wait for it and see | 13:10 |
| uvos | who would we even report issues too | 13:10 |
| freemangordon | andrew | 13:10 |
| uvos | like the neverball thing is easy to repo | 13:10 |
| freemangordon | already did | 13:10 |
| uvos | ah ok | 13:10 |
| freemangordon | lemme see if he will reply at all | 13:10 |
| freemangordon | if he do, I will try to send him instructions how to re-create this neverball thing | 13:11 |
| uvos | maybe i could extract the shadow rendering code from it into some standalone crash example. | 13:12 |
| freemangordon | that'd be very helpful, yes | 13:12 |
| uvos | if he is inclined to help | 13:12 |
| freemangordon | but lets wait for him to reply first | 13:12 |
| freemangordon | as if he does not, there's no point | 13:12 |
| uvos | right | 13:12 |
| freemangordon | uvos: are you sure this has ever worked? https://github.com/maemo-leste/status-area-applet-battery/blob/master/batmon.c#L126 | 13:17 |
| freemangordon | I see nobody cares about 'low' state | 13:17 |
| uvos | definately | 13:17 |
| uvos | i have seen it | 13:17 |
| freemangordon | maybe based on the % full | 13:18 |
| uvos | mce cares not about low btw its based on % | 13:18 |
| uvos | yes | 13:18 |
| uvos | in mce at least | 13:18 |
| uvos | no idea if its the same here | 13:18 |
| uvos | not that mce dose anything with low at all | 13:18 |
| uvos | but it calculates it | 13:18 |
| freemangordon | mce cares about low signal from upower | 13:18 |
| freemangordon | to make a shutdown decision | 13:18 |
| freemangordon | have to do some work work, ttyl | 13:18 |
| uvos | yes i mean low as the mce state | 13:18 |
| uvos | it has a low and critical state | 13:19 |
| uvos | low is < 10% | 13:19 |
| uvos | nothing happens on low in mce | 13:19 |
| uvos | but it calculates it still | 13:19 |
| buZz | Wizzup: hobbyking.com is also nice for such chargers | 13:27 |
| buZz | Wizzup: they have a dutch warehouse too | 13:27 |
| freemangordon | uvos: it is about battery applet, I think it does not care about what mce do | 13:38 |
| freemangordon | see https://github.com/maemo-leste/status-area-applet-battery/blob/master/status-area-applet-battery.c#L644 | 13:41 |
| freemangordon | going to fix that | 13:42 |
| uvos | freemangordon: is shal not care about what mce dose | 13:45 |
| uvos | mce dosent provide battery on an external interface | 13:45 |
| buZz | i'd love if 'fully charged' would make a more noticeable sound :) | 13:45 |
| buZz | is there even a sound on it? | 13:45 |
| uvos | and indeed mce dosent even use the battery information at all internally | 13:45 |
| uvos | except for the battery-guard module i added | 13:45 |
| freemangordon | uvos: it is not about mce this time ;) | 13:46 |
| uvos | "uvos: it is about battery applet, I think it does not care about what mce do" | 13:46 |
| uvos | was just respnding to that | 13:46 |
| freemangordon | but about battery status applet, ignoring 'low' state provided by kernel | 13:46 |
| freemangordon | ok | 13:46 |
| freemangordon | just making it sure we're on the same table | 13:46 |
| uvos | yes i was just agreeing | 13:47 |
| uvos | it dosent care | 13:47 |
| freemangordon | so, maybe I was not warned because battery applet does not warb | 13:47 |
| freemangordon | *warn | 13:47 |
| uvos | maybe but i have seen the warning before | 13:47 |
| freemangordon | yes, but see how it decides to warn | 13:47 |
| uvos | probubly because batt_calibrated == true | 13:47 |
| uvos | yes | 13:47 |
| freemangordon | mhm | 13:47 |
| freemangordon | going to add support for 'low' and 'critical' | 13:48 |
| uvos | it would be good to make the percentage confiurable too | 13:48 |
| uvos | how mutch time 5% is varies by device | 13:48 |
| freemangordon | maybe, but not now | 13:48 |
| buZz | uvos: i think i figured out why my prev install didnt calibrate anymore | 13:48 |
| buZz | because i overwrote the calibration with '1000000' by hand | 13:49 |
| buZz | it never changed it anymore afterwards, maybe file permissions | 13:49 |
| buZz | my new install from maemo-leste-1.0-armhf-droid4-20221023.img.xz does recalibrate 'all the time' | 13:50 |
| uvos | no idea wht that would happen buZz | 13:50 |
| buZz | :) alright, doesnt matter much | 13:50 |
| buZz | i'd love some example python app to 'start a program with a file as parameter' so i can maybe finally package that pcsx-rearmed with some minimal frontend | 13:51 |
| buZz | i mean, we do have some 'maemo filepicker' stuff we can use from python, right? | 13:52 |
| uvos | hopefully its registerd as the xdg filepicker | 13:52 |
| uvos | probubly not tho knowing nokia | 13:53 |
| buZz | :) | 13:53 |
| uvos | hm i gues this interface dident exist back then, so not nokias fault for once (looking at you hildon-mime) | 13:54 |
| buZz | i did get the errors again about 'missing font/bla' on apt installing stuff | 13:55 |
| buZz | guess i need some package installed to define those types , which i havent yet | 13:56 |
| freemangordon | buZz: I think I merged your commit, but didn;t release new version | 13:59 |
| freemangordon | will do soon (tm) :) | 13:59 |
| buZz | ah, that could be it :D | 13:59 |
| buZz | <3 thanks | 13:59 |
| freemangordon | uvos__: I don't think this https://github.com/maemo-leste/droid4-linux/blob/master/drivers/power/supply/cpcap-battery.c#L513 is correct either | 15:40 |
| freemangordon | this does not account for 'low' irq | 15:40 |
| freemangordon | tmlind: ^^^? | 15:41 |
| freemangordon | shall I fix that? | 15:41 |
| uvos__ | hmm idk | 15:43 |
| uvos__ | how do you suppose the state should be determined | 15:44 |
| uvos__ | you cant just go by the irq | 15:44 |
| uvos__ | since you could go below the irq thresh and then start charging, are we still below the thresh? how do we know? | 15:44 |
| freemangordon | well, once we have that signalled, we shall report low, until a charger gets connected | 15:44 |
| uvos__ | just becasue a charger isent connected dosent mean low shal not be reported | 15:44 |
| uvos__ | the battery may sill be low | 15:44 |
| uvos__ | *is connected | 15:45 |
| uvos__ | you can also connect and disconnect the charger while allways below the irq thresh | 15:45 |
| freemangordon | right, but not based on irq | 15:45 |
| freemangordon | well, ok | 15:45 |
| uvos__ | the irq is really just a proxy for a certain voltage anyhow | 15:45 |
| freemangordon | a charger connected restes the low flag | 15:45 |
| freemangordon | *resets | 15:45 |
| uvos__ | i would not give it special meaning | 15:45 |
| freemangordon | if we get it while the charger is there, well, it is still low | 15:46 |
| uvos__ | other than a check if this is ok irq | 15:46 |
| uvos__ | you can connect a charger and disconnect it again | 15:46 |
| uvos__ | while the battery is low | 15:46 |
| freemangordon | and? | 15:46 |
| uvos__ | and never have the irq fire | 15:46 |
| freemangordon | ah | 15:46 |
| uvos__ | the irq is not special anyhow | 15:47 |
| freemangordon | ok, then something more clever shall be done | 15:47 |
| uvos__ | its just a proxy for 3.3v | 15:47 |
| freemangordon | well... | 15:47 |
| uvos__ | it dosent mean anything more than that the battery is below 3.3v now so checking if the voltage is below 3.3v is functually the same | 15:47 |
| uvos__ | except its better | 15:47 |
| uvos__ | because its less suseptable to noise | 15:47 |
| freemangordon | irq accounts for the load, more or less | 15:48 |
| uvos__ | no | 15:48 |
| uvos__ | the datasheet is clear | 15:48 |
| uvos__ | its just a comperator | 15:48 |
| freemangordon | yes, but when the load is bugger, the voltage drop is more | 15:48 |
| freemangordon | *bigger | 15:48 |
| uvos__ | yes except the irq triggers on undesirably short voltage drops | 15:49 |
| uvos__ | and mesureing the voltage without the irq is the same ofc | 15:49 |
| uvos__ | ie the current code is better | 15:49 |
| uvos__ | than relying on the irq | 15:49 |
| uvos__ | the low irq should not be take as fact, mearly as a signal to check if the battery is low by other means | 15:50 |
| freemangordon | measuring the voltage is less accurate, as it does not account for the peak load | 15:50 |
| uvos__ | the code above is essentaly those other means | 15:50 |
| uvos__ | you dont want account for peak load | 15:50 |
| freemangordon | why not? | 15:50 |
| uvos__ | you want to do some somothing | 15:50 |
| sicelo | lol @ https://github.com/maemo-leste/status-area-applet-battery/blame/master/batmon.c#L33 | 15:50 |
| freemangordon | to issue low warning? | 15:50 |
| freemangordon | sicelo: yeah :) | 15:51 |
| freemangordon | no comment | 15:51 |
| uvos__ | because a 1ms spke is immaterial | 15:51 |
| freemangordon | sure, but it is an early warning | 15:51 |
| freemangordon | nothing wrong to start alerting the user | 15:51 |
| freemangordon | better early than late/never | 15:52 |
| uvos__ | the low signal from kernel should trigger on a certain state of charge idealy | 15:52 |
| uvos__ | we dont have soc directly | 15:52 |
| uvos__ | so we should try and get close | 15:52 |
| freemangordon | how do you define 'low'? | 15:52 |
| uvos__ | triggering on spikes is not that | 15:52 |
| uvos__ | <15% soc is typical | 15:52 |
| freemangordon | sure | 15:53 |
| freemangordon | but in the applet it is 10% | 15:53 |
| uvos__ | smoothing the voltage gets you closest do this | 15:53 |
| freemangordon | maybe I shall increase that? | 15:53 |
| uvos__ | sure 15% is typical, the point is its some soc | 15:53 |
| uvos__ | not someting else dependant on load | 15:53 |
| freemangordon | because it uses <10 as low and < 5 as critical | 15:53 |
| uvos__ | sure the exact soc values are up for debate | 15:54 |
| freemangordon | ok, but I think there is some conflict: | 15:54 |
| freemangordon | 1. kernel ignores voltage drops < 3.3 and reports low on steady 3.3 | 15:54 |
| freemangordon | 2. mce checks *current* if voltage is < 3.350 (iirc) and issues shutdown | 15:56 |
| uvos__ | kernel shal ignore voltage drops below <3.3 on some timescale | 15:56 |
| uvos__ | lets say 100ms | 15:56 |
| freemangordon | those 2 does not match | 15:56 |
| uvos__ | and mce shal do the same | 15:56 |
| uvos__ | for ciritical | 15:56 |
| uvos__ | right both shal smooth | 15:56 |
| freemangordon | well at least mce shall do | 15:56 |
| freemangordon | it is too sensitive atm | 15:57 |
| uvos__ | sure | 15:57 |
| freemangordon | ok, I will provide a patch for that | 15:57 |
| uvos__ | the smoothing cant be in mce tho | 15:57 |
| freemangordon | why? | 15:57 |
| uvos__ | it gets votlage changed signals | 15:57 |
| uvos__ | you cant smooth on those | 15:57 |
| freemangordon | I can start timer | 15:57 |
| uvos__ | pretty hacky | 15:58 |
| freemangordon | that runs every 20 or so seconds after first 'low' detection | 15:58 |
| freemangordon | no, why? | 15:58 |
| uvos__ | am moving window would be better | 15:58 |
| uvos__ | mce cant poll the voltage i think | 15:58 |
| freemangordon | so if it detects a voltage > threshold, then it just stops the timer | 15:58 |
| freemangordon | but, if it has several consecutive < threshold - shutdown | 15:59 |
| uvos__ | it would be alot better if upower would just filter it instead (i kinda think it dose even just to fast) | 15:59 |
| uvos__ | since mce isent the only consumer here | 15:59 |
| freemangordon | no, iirc it reports whatever kernel reports | 15:59 |
| uvos__ | well this is a problem for upower too | 16:00 |
| uvos__ | since it dose soc estimation based on votlage | 16:00 |
| freemangordon | this is not in the upstream upower | 16:00 |
| uvos__ | sure "our upower" | 16:00 |
| freemangordon | and I really think this is a huge hack | 16:00 |
| freemangordon | not to say it is very inaccurate | 16:01 |
| uvos__ | well wee need soc estimatation | 16:01 |
| uvos__ | its vert inaccturate because its bad | 16:01 |
| freemangordon | here I get 50% @ 3.6V | 16:01 |
| uvos__ | it ould be better | 16:01 |
| uvos__ | the tldr might be we need to not use upower at all | 16:01 |
| freemangordon | well... | 16:02 |
| uvos__ | but idk | 16:02 |
| freemangordon | me neither | 16:02 |
| freemangordon | but, it supports stuff like BT batteries etc | 16:02 |
| uvos__ | i gues the kernel folks wont be to happy if we just smooth all the voltages in kernel will they? | 16:03 |
| freemangordon | it is disabled, afaik | 16:03 |
| uvos__ | what is voltage_avg? | 16:04 |
| freemangordon | only of HW provides it :) | 16:04 |
| freemangordon | *if | 16:04 |
| uvos__ | right quie annoying that they dont want drivers to synthesize values | 16:05 |
| freemangordon | well, kinda makes sense | 16:05 |
| uvos__ | cpcap violates that allready anyhow | 16:05 |
| uvos__ | but userspace is dumb and not under our controll :P | 16:05 |
| freemangordon | mhm | 16:05 |
| uvos__ | really upower should smooth itself if avg is not available | 16:05 |
| freemangordon | I am tempted to pull latest upower to see how it will behave | 16:06 |
| freemangordon | and start making issues against it | 16:06 |
| freemangordon | yet again, I think we shall use low irq | 16:07 |
| freemangordon | because in reality *this* is what shall be reported by the driver - HW state | 16:07 |
| freemangordon | not some wild guess based on voltage | 16:07 |
| uvos__ | but thats not how hw works here | 16:08 |
| uvos__ | its not a battery low irq really | 16:08 |
| uvos__ | just a voltage low irq | 16:08 |
| freemangordon | see, I know what reference voltage and comparator is (most-probably op amp) :) | 16:09 |
| freemangordon | and I am pretty sure I understand how that works | 16:09 |
| uvos__ | im sure its not a op-amp | 16:09 |
| freemangordon | why not? | 16:09 |
| uvos__ | that would be silly when a analog comperator would work too | 16:09 |
| uvos__ | more complexity lower slew rate | 16:09 |
| freemangordon | anyway | 16:09 |
| uvos__ | driveing a op-amp into saturation is rude | 16:10 |
| uvos__ | :P | 16:10 |
| uvos__ | (you would have to if you wan to use it as a comperator) | 16:10 |
| freemangordon | the point is that it gives us early warning about the charge of the battery, which is more or less related with the state of the battery, i.e. its internal resistance | 16:10 |
| uvos__ | anyhow | 16:10 |
| uvos__ | not really, its dependant on a lot of factors inc external noise load and internal resistance | 16:11 |
| uvos__ | imo its not usable as anything but a "check this" signal | 16:11 |
| freemangordon | to me it is, to start warning the user | 16:12 |
| freemangordon | that the battery is getting 'low' | 16:12 |
| freemangordon | and that's true as long as 'battery level' is qualitative property | 16:13 |
| freemangordon | as we do not need or want exact measurements | 16:13 |
| freemangordon | all we want is to warn the user that she will soon need a charger | 16:13 |
| freemangordon | that's my point | 16:14 |
| uvos__ | imo we should to propper soc estimation (or use the soc given by the charge counter if avialbe) and warn the user based on that | 16:15 |
| uvos__ | thats my point | 16:15 |
| uvos__ | thats also what android dose it dose soc estimation and warns the user at exactly 15% | 16:16 |
| uvos__ | this works splendedly | 16:16 |
| freemangordon | I don;t think we will be ever able to make that work properly, but ok | 16:18 |
| freemangordon | I need some rest from the batteries :) | 16:18 |
| sicelo | freemangordon: how does this work i Fremantle? | 16:19 |
| freemangordon | bme | 16:19 |
| freemangordon | don;t remember what we did in bme replacement | 16:19 |
| freemangordon | maybe pali knows more | 16:19 |
| freemangordon | maybe something ob bq driver | 16:20 |
| freemangordon | *in | 16:20 |
| sicelo | yes, i know that, and Pali's replacement bme. but i mean .. how notifications are decided | 16:20 |
| freemangordon | don;t remember, sorry | 16:20 |
| sicelo | anyway I've also seen and heard the low battery notifications on droid 4. i don't use it much though, so i can't tell when last i heard and saw them | 16:21 |
| freemangordon | yes, but it is based on % full value | 16:21 |
| sicelo | but i recall there have been times i got lots of them | 16:21 |
| sicelo | ok. you propose to base on voltage? | 16:22 |
| freemangordon | it is already based on voltage | 16:24 |
| freemangordon | when the battery is not calibrated, a hack in upower estimates based on voltage | 16:24 |
| uvos__ | except its really dumb :) | 16:29 |
| uvos__ | idk if just improving this hack some dosent solve all issues | 16:29 |
| freemangordon | could be | 16:29 |
| uvos__ | and removeing the if callibrated check in the status applet | 16:29 |
| freemangordon | I already removed :) | 16:29 |
| freemangordon | uvos__: https://github.com/maemo-leste/status-area-applet-battery/commit/d1e9b3aa34989bc631d6caa039371ac806655db6 | 16:30 |
| norayr | folks droid3 is so beautiful!!! | 17:30 |
| norayr | so pity it has poor support. that is the same chipset no? | 17:31 |
| norayr | what is the difference? | 17:31 |
| Wizzup | nagging won't fix it | 17:32 |
| Wizzup | if we knew it'd be fixed already | 17:32 |
| norayr | eh eh. | 17:32 |
| uvos | that said, Wizzup could you provide me with access to a d3 running android (preferably los) to dump the regs and see if the d3 maybe sets some regulators up differently or so? | 21:08 |
| uvos | also to figure out whats going on with the leds | 21:09 |
| norayr | it is very expensive to send something to the outer world from where i live, but if Wizzup won't send, i can send u a device, my first d3 which is in veeery bad shape: screen has a crack, power and volume buttons are very tired and it lacks a backplate. | 22:52 |
| uvos | norayr: i dont want a device really - just information | 23:01 |
| uvos | Wizzup is best placed to provide it | 23:02 |
| norayr | ah! | 23:04 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!