<Wizzup>
btw, bookworm seems to have a new-ish pipewire compared to bullseye, which we might eventually want (since it so far has been a drop in replacement for pulse for me)
<uvos>
Wizzup: yeah
<uvos>
Wizzup: please also kick droid4-battery-calibration
<uvos>
i assume giveing me the rights to do so is still to hard
<Wizzup>
let me look at fixing it now
lel has quit [Remote host closed the connection]
lel has joined #maemo-leste
<SuperMarioSF>
woah, the battery life on leste with droid4 is surprisingly good...
<Wizzup>
SuperMarioSF: it ought to get even better
<SuperMarioSF>
a day passed, not even used a half
<Wizzup>
you have a nice battery :)
<uvos>
i think the mapphones are the only mainline linux devices that correctly idle
<uvos>
(please do correct me if im wrong, id like to know about them :) )
<uvos>
i gues the librem5 maybe?
<SuperMarioSF>
probably this is the key to the old "nokia level battery standby time" days
<Wizzup>
SuperMarioSF: what is 'this' ?
<SuperMarioSF>
early 2000s nokia dumb phone like standby time.
<uvos>
SuperMarioSF: so currently we can do about 90mW on idle, android can do 15mW so the hw is capable of at least this.
<SuperMarioSF>
usually last for few days without a single charge
<uvos>
i thin 2000s dumb phones did way better
<Wizzup>
SuperMarioSF: so what matters more than almost anything is the hw
<Wizzup>
omap is really good at pm, and we don't even hit the lowest idle modes yet
<Wizzup>
we can kind of hit them on the n900, but not with all the useful drivers loaded
<SuperMarioSF>
however keeping running at 15mW on android is almost imporssible for long term since the software side doesn't corporate.
<uvos>
thats not really true if you use android with out google services
<uvos>
no other stuff running
<uvos>
but yeah "sock android" no
<uvos>
*stock
<SuperMarioSF>
that is true, because there is a special case, that is "China's Mobile App EcoSystem"
<SuperMarioSF>
especially in early 2010s
<SuperMarioSF>
every damn software ask a long list of permission and start multiple background services just to keep them alive.
<uvos>
i mean yeah if you have 100 apps installed that all do telemetry
<uvos>
your battery is gona have a bad time :P
<SuperMarioSF>
that's why task management software these days are essential.
<uvos>
leste is way worse at task management than android btw
<uvos>
since leste relies on coperative battery mangament
<uvos>
and android more on a preemtive/permissions model
<SuperMarioSF>
but it actually standby very well, way better than the phone at the time in my memory.
<SuperMarioSF>
and of course better than today's.
<SuperMarioSF>
just for fun: do you know why China always made new phones with beefy specs first?
<SuperMarioSF>
because a software single handledly make this happen.
<SuperMarioSF>
Weixin, which had a global version called WeChat (not mixed with WeeChat)
<SuperMarioSF>
This thing can just occupy your half of battery life alone.
<SuperMarioSF>
And this thing is still going bigger, add more useless function and more telemetry.
<SuperMarioSF>
But we just can't let it go, because this is a "Super App" that basically every need to use. It almost became it's own OS at this point.
<uvos>
this may be true
<uvos>
but its hardly the fault of the os
<SuperMarioSF>
yes, it is not the fault of the OS
<Wizzup>
SuperMarioSF: yeah I had used wechat for some time in HK back in 2016 or 2017 or so
<SuperMarioSF>
that is the whole reason we always need to upgrade our phone in few years, just to keep up with that damn super app.
elastic_dog has joined #maemo-leste
<SuperMarioSF>
older phone will be "outdated" by that thing, not from API level, from performance level.
<uvos>
mean while in EU they shutdown 3g to force us to upgrade :(
<Wizzup>
:(
<SuperMarioSF>
because older tech tend to use more power...
<Wizzup>
is that true?
<uvos>
for the same bandwith yes
<uvos>
but genneraly bandwith rises more than efficancy
<SuperMarioSF>
unless there is a special reason to keep certain tech online, the older one will eventually gone.
<uvos>
anyhow hsdpa+ is really close to shannon limit anyhow
<uvos>
so both lte and 5g really dont have mutch more bandwith in the same band
<SuperMarioSF>
China Mobile still operate 2G network because our own railway signaling system still using them.
<SuperMarioSF>
and their TD-SCDMA 3G network are long gone because unpopularity.
<SuperMarioSF>
the funny thing is China Mobile is the first operator to release VoLTE nationwide, because they don't have 2G for HD calling, and 3G network is gone. They have to use VoLTE.
<SuperMarioSF>
meanwhile China Unicom had WCDMA handling HD calling to this day. They support VoLTE later, but HD Calling on 3G still works.
<SuperMarioSF>
China Telecom, had already fully converted into 4G only, because they were using CDMA based network before.
<SuperMarioSF>
CDMA infrastructure still there, but when you see your network drop back into CDMA, you know there is basically "Out of service".
<SuperMarioSF>
btw my primary SIM is a China Telecom one, I have subscribed long before and still using that today.
<Wizzup>
uvos: is there any point to setting up daedalus as well in jenkins?
<uvos>
not atm i dont think
<Wizzup>
ok
SuperMarioSF63 has joined #maemo-leste
SuperMarioSF has quit [Ping timeout: 252 seconds]
SuperMarioSF63 has quit [Client Quit]
SuperMarioSF has joined #maemo-leste
xmn has joined #maemo-leste
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #maemo-leste
macros_2ndPC has joined #maemo-leste
macros_ has quit [Ping timeout: 255 seconds]
norayr has joined #maemo-leste
norayr has left #maemo-leste [#maemo-leste]
norayr has joined #maemo-leste
pere has joined #maemo-leste
norayr has left #maemo-leste [Disconnected: Replaced by new connection]
<buZz>
(avatars work through the gabble link, both receiving and setting on server)
<buZz>
the 'save' of 'my settings' does seem to hang the first time you try it, always need to save twice to set it
<buZz>
SuperMarioSF: hahaha, i half considered just glueing a android to another device on the back, just for such 'YOU NEED THIS ONE APP OMG WTF BBQ'
uvos__ has joined #maemo-leste
norayr has left #maemo-leste [Disconnected: closed]
norayr has joined #maemo-leste
Pali has joined #maemo-leste
<SuperMarioSF>
buZz OK I depleted my battery however it doesn't show "recharge battery" popup. It seems it just killed X server and just shutdown normally.
<SuperMarioSF>
I can see the status light goes off later than screen.
<SuperMarioSF>
Will this work for signaling to start battery calibration?
<SuperMarioSF>
btw this happend while battey icon show at least 50%.
<SuperMarioSF>
Android side show only 4% remaining
<SuperMarioSF>
after reboot the desktop won't even show up, it just shutdown even before desktop loaded.
<SuperMarioSF>
there is the file /var/lib/droid4-battery-calibration/charge_full , but have no content in it.
<buZz>
SuperMarioSF: killed X + turned on the white led when screen is off?
<SuperMarioSF>
yes
<buZz>
thats the lowpower shutdown , the popup was prior to that
<SuperMarioSF>
desktop just gone
<SuperMarioSF>
and white led keeps for a while, and power down after that
<buZz>
yes, its to signal to you its powering down for low power
<SuperMarioSF>
so this is okay for calibrate battery?
Bratch has joined #maemo-leste
<SuperMarioSF>
I can see that file the script saves, but no content in it.
<SuperMarioSF>
it is a empty file
l_bratch has quit [Read error: Connection reset by peer]
<SuperMarioSF>
I just connected to a 5v 2A USB charger, and turned it back on.
<SuperMarioSF>
it went into desktop.
<buZz>
did it boot with green led on?
<buZz>
if not, then it didnt enable the charger
<SuperMarioSF>
i guess so
<buZz>
why guess
<buZz>
it has a led, look at it, does it have a color?
<SuperMarioSF>
now the green LED and white LED flashs
<buZz>
eh
<buZz>
this is even a droid4? running leste?
<SuperMarioSF>
maybe white LED means power on
<buZz>
it does not on leste on a droid4
<SuperMarioSF>
it is in leste
<buZz>
is it a droid4 ?
<SuperMarioSF>
yes
<SuperMarioSF>
and I'm ssh into it right now
<buZz>
i have never in my life seen leste on a droid4 'flash green and white led'
<SuperMarioSF>
oh
<SuperMarioSF>
it is green LED, but sometimes turn to white, and goes back to green.
<buZz>
a) there's no white led there, its red, green and blue, 'white' is all three on
<SuperMarioSF>
yes
<buZz>
flashing white ? O_o still, have never seen that
<SuperMarioSF>
usually it is green
<buZz>
its green solid when charger is charging
<SuperMarioSF>
yes
<buZz>
and white solid when 'power off because of low battery'
<SuperMarioSF>
most time it is green
<buZz>
i havent seen -any- other signalling from led
<buZz>
hmmmm
<buZz>
maybe you messed around with lestes 'led notification' in settings?
<buZz>
and enabled this white flashing? or maybe i did to remove it?
* buZz
wonders
<SuperMarioSF>
it should be default settings...
<SuperMarioSF>
green light, and about each 5 seconds, the white came on for 0.5 second and back to green
<buZz>
either way, do you see the file /sys/class/power_supply/battery/uevent? read it
<SuperMarioSF>
I checked my notification light, it was all checked
<buZz>
IF you are actively doing a calibration 1) POWER_SUPPLY_CHARGE_NOW should be increasing and POWER_SUPPLY_CHARGE_FULL should be increasing when you approach 100% charge
<SuperMarioSF>
here is the result for uevent
<buZz>
POWER_SUPPLY_CURRENT_AVG=-147478
<buZz>
negative means charging
<buZz>
POWER_SUPPLY_CURRENT_NOW=6000
<buZz>
not negative ; mean you are using more power
<buZz>
so the battery cant charge
<buZz>
should be between -100000 and -200000 (for gprs online while charging on good cable + psu)
<buZz>
i havent seen more than -200000 , but i think it -is- capable of it
<SuperMarioSF>
the unit seems 0.000001 amps?
<SuperMarioSF>
if that is true so there is 1.3A charging in to battery
<buZz>
i have no clue what you mean by 'the unit'
<buZz>
POWER_SUPPLY_CURRENT_NOW=6000 <- that value above zero means YOU ARE NOT CHARGING
<buZz>
does POWER_SUPPLY_VOLTAGE_NOW increase? then its charging
<SuperMarioSF>
OK
<SuperMarioSF>
I guess I misread something before,
<SuperMarioSF>
voltage reading is shaky but slowly increasing overall.
norayr has left #maemo-leste [Disconnected: closed]
<SuperMarioSF>
so I just keep it charging until no green light, and use it all day to do this again?
<SuperMarioSF>
what should I expect when battery fully charged about the file /var/lib/droid4-battery-calibration/?
<SuperMarioSF>
ok, then that file really don't have data there. I will wait unitl it is done.
<buZz>
i so dislike that its still POWER_SUPPLY_VOLTAGE_MAX_DESIGN=4200000
<buZz>
while the battery is actually designed for 4350000
<buZz>
meaning about 20-30% more capacity could be there
<buZz>
:(
Twig has quit [Ping timeout: 252 seconds]
<sicelo>
buZz: the led can go crazy once in a while, so SuperMarioSF's experience is ... possible
<buZz>
sicelo: oh, sure yeah, like when USB cable is poorly connected
<buZz>
i'm just telling about my experience, dont really have much more to go on (afaik we never documented all led meanings)
SuperMarioSF has quit [Quit: Client closed]
<sicelo>
i mean ... when it shows patterns you don't expect. in my case, a week or two ago, the green led was permanently on. messing with sysfs didn't help a bit
<buZz>
yeah no clue about 'patterns'
Twig has joined #maemo-leste
<buZz>
sicelo: i had 'green led permanent on, screen enabled, not responding to touch and buttons, not even to powerbutton' just a couple days ago
<buZz>
also , it was SUPERWARM , not doing any HV lipo charging, it was just in my bag, when i pulled it out, it was already in that mode
<sicelo>
Wizzup: do you think N900 can be made to idle with a running system, or unlikely? I hope/plan to look at this at some point with my limited skills, but if you think it's unlikely, maybe I should spend my energy elsewhere
<Wizzup>
sicelo: I think it's a worthy thing to work on, but might be hard without serial
<sicelo>
i bought a level converter to mc guyver a serial connection :-)
<sicelo>
just that life got extra busy as soon as it arrived, but i am hopeful that I'll have a bit more time after end of this month
<sicelo>
and also 2.4 and 2.7v zeners. i'll mostly use a circuit somewhat similar to sre's. the challenge will be pogo pins, but if i fail to find a reliable way, i'll just solder wires to the board :-D
<Wizzup>
I think it would be very useful to identify which drivers block idle
<Wizzup>
even if you don't have immediate code fixes for it
<sicelo>
i'll do that
<sicelo>
2G/3G is luckily not an issue for me in next few years (the perks of living in 'Third World'), so dinosaurs like Droid 4 and N900 still have a bit of a future for me, and since for my use case, N900 modem is more reliable and predictable, i'm not letting go anytime soon
<sicelo>
Wizzup: i think you still never replied to tmlind's email regarding N900 OFF mode. guess you're also busy like everyone :-)
<Wizzup>
sicelo: unfortunately very busy, was just complaining about how busy to a friend :D
<Wizzup>
sicelo: was this about the sysctl for silencing the wakeups?
<sicelo>
or /proc ... compaction.
<Wizzup>
yeah, that
<Wizzup>
yeah, I think that's a case of no time yet :(
Livio has joined #maemo-leste
norayr has left #maemo-leste [Disconnected: closed]
<uvos>
how would serial help you id what drivers block idle?
<uvos>
serial blocks idle
<uvos>
or is that different on omap3?
<uvos>
buZz: "meaning about 20-30% more capacity could be there" yeah no
<buZz>
well, >10% anyway , you saw my figures before :P
<uvos>
maybe 10% at absolute most
Twig has quit [Read error: Connection reset by peer]
<buZz>
but the omap_hqd seems to hang a lot :(
<uvos>
and the caillibration is really inaccurate i would not take its numbers so seriously
<buZz>
its ~1000mAh without my IED mods, and ~1300mAh with
<buZz>
at least on the calibration
<uvos>
in a normal lipo theres about 10% over 4.0v
<buZz>
i mean, reliably ~1000 and ~1300 over several calibration cycles
<buZz>
(talking about the 4.35V one, the 4.4 and higher ones they talk about i never used or seen :) )
<uvos>
yeah but only 10% above 4.2
<uvos>
thats jives with other datasheets
<uvos>
30 dosent
<uvos>
that seams very wrong
<buZz>
either way, i still want to try to replace your constant with mine, to see if all that code works as-is to get 4.35v max_design , and then overwrite charge voltage with 4.35 and run it like that for ~2 months, like i did with my IED patches
<buZz>
btw, i found a third EB41, still need to hook it up, the flexpcb looks a bit busted
eloy_ is now known as eloy
<buZz>
maybe its production date?
<sicelo>
uvos: the guy has a brief sphone review on his blog
<uvos>
buZz: we should check where the value even comes from
<sicelo>
uvos: any idea for idle/off on omap3 (without serial)?
<uvos>
its from the w1 subsystem
<uvos>
it might be concating several things
<uvos>
ie the 8 chars might relate to the host controller
<uvos>
buZz: or we can just go f**k it and use the first nvmem we get
<buZz>
3a31240b as unix timestamp would be Fri Dec 08 2000 18:10:19 GMT+0000
<uvos>
buZz: since its the only chip on that bus on d4
<buZz>
i doubt this battery is 22 years old :D
<uvos>
buZz: but i dont like it
<buZz>
uvos: hehe , thats true, and i dont like that either :)
<buZz>
might cause issues later
<buZz>
tbh i saw very few systems with >1 1wire device
<uvos>
yeah but without checking every mapphone to make sure
<uvos>
.. not a great idea
<buZz>
right, well
<uvos>
as you say
<buZz>
we have a couple in this channel ^_^
<uvos>
well no
<uvos>
theres lots of more exotic ones we dont have
<buZz>
i mean, just to identify the number their EB41 reports with current setup
<uvos>
sure but it needs to work on the 2 bionic bats the mz6xx ones and idealy it would work any mapphone battery
<uvos>
maybe we open every eeprom and grep for |motorola"
<uvos>
also not pretty but would work i gues
<buZz>
yeah CHARGEONLY or something :P hehe
<buZz>
uvos: also we just need to do it once i guess?
<uvos>
no
<uvos>
the kernel realy has no where to store state cross reboots
<uvos>
(also thats very frowned upon)
<buZz>
yeah i mean, once on boot
<uvos>
ofc yeah
<uvos>
sicelo: you mean to debug?
<sicelo>
yes
<buZz>
currently it seems its trying to reread the nvmem file all the time?
<buZz>
somewhat
<uvos>
sicelo: not really sorry, the idle blocking bits will give you some hint
<uvos>
other than that what Wizzup was doing is the best thing i know
<uvos>
(modprobe stuff one at a time)
<uvos>
buZz: it should not
<buZz>
uvos: -sometimes- the endpoints in /sys/bus/w1/devices disappear , and come back later
<buZz>
to me, that seems like something is still happening
<uvos>
hmm
<uvos>
thats wierd
<buZz>
also the continuous messages from omap_hdq in dmesg
<uvos>
sounds like buggynes
<buZz>
which sometimes go so fast that the whole devices locks up
<buZz>
right, ok
<uvos>
maybe the hdq dirver has had a regeression since i used it last
<buZz>
we could make 'all' the charger variables userspace? or module parameters?
<uvos>
lemmy probe it
<uvos>
sure you could make all the values wirteable in sysfs
<buZz>
then do identifying in userland through loading the omap_hdq driver, and unload it after grabbing the data
<uvos>
but generally the kernel shal not allow the user to distroy something from userspace
<buZz>
then some small tool that can analyze nvmem , identify values for charger, and then unload/reload the charger module with those vars, cache em to disk to use again next boot
<buZz>
unless /newbatterywhodid exists or something
<uvos>
thats unsafe
<buZz>
well, the omap_hdq step once can still be done to make it safer, indeed
<uvos>
on bionic there are 4.2 and 4.35v batterys
<buZz>
then /newbatterywhodid isnt needed
<uvos>
the user can switch
<buZz>
does unloading charger module work even? on a booted device
<uvos>
should be ok
<buZz>
well, if loading that with parameters could work, that would make this all workable, i think
<uvos>
not sure why you would need module parameters
<buZz>
i dont think we need to expose all the variables themselves, just a batterytype=x , 0=4.2v plain, 1=EB41 , etc
<buZz>
because it cannot autodetect it now
<uvos>
oh like that
<uvos>
yeah we could do that as a fallback
<buZz>
might be a simple method
<buZz>
and chargevoltage is already overwriteable through sysfs you said, i think?