norayr has joined #maemo-leste
Daaanct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 252 seconds]
uvos__ has quit [Ping timeout: 248 seconds]
uvos has quit [Ping timeout: 248 seconds]
akossh has quit [Quit: Leaving.]
Danct12 has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
norayr has joined #maemo-leste
Daaanct12 has quit [Remote host closed the connection]
Daanct12 has joined #maemo-leste
Daaanct12 has joined #maemo-leste
Danct12 has quit [Ping timeout: 252 seconds]
norayr has left #maemo-leste [Error from remote client]
xmn has quit [Ping timeout: 255 seconds]
norayr has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
joerg has quit [Ping timeout: 248 seconds]
joerg has joined #maemo-leste
mardy has joined #maemo-leste
elastic_dog has joined #maemo-leste
elastic_dog is now known as Guest5715
elastic_dog has quit [Quit: elastic_dog]
elastic_dog has joined #maemo-leste
ceene has joined #maemo-leste
Daaanct12 has quit [Remote host closed the connection]
Daaanct12 has joined #maemo-leste
Danct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 252 seconds]
mardy has quit [Ping timeout: 252 seconds]
mardy has joined #maemo-leste
mardy has quit [Ping timeout: 252 seconds]
Twig has joined #maemo-leste
mardy has joined #maemo-leste
alex1216 has joined #maemo-leste
pere has quit [Ping timeout: 272 seconds]
norayr has joined #maemo-leste
uvos has joined #maemo-leste
uvos__ has joined #maemo-leste
Twig has quit [Remote host closed the connection]
norayr has left #maemo-leste [Error from remote client]
pere has joined #maemo-leste
Danct12 has quit [Remote host closed the connection]
Daanct12 has joined #maemo-leste
Danct12 has joined #maemo-leste
Daaanct12 has quit [Ping timeout: 252 seconds]
norayr has joined #maemo-leste
akossh has joined #maemo-leste
alex1216 has quit [Ping timeout: 252 seconds]
mardy has quit [Read error: Connection reset by peer]
alex1216 has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
mardy has joined #maemo-leste
nedko has quit [*.net *.split]
norayr has joined #maemo-leste
<freemangordon> uvos: do you want to make a new kernel update with cpcap fixes
<freemangordon> branch is maemo-5.18.y-cpcap, no tag
<uvos> freemangordon: makes sense to build it for devel no?
<uvos> not sure what your saying
<uvos> do you want me to tag it?
<freemangordon> yes, tag and build for -devel
<uvos> ok
<freemangordon> maybe merge back to maemo-5.18.y and delete maemo-5.18.y-cpcap branch
<freemangordon> I made it mostly for you and tmlind to review
<uvos> i get that
<uvos> i have to review it first
<freemangordon> I already fixed leste-config to enable hdq, I amd sure it does not increase idle current draw
<freemangordon> well, 99.99% sure :)
norayr has left #maemo-leste [Error from remote client]
<uvos> leste-config-mapphone/etc/modprobe.d/wire.conf.leste lacks ending newline
<freemangordon> not really
<freemangordon> pull again
<uvos> gh sais so
<uvos> i havent pulled yet
<freemangordon> hmm, I am sure I pushed, lemme check
<uvos> might be bug idk but its not happy
<uvos> oh you fixed it
<uvos> sorry
<freemangordon> maybe I didn;t push to master, lemme check
<freemangordon> it is there as well
<uvos> its there
<freemangordon> hmm, with the new battry thing are looking way batter
<freemangordon> *things
<freemangordon> I disconnected from the charger yesterday evening
<freemangordon> it still reports 50% full, but I think it has more juice actually
<uvos> just in: man is suprised new 2200mah battery works better than 10 year old 1750mah cell :P
Danct12 has quit [Remote host closed the connection]
Daaanct12 has joined #maemo-leste
Danct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 252 seconds]
uvos has quit [Remote host closed the connection]
akossh has quit [Ping timeout: 252 seconds]
noidea_ has quit [Remote host closed the connection]
noidea_ has joined #maemo-leste
akossh has joined #maemo-leste
<freemangordon> :D
pere has quit [Ping timeout: 248 seconds]
<freemangordon> tmlind: BTW, I have a patch for a panel (simple-panel), I know the model but not the manufacturer, what compatible I shall make for it? All panels are like $manufacturer,$model.
<freemangordon> in case anybody is curious about how that allwinner tablet I am using behaves with leste: http://46.249.74.23/leste/sunxi/20221102_001.mp4
norayr has joined #maemo-leste
pere has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
Daanct12 has joined #maemo-leste
norayr has joined #maemo-leste
Daaanct12 has quit [Ping timeout: 252 seconds]
Daaanct12 has joined #maemo-leste
Danct12 has quit [Ping timeout: 252 seconds]
uvos__ has quit [Ping timeout: 248 seconds]
xmn has joined #maemo-leste
nedko has joined #maemo-leste
akossh has quit [Ping timeout: 272 seconds]
<sicelo> Wizzup: any chance that you're not too far from your n900 serial jig? would be great if you could assist Pali with u-boot test that he needs
<tmlind> freemangordon: noname,panelxyz or something similar?
<freemangordon> will upstream accept it?
<freemangordon> uvos: "Nov 2 16:25:10 localhost kernel: [73611.267822] cpcap_battery cpcap_battery.0: Battery low at 3393mV!"
<freemangordon> and immediate shutdown
<freemangordon> something is broken, I guess mce logic
<freemangordon> battery capacity is measured to be 1619 mAh, not even close to 2250
<tmlind> freemangordon: if some mobile device, there are usually multiple providers of components, maybe generic,panelxyz
<freemangordon> hmm, yeah, generic should do the job
<freemangordon> it is tablet, but still
<freemangordon> I think it is better to calculate that based on POWER_SUPPLY_VOLTAGE_MIN_DESIGN
<freemangordon> like POWER_SUPPLY_VOLTAGE_MIN_DESIGN+50 or something
<freemangordon> also, I guess you have some hard values in charge-mode
<sicelo> that "Battery low at 3393mV" came from kernel. isn't it kernel that initiated the shutdown in this case?
<freemangordon> no
<freemangordon> also, it seems there are 2 types of 'low' one @ 3.3 and other @ 3.1, no idea what are those used for
<freemangordon> tmlind: ^^^ do you remember?
<freemangordon> ah, it seems 'high' low is for low reporting, 'low' low is for shutdown
<freemangordon> cpcap_battery_low() has some hardcoded values too
<freemangordon> but that is not so critical as mce deciding to do power off too early and charge-mode assuming normal li-ion battery no matter what kernel says
<sicelo> iirc it was set to 3350 in mce because d4 can't boot easily once battery is completely depleted
<freemangordon> *what* battery?
<sicelo> d4 battery :-)
<freemangordon> 10yo one?
<freemangordon> because here I have new polarcell 2250 mAh
<sicelo> 10yo battery and cheap replacements
<freemangordon> and yes, it can boot the device even @ 3150
<freemangordon> the point is that genuine moto batteries are 3.1-4.35
<freemangordon> not 3.2-4.2
<freemangordon> and that is the difference between 1600 and 2200
<freemangordon> 30%
<freemangordon> or something
<freemangordon> but anyway, lets wait for uvos, to see if we will be able to come-up with some idea that will make both (old battery/new battery) parties happy
<freemangordon> in any case, mce shutdown voltage must be less that 3.3, otherwise you don't have any chance to get a charger
xmn has quit [Ping timeout: 252 seconds]
pere has quit [Ping timeout: 252 seconds]
alex1216 has quit [Quit: WeeChat 2.3]
xmn has joined #maemo-leste
<freemangordon> hmm, what about:
<freemangordon> 1. mce stores current voltage @ first 'low' signal received
<freemangordon> 2. on every following 'low' received, it subtracts the current voltage from the stored one and if it is more than a threshold or if the current voltage is less that DESIGN_LOW + 100 (for example), then it shuts down
<freemangordon> 3. stored 'first low' is reset on charger connected
<freemangordon> that way bad batteries will be guaranteed to have enough charge to boot and good batteries will be used properly and users will have a chance to find a charger
<freemangordon> hmm?
pere has joined #maemo-leste
<freemangordon> my old (bad) battery was giving low @ 3636mV, so I think threshold should be calculated based on lowVoltage - 3300, somehow
<freemangordon> hmm, actually threshold = $device_specific_value + (4200-DESIGN_LOW) should be better
<freemangordon> oh, I mean 3200-DESIGN_LOW
uvos has joined #maemo-leste
<freemangordon> hmm, increasing POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE doesn't actually work
<Wizzup> sicelo: I wil be near it on sunday and onwards
<uvos> mce deicdes to turn off the device early because of the mapphone bootloader booting problem when totaly empty
<uvos> we discussed this plenty of times before
<uvos> yes its early (slightly the amount of engery in a lipo at 3.35 volts is fairly tiny over 3.0V the curve gets really steep down there)
<uvos> it _needs_ to be early
<uvos> take a look at https://learn.adafruit.com/li-ion-and-lipoly-batteries/voltages for a referance discharge curve
<uvos> note that teh differencein capcaity between a discarge to 3.1 and 3.2 is less than to even worry about
<uvos> 3.35 is slightly early, but note that we do that because the device will die before it reaches a bootstate where it can charge if you do that
<uvos> becasue of kexecboot etc
<uvos> but even that is in the rage of a couple pecent
<uvos> 2% maybe 5% if the device is heavly loaded at shutdown
norayr has left #maemo-leste [Error from remote client]
<uvos> so i did the expieraments wrt when to shutdown with my best stock eb41 btw
<uvos> that hat about 1250mAh as callibrated by cpcap
<uvos> also taking into account that we use quite a large amount of power even when off, if the mainline kernel is the one to turn the device off
<uvos> so we also needed some extra
<freemangordon> uvos: I understand and agree that we should have some extra power on shutdown
<freemangordon> that's not the issue, the issue is that I was not give any chance to connect a charger
<freemangordon> *given
<freemangordon> no warning, nothing, as soon as 'low' was signaled, bang, a shutdown
<freemangordon> that's why I think a more complicated logic, like the one ^^^ shall be implemented
<freemangordon> also, it is not about d4 only
<uvos> well we have a conflict here
<freemangordon> I know
<uvos> we dont want to change the values in kernel
<uvos> because they should be correct
<freemangordon> we should not
<uvos> so we want a workaround in userspace only
<freemangordon> see the algo I came up with ^^^
<freemangordon> this is all in mce
<uvos> i dont see why its not about d4 only
<uvos> any other device should not have this issue
<uvos> the kernel should just signal at the appropriate times
<freemangordon> we may have similar issues on other devices, in theory
<freemangordon> but lets not discuss that now
<freemangordon> please comment on the alog
<freemangordon> *algo
<uvos> i dont grok it
<uvos> what is your first low?
<freemangordon> 'current_voltage' at the tim e'low' is generated for the first time
<uvos> thats essentaly a random number generator
<uvos> since it depends on load
<sicelo> those 'lows' don't exist in bq27200 iirc
<freemangordon> not really, because the worse battery is, the higher the voltage
<uvos> but you cant realy on that
<uvos> since it wont be so when the device is not loaded
<uvos> i also dont see what is nessecary
<uvos> besides rasing the low threshold (for the banner) in userspace
<freemangordon> to have at least few minutes of "battery low" ranings before a shutdoen
<uvos> sure
<freemangordon> *warnings
<uvos> so just raise the tresh in upower
<freemangordon> this somes from the kernel
<uvos> to 3.5 or so
<freemangordon> *comes
<uvos> and ignore the kernel
<uvos> just need to make this selective like in mce
<freemangordon> see, *defaults* should work
<uvos> the defaults are what is in kernel
<freemangordon> no, mce ignores the kernel and makes its own shut-down decision
<uvos> yes
<uvos> the fact that the kernel is "lieing" is a quirk on mapphones only
<freemangordon> this is wrong the way it is implemented for d4
<freemangordon> that quirk makes it so that those with good batteries have absolutely no chance to plug a charger when the battery is low
<freemangordon> and this has to be fixed
<uvos> sure and i told you how i would do that
<uvos> just ignore the low signal from the kernel in upower
<freemangordon> why upower?
<uvos> and add something based on configureable voltage instead
<uvos> where else would you do it?
<uvos> upower is the common thing here
<freemangordon> that agin depends on the load, no?
<uvos> sure, but its the best we have
akossh has joined #maemo-leste
<freemangordon> did you grok what I am proposing?
<uvos> yes and it cant be reliable
<freemangordon> I don;t see why?
<uvos> since it depends on instanainous load
<uvos> while upower dose smoothing
<freemangordon> no, there are 2 shutdoen conditions
norayr has joined #maemo-leste
<freemangordon> either threshold or low voltage
<freemangordon> whichever comes first
<uvos> sure. but should be critical not low
<uvos> for the latter
<uvos> low is the banner
<freemangordon> sure
<freemangordon> I have no issue with too mane 'low' banners
<freemangordon> given that I had none before shutdown :)
<uvos> right so the problem is not the shutdown threshold in mce
<freemangordon> back then I had my n900 beeping 'low' all day long
Twig has joined #maemo-leste
<freemangordon> it is
<uvos> or the cirtical signal
<uvos> it is that the low signal dosent follow the thresh in mce
<freemangordon> no, it is the shutdown threshold in mce
<uvos> ie it isent above the tresh in mce
<freemangordon> lemme explain:
<freemangordon> I got kernel low @3393mV
<freemangordon> mce threshold is 3350
<sicelo> freemangordon: was the N900 battery calibrated? (that beeped low all day)
<uvos> yes so it shutdown
<uvos> and you never saw the low banner
<freemangordon> exactly
<uvos> the issue here isent the mce threshold
<uvos> its that the banner is to late
<freemangordon> it is
<freemangordon> because it shuts down
<uvos> mce _has_ to shutdown
<freemangordon> no, banner is not late
<uvos> it has no choice
<freemangordon> yes, but that should depend on the quality of the battery
<freemangordon> sicelo: this is d4
<uvos> it cant
<freemangordon> sicelo: oh
<freemangordon> no, that was bme
<uvos> there is no reliable way for mce to know how mutch capacity is below 3.35V
<uvos> what you propose is not a relaible way to mesure it
<freemangordon> but is better than current behaviour
<uvos> no
<uvos> and as i also explained
<uvos> if mce thresh is 3.35
<freemangordon> no, current behaviour is unacceprable
<uvos> and your special thresh is 3.15V
<uvos> the lost extra capacity is <5% in exream cases
<uvos> probubly less than 2
<freemangordon> because it leeves me without a phone, withoug giving me a warning
<freemangordon> *leaves
<uvos> but thats not a problem with the treshold at all
<uvos> the indication of low just needs to come earlier
<freemangordon> it cannot
<freemangordon> because the battery is good
<uvos> ofc it can
<uvos> we need 2-3% extra capcaity to boot again
<freemangordon> exactly
<uvos> so we need to move the low signal up 2-3%
<uvos> aswell
<freemangordon> no, we should not shutdown @ 3350
<uvos> yes we must
<uvos> there is no alternative
<freemangordon> or at least that should account for the DESIGN_LOW
<uvos> no
<freemangordon> aaaaa
<freemangordon> I give up
<uvos> DESIGN_LOW should be the real value
<uvos> not the value we moved up 2-3%
<uvos> becasue of the bootloader issue
<uvos> so we should absolutly not include it
<uvos> and we dont have to either
<uvos> becuase the differences in design low are immaterial
<uvos> 3.1 vs 3.2 vs 3.0 v are <<1% capcaity
<uvos> we cant mesure that accuratly anyhow
<uvos> so there is no point
norayr has left #maemo-leste [Error from remote client]
<freemangordon> ok, lemme try again:
<freemangordon> uvos: what is the lowest battery capacity we shall support?
<uvos> android works fine even with really degraded batteies
<freemangordon> ok, so 1000mAh?
<uvos> sure
<freemangordon> now, to boot, we need about 50mAh remaning, no?
<uvos> not sure about the exact value
<uvos> but yes some amount
<freemangordon> and high enough voltage, like maybe 3.3 if we assume internal resistance to be 1 ohm
<freemangordon> this is for bad batteries
<uvos> high enougth voltage at what stage
<freemangordon> boot
<uvos> we need to stay above mbms shutdown threshold
<uvos> the android kernels threshold
<uvos> during boot
<freemangordon> so 3.1
<uvos> yes, mbm is a bit higher
<freemangordon> threshold I mean
<uvos> but it comes first so no matter
<freemangordon> ok
<uvos> we also need to say above the mainline kernels emergency shutdown thresh
<uvos> at least for the second it takes to enable charging
<freemangordon> yes
<freemangordon> so, lets assume 3.3 is ok
<uvos> sure at boot time
<uvos> so we need to issue shutdown slightly before that ofc
<freemangordon> but, this is 3.3 with no load
<uvos> sure
<uvos> but you need to accound for usage during shutdown
norayr has joined #maemo-leste
<freemangordon> sure, but this is about 30 seconds
<uvos> and the bug that cuases the device to use 1-2mA during off
<uvos> we need the device to survive a day or so while off after low battery shutdown
<uvos> 30 quite processing intense seconds
<freemangordon> also, we can use the measured capacity to make an estimation of the quality of the battery
<uvos> do remember the discarge curve, 3.3v and 3.1 are very close
<uvos> well the problem here is
<uvos> that we dont know where the charge counter is ususal
<sicelo> uvos: shouldn't that be figured out? "the bug that cuases the device to use 1-2mA during off"
<uvos> sicelo: yes
<uvos> sicelo: but thats very hard
<uvos> sicelo: how do you get hw state when the device is off
<uvos> sicelo: clearly we are not doing something, but what?
<freemangordon> anyway, we shall either raise the 'low' threshold above 3.3 or lower the mce shutdown threshold
<freemangordon> we can;t do former, so we shall make mce smarter
<uvos> well we cant lower the mce shutdown threshold as that will softbrick peoples devices
<uvos> and we must make the low threshold be above whatever mce decides at all times
<freemangordon> byt either lowering the threshold or do not do shutdown before warning at least couple of times
<uvos> so it needs to account for the mce tresh being 3.35v
<uvos> we cant just not shutdown before warning a couple of times
<freemangordon> so, what about ignoring firts couple of "low" signals then?
<uvos> a bad idea
<uvos> since if the device is very quiet they wont come
<freemangordon> why?
<uvos> it will only come once
<uvos> there is only one solution:
<uvos> remove the code from mce, and add it to upower
<uvos> the real issue here is
<uvos> that the ui and mce take the values from upower
<uvos> and chaingn something in mce (like how low is determined) dosent affect the ui
<freemangordon> again, it is not about the low but about shutdown
<freemangordon> and this is decided in mce
<uvos> yes but thats not the root issue
<uvos> so really mce should just shutdown when upower sais battery is ciritcal
<uvos> and the ui should notify when upower sais low
<freemangordon> agree
<uvos> so we messed with mce to change when critical is
<uvos> but thats bad
<freemangordon> that's what I am trying to say all the time
<uvos> because it dosent move low and it dosent move critical for other upower clients
<uvos> the solution is not to make mce "smarter"
<uvos> but to add config options to upower
<uvos> to define low and critical other than what the kernel sais
<freemangordon> which we have to support, no?
<freemangordon> upower patches I mean
<uvos> not sure what you mean by support
ceene has quit [Remote host closed the connection]
<uvos> we have to write upower patches
<uvos> yes
<uvos> we have plenty of those allready.....
<freemangordon> well, whatever the solution is, the current behaviour is not ok
<freemangordon> I'll think about that a bit more
<uvos> well the only way to solve it is to change A: kernel, but we dont want to do that or B: upower
<uvos> and changing upower would involve adding a udev var that it checks for a low voltage threshold for critical
<uvos> and antoher for low
<freemangordon> or simply lowering the current mce threshold a bit
<uvos> no
<freemangordon> I think current value is too conservative
<uvos> that dosent solve the issue at all
<uvos> even if the value is too converative ( i strongly dissagree )
<freemangordon> ok
<uvos> the issue is that the distance between low and cirictcal is not constant
<freemangordon> who is going to implement the code in upower?
<uvos> ugh, im not to bothered by current behavior xD
<freemangordon> but your users are
yanu has quit [Ping timeout: 248 seconds]
norayr has left #maemo-leste [Error from remote client]
yanu has joined #maemo-leste
<uvos> heh
<uvos> well idk - not right now make an issue is what i say to that
pere has quit [Ping timeout: 252 seconds]
pere has joined #maemo-leste
uvos has quit [Ping timeout: 252 seconds]
norayr has joined #maemo-leste
nedko has quit [Ping timeout: 255 seconds]
nedko has joined #maemo-leste
mardy has quit [Quit: WeeChat 3.5]
_whitelogger has joined #maemo-leste
Twig has quit [Remote host closed the connection]
<norayr> floks, i agree with uvos. even now d4 is problematic. i recently found myself preparing special wires and connecting my phone to my friends' phone in other town because there was no way to charge it. i revived it, luckily, gave it enough charge from my battery so that it would start and charge itself.
<norayr> it sdould preserve even more charge when shutting down.
<norayr> not less.
<norayr> many people won't be able to care about the phone rike it is tamagocci.
<norayr> the phone should care about itself y shutting itself down earlier and preserving enough charge to boot a le of times.
<norayr> a couple of times.
Langoor has quit [Read error: Software caused connection abort]
Langoor has joined #maemo-leste
branon has quit [Ping timeout: 268 seconds]
branon has joined #maemo-leste
akossh has quit [Quit: Leaving.]
BenLand100 has quit [Ping timeout: 272 seconds]