<buZz>
i doubt many will go upstream, like the systemd one
<buZz>
so maybe our own fork will just stay needed
thunderysteak has quit [Ping timeout: 260 seconds]
joerg has quit [Ping timeout: 265 seconds]
joerg has joined #maemo-leste
mardy has joined #maemo-leste
xmn has quit [Ping timeout: 260 seconds]
Twig has joined #maemo-leste
<freemangordon>
hmm, I did nothing in upower
Twig has quit [Ping timeout: 260 seconds]
<freemangordon>
Wizzup: I think we shall try upower with no patches
<freemangordon>
at least SOC estimation that was implemented there is worse than nothing IMO
<freemangordon>
I had occasional shutdowns because of low battery while applet was reporting 30%-40% or something
Twig has joined #maemo-leste
<sicelo>
iirc vanilla upower has issues on at least D4 and N900. For N900, the issue exists while battery is not calibrated. i forget exact details, but it's probably that there's no LMD in that case, and it throws upower off
<sicelo>
something similar happens with D4 ... although I haven't used vanilla in a long time there, so I forget exact details now
<freemangordon>
sicelo: ok, we may carry some of the patches, if needed. however, I think all those were done when we were on ascii
<SuperMarioSF>
so i am doing recalibration on battery, I removed the file for full charge capacity for old battery is this correct?
<sicelo>
freemangordon: i am trying to get mtdoops working for capturing the kernel hang due to N900 modem. so far i'm not very successful. do you perhaps know how to make it work? i added `mtdoops.mtddev=log` to the cmdline
ceene has joined #maemo-leste
<freemangordon>
yep, that should work
<freemangordon>
but, I think you need onenand drivers enabled as well
<uvos>
so mce reads alot of stuff in the upower module
<uvos>
but thats just an artifact from that module being backproted form sfos
<uvos>
mce dosent use any information provided by this module anywhere except battery-guard
<uvos>
witch will work fine as long as at least voltage is available
<uvos>
personally i think we need some kind of soc estimation, but i agree that the current implementation is terrible
<uvos>
(for the battery applet)
<uvos>
since afaik only the battery applet cares about soc, another option is to simply add some estimation to this instead of upower (if upstream upower is not frendly)
<uvos>
freemangordon: yeah charging_sdl shout be fixed
<freemangordon>
sorry, I meant - yes, lets put modem stuff in chimaera
<uvos>
ugh please note the bug where the modem stuff breaks all connections includeing wifi
<uvos>
if the modem dosent come online for any reason
<uvos>
thats a pretty terrible thing to expose stable to imo
<Wizzup>
chimaera is not stable
<uvos>
then maybe build just a devel image
<Wizzup>
imo we should just fix the bug
pere has quit [Ping timeout: 260 seconds]
<uvos>
sure but if you build just a "stable" chimaera im not sure what the path here is besides fixing all bugs imidiatly and then branching a devel then
<uvos>
but that seams overly ambitious since im shure chimaera will have some new bugs that need attention first
<uvos>
while if we start with just a devel chimaera the path makes more sense, build devel, stabilize, and then branch out a chimaera-stable
<uvos>
but do what you like
<freemangordon>
uvos: I think this algo is a bit pessimistic
<freemangordon>
(for calculation of the SOC)
<uvos>
being a bit on the pessimistic side is imo better than being on the optimistic side
<uvos>
depends on how mutch ofc
<uvos>
so i think targeting being slightly pessimistic with soc estimation makes the most sense
<freemangordon>
reports 92% for 99%
<freemangordon>
ok
<freemangordon>
Ri = 0.104746
<freemangordon>
which looks sane to me
<uvos>
if its most pessimistic at the top end
<uvos>
this is imo alos no problem
<uvos>
since hopefully battery will be callibrated then
<freemangordon>
the problem is it never shows 100 %
<freemangordon>
but yeaah
<uvos>
sure but at least on d4 this is no problem
<uvos>
as callibrated value will take over
<freemangordon>
right
<uvos>
also you could have it show 100% whenever the kernel claims that the battery is fullt
<freemangordon>
well...
<uvos>
i know on d4 the kernel never claims this
<uvos>
for resonable amounts of time
<freemangordon>
do you want the latest version to test?
<freemangordon>
actually, I'll paste it here for whoever wants to
<uvos>
sure i can run it for a bit to see what it reports ri wise
<Wizzup>
uvos: I think your algo is a bit pessimistic wrt fixing bugs :P
<Wizzup>
we also still have annoying bugs in non-devel
<uvos>
being a bit on the pessimistic side is imo better than being on the optimistic side
<uvos>
depends on how mutch ofc
<uvos>
so i think targeting being slightly pessimistic with chimaera migration makes the most sense
<uvos>
Wizzup: :P
alex1216 has quit [Quit: WeeChat 2.3]
<freemangordon>
sicelo: could you please build and run what I pasted ^^^ on n900? to compare calculated VS reported value
noidea_ has quit [Ping timeout: 265 seconds]
<freemangordon>
you will have to change BATTERY_FILE define
SuperMarioSF has joined #maemo-leste
noidea_ has joined #maemo-leste
ceene has quit [Ping timeout: 260 seconds]
pere has joined #maemo-leste
<SuperMarioSF>
Wizzup , I just sent you the images of XT883, please check mailbox. (105MiB, not attached with mail, but in a OneDrive share link instead.)
<SuperMarioSF>
with some notes attached.
<Wizzup>
it's downloading, thanks
pagurus has quit [Ping timeout: 260 seconds]
<Wizzup>
the front seems to in a good condition
<SuperMarioSF>
the back.... oof
<Wizzup>
yeah, oh well :)
<Wizzup>
notes look great
<SuperMarioSF>
so sticky, much gunk, wow.
<Wizzup>
yeah, this happens with old plastic sometime I think
<SuperMarioSF>
usually with some skin like texture, which is a thic layer of latex.
<SuperMarioSF>
I have a Lenovo Thinkpad X201i
<SuperMarioSF>
and it suffers the exactly same problem
<SuperMarioSF>
*thin layer of latex
<SuperMarioSF>
it is very diffcult to cleanup the mess.
<SuperMarioSF>
but
<SuperMarioSF>
if the phone was actively used back then, this issue won't be that problematic
<SuperMarioSF>
this also shows the phone is barely used and just sitting in the box for a decade.
pere has quit [Ping timeout: 256 seconds]
<uvos>
oh btw SuperMarioSF
<uvos>
there was another china exlusive (afaik) mapphone
<SuperMarioSF>
?
<SuperMarioSF>
which one?
<uvos>
xt881 codename Yangtze
<uvos>
this is also i think the last mapphone none of us have :P
<uvos>
at least this device has a chineese regonal rom image
<uvos>
so i presume it was china only
<uvos>
and yeah indeed this is the final mapphone we dont have
<SuperMarioSF>
XT881
<SuperMarioSF>
product name "Electrify 2"
<SuperMarioSF>
1GB RAM + 8GB internal storage
<SuperMarioSF>
1780mAh battery
<SuperMarioSF>
Android 4.0 on OMAP4430
uvos has quit [Quit: Konversation terminated!]
<SuperMarioSF>
sadly there is almost no item available on second-hand market.
<SuperMarioSF>
the only one seems only have phone itself.
<SuperMarioSF>
because lack of a physical keyboard, this phone may be treated as any "normal" phone, so not popular in collector's terms, thus usually not much sales.
uvos has joined #maemo-leste
<uvos>
it probubly also dident sell anny
<SuperMarioSF>
maybe.
<uvos>
its mostly uninteresting being almost same as the more common xt91x
<SuperMarioSF>
or they sell many but they all died, due to age and lost of interest.
<uvos>
sure
<uvos>
just maybe interesting from a collectors point of view to have all mapphones
<tmlind>
heh
<SuperMarioSF>
so you actually want one, despite it will only came with phone only?
<uvos>
maybe, how much?
<Wizzup>
Almost everything we get from ebay is just the phone
<SuperMarioSF>
hmmmmm
<SuperMarioSF>
CNY 99
<SuperMarioSF>
dirt cheap.
<Wizzup>
so 13,37 eur
<Wizzup>
I like that ;)
<SuperMarioSF>
but something weird
<SuperMarioSF>
the listing says it was a "English language phone"
<uvos>
hmm
<uvos>
maybe it was sold somewhere else too
<SuperMarioSF>
and system UI clear shown English.
<uvos>
let me check us
<SuperMarioSF>
Wizzup, wil this time you will get 2 XT883 with maybe almost complete retail box.
<Wizzup>
SuperMarioSF: yeah, that sounds great, I was surprised by the photos that you emailed, the device is so complete.
<SuperMarioSF>
the first one I guess is the complete one, except plastic wraps of course.
<uvos>
there are none on us ebay at least
<uvos>
so no idea
noidea_ has quit [Ping timeout: 260 seconds]
<freemangordon>
uvos: where did you get the formula from?
<uvos>
freemangordon: dunno via pavel
<freemangordon>
hmm
<uvos>
dont know where it came from originally (besides the comment that it comes with)
<SuperMarioSF>
from the listing, the second one may lack of some boring booklets, but earphone, charger, cable is present. maybe lacking one battery (seems only have one).
<freemangordon>
I opened that post
<freemangordon>
only half of the formula is there
<Wizzup>
I have hildon-desktop and hildon-home in my vm
<freemangordon>
:)
<freemangordon>
good boy ;)
<uvos>
ok maybe pavelmachek can enlighten us, if we know how to contact him
<SuperMarioSF>
the second one maybe being used for a little, not good as the first one, but good enough.
<freemangordon>
uvos: via mail, but how did you get it initially?
<Wizzup>
just apt-get install xorg-server hildon-desktop hildon-home osso-xterm, reboot and then log in via and start them
<freemangordon>
uvos: ok, I'll send him a mail
<SuperMarioSF>
the second one may have much less gunk on the back cover. seems in good condition.
<Wizzup>
note that at this point there is a xorg init script I think, so you won't be able to use console normally
<Wizzup>
SuperMarioSF: great :D
<Wizzup>
SuperMarioSF: I think the back cover is the same as the droid 3, which I have here, back cove rwise
<SuperMarioSF>
oh I noticed the second one's protect film for back side of the screen is present, just missing the pull tab.
<SuperMarioSF>
thanks to weird habits of Chinese people: Not peeling off any protective cover if possible
<Wizzup>
heh
<SuperMarioSF>
🤣
<uvos>
not just chinese people, i routinely make fun of my gf for this :P
<SuperMarioSF>
hmmmm
<SuperMarioSF>
maybe for a known fate of reselling these thing?
<SuperMarioSF>
I certainly don't care that much.
Daanct12 has joined #maemo-leste
<SuperMarioSF>
but I will have extra protection for my devices especially for screen.
Danct12 has quit [Ping timeout: 260 seconds]
<SuperMarioSF>
scratched screen is so painful to watch
<SuperMarioSF>
but I certainly not reselling anything I have, except very rare cases.
<uvos>
for some reason you can buy d4 screen protectors on german ebay, very conviniant
<SuperMarioSF>
and my storage is filled with those strange things.
<SuperMarioSF>
oh
<uvos>
dunno who or why someone would sitting on d4 accesorys in DE
<SuperMarioSF>
In china there is a type of service to customize made screen protection film.
<uvos>
sure but these ship way to fast to be from china
<SuperMarioSF>
oh that is not "ship"
<uvos>
i dont think it would be profitable to produce them here either
<uvos>
SuperMarioSF: sure even air freight
<uvos>
took like 2 days to arive
<SuperMarioSF>
you take your phone, any strange one, the only requirement is having a screen.
<SuperMarioSF>
to a service shop
<SuperMarioSF>
and they cut a customized shape for you
<SuperMarioSF>
just wait about 15min
<SuperMarioSF>
you can leave with new film applied
<SuperMarioSF>
15min plus maybe 30min of walk time, surely faster than 2 days of shipping
<uvos>
sure no doubt
<SuperMarioSF>
but this type of protection is only a layer of plastic.
<SuperMarioSF>
I usually want a layer of hardened glass
<SuperMarioSF>
which is much diffcult to manufacture and customized.
<SuperMarioSF>
and it seem there is no such thing supplied any more in China.
<SuperMarioSF>
(for D4)
<SuperMarioSF>
but if you want to sell many of them, you can order a whole batch, and they will customize made for you.
<SuperMarioSF>
as long as the screen is flat, they can do it.
<SuperMarioSF>
.
<SuperMarioSF>
wow
<SuperMarioSF>
the replaced battery of my D4 lasted the whole day
<SuperMarioSF>
and have 45% battery left
<bencoh>
wow
<bencoh>
maybe I should really order a new one as well
<Wizzup>
at this point this should be expected maemo leste
<SuperMarioSF>
with 3G modem always online for phone and SMS
<Wizzup>
expected with maemo leste*
<SuperMarioSF>
yup
<Wizzup>
maybe even more
<SuperMarioSF>
but not expected with some old new stock battery replacement
<Wizzup>
mhm
<SuperMarioSF>
the old one only have about 6~8 hours, 1233mAh
<SuperMarioSF>
since this is the first boot up, I haven't able to start calibration yet.
<Wizzup>
wow, that can't have been 1233mAh
<Wizzup>
I get over a day easily on 1081maH
<Wizzup>
mAh*
<SuperMarioSF>
weird...
<SuperMarioSF>
I removed calibration file, so I have to depleate the battery and recharge them up to 100% to gei it done?
<Wizzup>
I think so, ideally we'd have some mode for it :)
noidea_ has joined #maemo-leste
Twig has joined #maemo-leste
<SuperMarioSF>
I forgot how to do that... and I'm not able to find the document for it (maybe the second time)
<freemangordon>
SuperMarioSF: most-probably those 45% are fake
<freemangordon>
if not calibrated, you have no more than 5-8%
<SuperMarioSF>
and there is a weird thing
<freemangordon>
ATM we have a really bad voltage based SOC estimation
<SuperMarioSF>
I first depleated the battery
<SuperMarioSF>
really hard
<SuperMarioSF>
it shut itself down
<SuperMarioSF>
and I am not able to boot it to desktop again, even with power plugged in
<SuperMarioSF>
the reading from my meter shown there is no current usage from power cable during the boot .
<freemangordon>
re-plug the USB cable
<SuperMarioSF>
I tried but it doesn't work.
<freemangordon>
latest kernel seem to have broken something in that regard
<SuperMarioSF>
I have to boot into android side, actually the charger animation
<freemangordon>
the same happened here today
<SuperMarioSF>
at there I can charge
<SuperMarioSF>
at 1.5A
<freemangordon>
yeah
<freemangordon>
we have charger-detection WIP
<freemangordon>
still not in the repos
<SuperMarioSF>
but I have no idea if this can break the calibration
<Wizzup>
that would be good to have, then we can actually leave devices on usbnet and access them remotely :P
<SuperMarioSF>
if I can at least charge it to around 10% from android side, I can boot maemo normally.
<SuperMarioSF>
is this can affect calibration?
<Wizzup>
charge-mode should be able to do this for you too
<Wizzup>
(the charging)
<SuperMarioSF>
so I can just depleate battery, boot to Android charge mode, and charge to 100%, back to maemo, the calibration wil just done at that moment?
<uvos>
no
<SuperMarioSF>
you mean the maemo charge mode?
<uvos>
you have to boot from empty and then charge to full with the mainline kernel
<uvos>
or the other way around
<SuperMarioSF>
then how can I boot from empty state if mainline kernel doesn't use power from power supply?
<uvos>
this works fine here
<uvos>
but i think its broken
Daaanct12 has joined #maemo-leste
<uvos>
because cpcap-charger starts charging on usb plugged irq
<uvos>
or vbus irq, i havce to check the code
<SuperMarioSF>
so I should plug the cable in right after the module loaded?
<uvos>
but point is its a irq
<uvos>
and i dont see how this can not break when the lead is allready plugged on boot
<freemangordon>
uvos: this used to work just fine with 5.18
<uvos>
i know
<uvos>
but i dont see how this can be not racy
<uvos>
SuperMarioSF: yes
<SuperMarioSF>
OK i will try
<SuperMarioSF>
the cpcap-charger module will load before or after the kernel fb console initialized?
<freemangordon>
uvos: with extcon driver no irq will be needed
<uvos>
freemangordon: great
<uvos>
SuperMarioSF: it probes slightly after
<SuperMarioSF>
oh
<uvos>
i think
<SuperMarioSF>
maybe that is the bad news
Daanct12 has quit [Ping timeout: 264 seconds]
<SuperMarioSF>
because I often see it loads and immediately detected a low battery and just shut down
<SuperMarioSF>
I basically have no chance to plug it in
<buZz>
you can plug usb before xorg starts
<SuperMarioSF>
I know
<buZz>
to prevent the autopoweroff from low voltage
<uvos>
buZz: if his battery is below the kernels threshold
<SuperMarioSF>
but that didn't even give me a chance even for xorg
<SuperMarioSF>
I see those low battery message from fb console
<buZz>
oh ok
<uvos>
(should never happen really but ok) that wont help @buZz
<uvos>
SuperMarioSF: in this case charge with android and try again
<uvos>
this time soon after device shuts down due to low battery
<uvos>
or wait for freemangordon to fix usb detection
<SuperMarioSF>
OK
<SuperMarioSF>
I will try first
<SuperMarioSF>
if not working, I wait for it fixed.
Daaanct12 has quit [Ping timeout: 260 seconds]
<SuperMarioSF>
at least this time I won't depleate it too hard.
<freemangordon>
I think I shall stop waiting upstream and just do whatever I think is sane
<SuperMarioSF>
last time I just ran a stress test on it
<freemangordon>
later on, if they reply in this life, I can change it
<SuperMarioSF>
maybe it was too hard
<SuperMarioSF>
about upstream...
<SuperMarioSF>
Linux maintainers are hard to work with these days...
<freemangordon>
no, as I said, voltage-based SOC estimation we use now is useless
akossh has joined #maemo-leste
<freemangordon>
hard? I would say impossible, they don;t reply in weeks for 2 liners :(
<SuperMarioSF>
sometimes they reject your thing and say nothing meaningful to solve the problem
<SuperMarioSF>
for example
<Wizzup>
freemangordon: got a moment to help me think about maemo-security-certman ?
<SuperMarioSF>
you have a new hardware design support, you submitted your change and fixed many problem.
<freemangordon>
SuperMarioSF: or this, yes
<SuperMarioSF>
and they rejected your change, even you fixed anything the current state went wrong.
<Wizzup>
freemangordon: in lib/certman/cryptoki_module.c there is a duplicate declaration of some define that is now also defined in nss, it's CRYPTOKI_VERSION_MAJOR and CRYPTOKI_VERSION_MINOR. I'm not sure if we can just use NSS's version, or if we'd need to change our cryptoki implementation using nss to match the version required
<SuperMarioSF>
they say "I haven't seen your hardware is widely used, so support for it will be pointless" like things
<SuperMarioSF>
and their mind is still stopped at a decade ago for that hardware.
<SuperMarioSF>
*similar hardware
<freemangordon>
Wizzup: not sure I can help without looking in the code
<Wizzup>
freemangordon: my guess if that we might want to rename our const and use it, since it's not clear if we will support it
<freemangordon>
this is what we need to have working charger detection
<SuperMarioSF>
the funny thing is, the same person have been rejected, just ported NetBSD for its hardware design, way faster than Linux does.
<freemangordon>
not only on d4, but on any device in general
<freemangordon>
and yet the only comment so far was "atomic notifiers are horrid"
<SuperMarioSF>
hmmm I wonder those maintainer is working in a atomic way :P
<SuperMarioSF>
(workflow about doing the actual changes)
<sicelo>
freemangordon: N900 is bootlooping, so can't test. but I may do so on my postmarketOS install
<sicelo>
mmm, i see glib.h there ... wonder if musl will like that
<freemangordon>
yeah, we don't really need leste for that
<freemangordon>
ummm
<freemangordon>
glib is not libc6
<uvos>
admittedly confusing with one being called glib and a popular implementation of the other glibc
<Wizzup>
uvos: maybe for new kernel upgrades we should use leste-experimental
<Wizzup>
it's not great to have our n900 devel users have a bootlooping kernel
<uvos>
i can do that
<Wizzup>
great
<uvos>
altho imo we should keep stable closer to devel and tell people who use devel: tough
<uvos>
but ill do what you prefer
<sicelo>
"and tell people who use devel: tough" - i completely disagree. that's like showing middle finger to those people. the point of devel is to get testers, no?
<uvos>
the point of devel is that it can break at any time
<sicelo>
i don't understand why you noticed that it broke n900, but kept quiet about it
<sicelo>
anyway
<sicelo>
freemangordon: sure will do it in a bit
<uvos>
? i noticed after it was in devel allready
<sicelo>
yes, kept quiet still.
<uvos>
anyhow imo adding exipiramental dose nothign but add another layer, makeing devel stable and expieramental be the new devel
<sicelo>
i waited around two or more days until i upgraded. i was so sure you were not aware of the bootloop
<sicelo>
but yes it's immaterial
<uvos>
i dident know anything was wrong with n900 for any siginificant amount of time...
<uvos>
besides this is pointless, rn we are wating on Wizzup to grab serial output
<BlagovestPetrov[>
libicd-network-wpasupplicant fails, again because of flags and old gtk. checking..
<Wizzup>
uvos: ok, let me do it tonight
<Wizzup>
tmlind damned me by giving me his serial ;)
Danct12 has quit [Ping timeout: 260 seconds]
<tmlind>
hehe
<uvos>
same trojan horses Wizzup hands out when it supplies devices :P
<sicelo>
freemangordon: after compiling, needs to be run over a period of time?
<sicelo>
still must boot pmOS though
<freemangordon>
sicelo: well, as soon as you run it it starts printing results
<freemangordon>
new value is calculated and print every 30 seconds
<uvos>
probubly we should test it on a verity of soc on different devcies
<BlagovestPetrov[>
I see that you already made a branch for Chimaera but it was failing for me
<Wizzup>
BlagovestPetrov[: ah just fixed it
<Wizzup>
sorry :( :(
<Wizzup>
I shouldn't get ahead of you :)
<BlagovestPetrov[>
it's ok :D
<BlagovestPetrov[>
i'm going to have a dinner and we can sync after
<Wizzup>
cool
<Wizzup>
qt5 will still be some work I bet
dsc_ has quit [Ping timeout: 268 seconds]
<Wizzup>
qt 5.11 to qt 5.15
<sicelo>
freemangordon: regarding estimating SOC, maybe there'll be some pointers in bme(-replacement) too? fremantle always had a way to know percentage even on newly inserted battery
* uvos
salvates about qt 5.15 wrt possibilies of apps to use from plamo
<Wizzup>
is it a big difference?
dsc_ has joined #maemo-leste
<uvos>
Wizzup: yes huge
<uvos>
since 5.15 is the final qt5 release
<Wizzup>
good for you, not good for me, having to do the rebasing
<uvos>
it has lots of support
<Wizzup>
:D
<uvos>
Wizzup: :P
<dsc_>
qt6 is gonna be painful
<uvos>
i presume chimaera dosent have qt6?
<uvos>
otherwise additional outch
<Wizzup>
they removed qt4
<Wizzup>
in bullseye
<dsc_>
qt6 is gonna be painful because its not backward compatible with QML "1.0"
<dsc_>
they rewrote it basically
<Wizzup>
dsc_: speaking of which, openmediaplayer is qml 1.0 but I never got it to work :p
<Wizzup>
and I suspect qt5 will be around for many years to come
<dsc_>
right
<dsc_>
oh for sure
<dsc_>
I think the community is still waiting on qt6 to get stable, just like with qt5, it only got 'usable' starting from 5.7 :P
<dsc_>
plus some drama around the license changes
<Wizzup>
yup
<Wizzup>
we need to work on out qt5 support in maemo
<Wizzup>
the colour problems still being there is a bit embarrasing
<Wizzup>
and the input method also really needs to happen soon
<uvos>
we need someone who is good with themes i gues
<uvos>
the gtk2 thems are also broken
<uvos>
wrt the buttons
<Wizzup>
where do you see those being broken?
<uvos>
anywhere where they expand beyond the minimal size (eg. pinentry)
<uvos>
iirc this is beacuse the bitmap map is wrong
<uvos>
so the wrong subimages are selected
<uvos>
the qt issue is useing base color on window color instead of window text with window color
<uvos>
the themes/ gtk2 theme translator dose this
<Wizzup>
so I am not sure if this is a theming problem
<Wizzup>
(the gtk scaled buttons)
<uvos>
yes it is at least it renders ok in non maemo themes
<BlagovestPetrov[>
yeah, qml is completely rewritten
<BlagovestPetrov[>
most of the qml libs are with different include names
<Wizzup>
qml theming in general is also tricky I think
<BlagovestPetrov[>
нуфр
<BlagovestPetrov[>
ops, I mean, yeah
<freemangordon>
uvos: I fixed some of the themes
<freemangordon>
fix shall be ported to other themes as well
Danct12 has joined #maemo-leste
<tmlind>
so i just pushed out updated sources for utagboot and buildroot, and new binaries for droid4-kexecboot with initial support for xt910
<tmlind>
also the binaries are now there for mz609 and mz617
<tmlind>
ok cool, yeah if you have the patch or dts i'll give it a try at some point
norayr has left #maemo-leste [Error from remote client]
mp107 has joined #maemo-leste
<uvos>
yeah looking for it
norayr has joined #maemo-leste
<tmlind>
freemangordon, uvos: so with the battery calculation, can the coulomb counter measurement be used? it's a long term p = ui basically, i guess voltage and current still needs to be sampled for resistance estimate?
<uvos>
tmlind: i dont think the counter is usefull for estimation really, you could estimate once and then use the counter from there, but this will give worse results than just allways estimateing
<uvos>
so i dont see how it could be usefully used atm
<tmlind>
ok
<uvos>
well, if you get really fancy you could use the counter while callibrated to write a offset file that gives you a table of the differences between the output of the estimator and the real soc
<uvos>
and then use that when uncallibrated
<uvos>
(essentally create the soc table in the eeprom on the fly)
<tmlind>
yeah i guess
<tmlind>
i think the sampling times for the cpcap iio devices can be configured too if some average voltage or current is needed
<uvos>
oh really?
<uvos>
that would be great
<tmlind>
yeah there are some mystery hw values that seem to relate to the sample frequency and lenght possibly
<sicelo>
freemangordon: my n900 battery isn't calibrated, so i guess that's throwing that program off. anyway, https://paste.debian.net/1262323/
<uvos>
sicelo: the point of this programm is to work with uncallibrated batteries
<sicelo>
ok
<uvos>
sicelo: its interesting
<uvos>
that you Ri values bounc around so mutch
elastic_dog has joined #maemo-leste
elastic_dog has quit [Killed (silver.libera.chat (Nickname regained by services))]
* tmlind
zzz
<uvos>
gn8
norayr has left #maemo-leste [Error from remote client]
<sicelo>
/* use linear approx. below 3.756V => 50.00% assuming 3.3V => 0% */ ... at least the fg on n900 is programmed for 6% = 3.248V. that's when a calibration cycle completes
<uvos>
50mV at low soc is mutch less than mesurement error here
<freemangordon>
sicelo: yes, 'reported 0' is because it is not calibrated
<freemangordon>
but, it would have been good if you can run that on calibrated system
<freemangordon>
I want to see how well estimation behaves compared to real values
<sicelo>
yeah, to see how closely the calculation matches reality
<sicelo>
ack
<freemangordon>
right
pere has joined #maemo-leste
mp107 has joined #maemo-leste
<freemangordon>
hmm, how old is that battery? 10 years?
<sicelo>
what's 'r'?
<freemangordon>
currently calculated internal resistance
<sicelo>
i don't remember age. probably 2016
norayr has joined #maemo-leste
<freemangordon>
I guess that's why it has so high Ri
<sicelo>
:-)
<freemangordon>
but yeah, it will be interesting to compare calculated vs calibrated
<sicelo>
and works good enough so far, despite n900 not doing pm with linux atm
<freemangordon>
anyway, zzz time, night!
<sicelo>
i'll try, but no promises (re: calibration) since i often need to remove the battery from device
Twig has quit [Remote host closed the connection]
<vectis>
Wizzup: Finally got bluetooth audio on the d4 working. I don't know if it was needed, but the last thing I changed was to install bluez-firmware.
<Wizzup>
vectis: good to know, there's a lot going on but glad to hear it works
<Wizzup>
(a lot going on for me, so I didn't do a write up yet)
<vectis>
Wizzup: No problem, I can see your very busy.
<Wizzup>
if you have some notes, please do share them
<Wizzup>
btw tmlind freemangordon - I didn't forward port the fb_id patch for the droid 4, let's see if we still need it for xorg
<sicelo>
btw, at least on N900, i noticed shutdown is very slow, compared to shutdown while running pmOS. it doesn't bother me, but it's quite curious
<Wizzup>
shutdown can be improved in many ways
<uvos>
it also still hangs on d4 for unkown reasons sometimes
norayr has left #maemo-leste [Error from remote client]
<sicelo>
i believe modem is brought online by cellulard? what starts it, since it doesn't explicitly exist in /etc/runlevels
<Wizzup>
it should have an init script
<Wizzup>
/etc/init.d/cellulard ?
norayr has joined #maemo-leste
norayr has left #maemo-leste [#maemo-leste]
norayr has joined #maemo-leste
norayr has left #maemo-leste [#maemo-leste]
<sicelo>
really odd. even removing that ... system still bootloops (but not system with dead modem)
<sicelo>
i'll disable ofono to test, but just having ofono running doesn't cause issues in pmOS, and even list-modems is fine
norayr has joined #maemo-leste
<Wizzup>
sicelo: blacklist the module
<Wizzup>
icd2 also powered the modem iirc
<Wizzup>
it just doesn't manage online/offline
<sicelo>
oh, that could be it then. i just thought all this was now in cellulard :-)
<uvos>
Wizzup: freemangordon: so if i want to add new config stuff
<uvos>
that shal be set by a system settings applet