nedko has quit [Remote host closed the connection]
<freemangordon>
going to fix that
nedko has joined #maemo-leste
<uvos>
freemangordon: is shal not care about what mce dose
<uvos>
mce dosent provide battery on an external interface
<buZz>
i'd love if 'fully charged' would make a more noticeable sound :)
<buZz>
is there even a sound on it?
<uvos>
and indeed mce dosent even use the battery information at all internally
<uvos>
except for the battery-guard module i added
<freemangordon>
uvos: it is not about mce this time ;)
<uvos>
"uvos: it is about battery applet, I think it does not care about what mce do"
<uvos>
was just respnding to that
<freemangordon>
but about battery status applet, ignoring 'low' state provided by kernel
<freemangordon>
ok
<freemangordon>
just making it sure we're on the same table
<uvos>
yes i was just agreeing
<uvos>
it dosent care
<freemangordon>
so, maybe I was not warned because battery applet does not warb
<freemangordon>
*warn
<uvos>
maybe but i have seen the warning before
<freemangordon>
yes, but see how it decides to warn
<uvos>
probubly because batt_calibrated == true
<uvos>
yes
<freemangordon>
mhm
<freemangordon>
going to add support for 'low' and 'critical'
<uvos>
it would be good to make the percentage confiurable too
<uvos>
how mutch time 5% is varies by device
<freemangordon>
maybe, but not now
<buZz>
uvos: i think i figured out why my prev install didnt calibrate anymore
<buZz>
because i overwrote the calibration with '1000000' by hand
<buZz>
it never changed it anymore afterwards, maybe file permissions
<buZz>
my new install from maemo-leste-1.0-armhf-droid4-20221023.img.xz does recalibrate 'all the time'
<uvos>
no idea wht that would happen buZz
<buZz>
:) alright, doesnt matter much
<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
<buZz>
i mean, we do have some 'maemo filepicker' stuff we can use from python, right?
<uvos>
hopefully its registerd as the xdg filepicker
<uvos>
probubly not tho knowing nokia
<buZz>
:)
<uvos>
hm i gues this interface dident exist back then, so not nokias fault for once (looking at you hildon-mime)
<buZz>
i did get the errors again about 'missing font/bla' on apt installing stuff
<buZz>
guess i need some package installed to define those types , which i havent yet
<freemangordon>
buZz: I think I merged your commit, but didn;t release new version
<freemangordon>
will do soon (tm) :)
<buZz>
ah, that could be it :D
<buZz>
<3 thanks
ikmaak has quit [Read error: Connection reset by peer]
<freemangordon>
nothing wrong to start alerting the user
<freemangordon>
better early than late/never
<uvos__>
the low signal from kernel should trigger on a certain state of charge idealy
<uvos__>
we dont have soc directly
<uvos__>
so we should try and get close
<freemangordon>
how do you define 'low'?
<uvos__>
triggering on spikes is not that
<uvos__>
<15% soc is typical
<freemangordon>
sure
<freemangordon>
but in the applet it is 10%
<uvos__>
smoothing the voltage gets you closest do this
<freemangordon>
maybe I shall increase that?
<uvos__>
sure 15% is typical, the point is its some soc
<uvos__>
not someting else dependant on load
<freemangordon>
because it uses <10 as low and < 5 as critical
<uvos__>
sure the exact soc values are up for debate
<freemangordon>
ok, but I think there is some conflict:
<freemangordon>
1. kernel ignores voltage drops < 3.3 and reports low on steady 3.3
<freemangordon>
2. mce checks *current* if voltage is < 3.350 (iirc) and issues shutdown
<uvos__>
kernel shal ignore voltage drops below <3.3 on some timescale
<uvos__>
lets say 100ms
<freemangordon>
those 2 does not match
<uvos__>
and mce shal do the same
<uvos__>
for ciritical
<uvos__>
right both shal smooth
<freemangordon>
well at least mce shall do
<freemangordon>
it is too sensitive atm
<uvos__>
sure
<freemangordon>
ok, I will provide a patch for that
<uvos__>
the smoothing cant be in mce tho
<freemangordon>
why?
<uvos__>
it gets votlage changed signals
<uvos__>
you cant smooth on those
<freemangordon>
I can start timer
<uvos__>
pretty hacky
<freemangordon>
that runs every 20 or so seconds after first 'low' detection
<freemangordon>
no, why?
<uvos__>
am moving window would be better
<uvos__>
mce cant poll the voltage i think
<freemangordon>
so if it detects a voltage > threshold, then it just stops the timer
<freemangordon>
but, if it has several consecutive < threshold - shutdown
<uvos__>
it would be alot better if upower would just filter it instead (i kinda think it dose even just to fast)
<uvos__>
since mce isent the only consumer here
<freemangordon>
no, iirc it reports whatever kernel reports
<uvos__>
well this is a problem for upower too
<uvos__>
since it dose soc estimation based on votlage
<freemangordon>
this is not in the upstream upower
<uvos__>
sure "our upower"
<freemangordon>
and I really think this is a huge hack
<freemangordon>
not to say it is very inaccurate
<uvos__>
well wee need soc estimatation
<uvos__>
its vert inaccturate because its bad
<freemangordon>
here I get 50% @ 3.6V
<uvos__>
it ould be better
<uvos__>
the tldr might be we need to not use upower at all
<freemangordon>
well...
<uvos__>
but idk
<freemangordon>
me neither
<freemangordon>
but, it supports stuff like BT batteries etc
<uvos__>
i gues the kernel folks wont be to happy if we just smooth all the voltages in kernel will they?
<freemangordon>
it is disabled, afaik
<uvos__>
what is voltage_avg?
<freemangordon>
only of HW provides it :)
<freemangordon>
*if
<uvos__>
right quie annoying that they dont want drivers to synthesize values
<freemangordon>
well, kinda makes sense
<uvos__>
cpcap violates that allready anyhow
<uvos__>
but userspace is dumb and not under our controll :P
<freemangordon>
mhm
<uvos__>
really upower should smooth itself if avg is not available
<freemangordon>
I am tempted to pull latest upower to see how it will behave
<freemangordon>
and start making issues against it
<freemangordon>
yet again, I think we shall use low irq
<freemangordon>
because in reality *this* is what shall be reported by the driver - HW state
<freemangordon>
not some wild guess based on voltage
<uvos__>
but thats not how hw works here
<uvos__>
its not a battery low irq really
<uvos__>
just a voltage low irq
<freemangordon>
see, I know what reference voltage and comparator is (most-probably op amp) :)
<freemangordon>
and I am pretty sure I understand how that works
<uvos__>
im sure its not a op-amp
<freemangordon>
why not?
<uvos__>
that would be silly when a analog comperator would work too
<uvos__>
more complexity lower slew rate
<freemangordon>
anyway
<uvos__>
driveing a op-amp into saturation is rude
<uvos__>
:P
<uvos__>
(you would have to if you wan to use it as a comperator)
<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
<uvos__>
anyhow
<uvos__>
not really, its dependant on a lot of factors inc external noise load and internal resistance
<uvos__>
imo its not usable as anything but a "check this" signal
<freemangordon>
to me it is, to start warning the user
<freemangordon>
that the battery is getting 'low'
<freemangordon>
and that's true as long as 'battery level' is qualitative property
<freemangordon>
as we do not need or want exact measurements
<freemangordon>
all we want is to warn the user that she will soon need a charger
<freemangordon>
that's my point
<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
<uvos__>
thats my point
<uvos__>
thats also what android dose it dose soc estimation and warns the user at exactly 15%
<uvos__>
this works splendedly
<freemangordon>
I don;t think we will be ever able to make that work properly, but ok
<freemangordon>
I need some rest from the batteries :)
<sicelo>
freemangordon: how does this work i Fremantle?
<freemangordon>
bme
<freemangordon>
don;t remember what we did in bme replacement
<freemangordon>
maybe pali knows more
<freemangordon>
maybe something ob bq driver
<freemangordon>
*in
<sicelo>
yes, i know that, and Pali's replacement bme. but i mean .. how notifications are decided
<freemangordon>
don;t remember, sorry
<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
<freemangordon>
yes, but it is based on % full value
<sicelo>
but i recall there have been times i got lots of them
<sicelo>
ok. you propose to base on voltage?
<freemangordon>
it is already based on voltage
<freemangordon>
when the battery is not calibrated, a hack in upower estimates based on voltage
<uvos__>
except its really dumb :)
<uvos__>
idk if just improving this hack some dosent solve all issues
<freemangordon>
could be
<uvos__>
and removeing the if callibrated check in the status applet
<norayr>
so pity it has poor support. that is the same chipset no?
<norayr>
what is the difference?
<Wizzup>
nagging won't fix it
<Wizzup>
if we knew it'd be fixed already
<norayr>
eh eh.
uvos has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
norayr has joined #maemo-leste
nedko has quit [Ping timeout: 255 seconds]
nedko has joined #maemo-leste
<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?
<uvos>
also to figure out whats going on with the leds
mardy has quit [Quit: WeeChat 3.5]
Twig has quit [Remote host closed the connection]
<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.
<uvos>
norayr: i dont want a device really - just information
<uvos>
Wizzup is best placed to provide it
<norayr>
ah!
akossh has quit [Quit: Leaving.]
elastic_dog has quit [Remote host closed the connection]