# 2nd Init Rom's and 1% battery readouts



## cubsfan187

Let me start by saying that I have been kinda blasted for bringing this up in different threads of these 2nd init roms and am not looking for that here. I'm trying to understand this a little better and find out if there is anyone looking into it. This is a feature of the Froyo based 2nd init roms I miss. (and others do as well)

Is there a way to get the 2nd init roms to report in 1%? I know that on the 602 blur based roms (Shuji,SSM,Vortex) they report in 10% BUT battery widgets such as battery monitor and moto charge will give you 1%. Now switch to roms such as CM7 and MIUI on the GB kernel, and you get 10% and that's it. If you use things like those battery widgets I mentioned, you get readouts like 148293406%. I'm trying to figure out why that is. In the froyo versions it was as easy as adding a line to the build.prop file. But the GB kernel is not being very nice or cooperative about it. Is it something in the way the bootloader is hijacked on this kernel? Is it something in the build.prop file that is preventing it? Or is it something just can't be figured out and fixed?

I guess I'm asking for myself. Maybe to see what I can do to help figure it out. Maybe to see if it's even possible. Or maybe just to learn a little more about the way things work. Whatever way it is, if all you're gonna do is blast me as well, then please don't bother to reply. I do not want to start a words war about something like this. I'm just looking for info and that's it.

Thanks all!


----------



## gregg0829

I am in agreement with you. I miss the 1% as well. Hope you or someone is able to update this.


----------



## Nis

I can give a little bit of info on how 1% increments are read.

Battery level is output on almost all phones at /sys/class/power_supply/battery/capacity. For some reason Moto phones output 10% increments to this file instead of 1%. Moto phones, however, also output 1% increments to /sys/class/power_supply/battery/charge_counter. This is the file that is read by some battery widgets to get 1% increments. CM7 also has the ability to read battery level from this file based on the value in /system/build.prop.

On CM7GB, though, /sys/class/power_supply/battery/charge_counter doesn't hold the 1% battery level but probably some value below its minimum value. Why it does this on CM7GB and not on stock or the Blur-based ROMs is a mystery. There is probably some Blur library that is responsible for setting this file to the correct value.


----------



## cubsfan187

That very well could be. But I remember a time when people were begging P3Droid to make a 1% battery fix for froyo roms way back when and he said then it wouldn't work. So months later, along came CM7 and within a month of it's release was the 1% battery. Why Moto wouldn't just do this from the beginning is beyond me.

If it's a blur lib, couldn't someone (with WAY more skills than I have) kinda pull apart a blur based rom and see if any of the code in there could be useful in making the necessary changes to get it coded right?

I read in the CM4GB thread that someone working on the MIUI4GB rom thinks that the charge light "bug" and the 1% battery readout may be connected. I wonder if that is the case somehow.


----------



## cubsfan187

Haven't seen any progress on this yet. Has anyone else? (the charge light being linked to the 1% batt is what I'm talking about)


----------



## Jordan8

cubsfan187 said:


> Let me start by saying that I have been kinda blasted for bringing this up in different threads of these 2nd init roms and am not looking for that here. I'm trying to understand this a little better and find out if there is anyone looking into it. This is a feature of the Froyo based 2nd init roms I miss. (and others do as well)
> 
> Is there a way to get the 2nd init roms to report in 1%? I know that on the 602 blur based roms (Shuji,SSM,Vortex) they report in 10% BUT battery widgets such as battery monitor and moto charge will give you 1%. Now switch to roms such as CM7 and MIUI on the GB kernel, and you get 10% and that's it. If you use things like those battery widgets I mentioned, you get readouts like 148293406%. I'm trying to figure out why that is. In the froyo versions it was as easy as adding a line to the build.prop file. But the GB kernel is not being very nice or cooperative about it. Is it something in the way the bootloader is hijacked on this kernel? Is it something in the build.prop file that is preventing it? Or is it something just can't be figured out and fixed?
> 
> I guess I'm asking for myself. Maybe to see what I can do to help figure it out. Maybe to see if it's even possible. Or maybe just to learn a little more about the way things work. Whatever way it is, if all you're gonna do is blast me as well, then please don't bother to reply. I do not want to start a words war about something like this. I'm just looking for info and that's it.
> 
> Thanks all!


Do the random numbers that are being put out on the GB kernel ROMs seem to have any meaning? Maybe it's something that just needs translated into a percent?


----------



## Nemo aeternamn

"Jordan8 said:


> Do the random numbers that are being put out on the GB kernel ROMs seem to have any meaning? Maybe it's something that just needs translated into a percent?


No... as those numbers read the same no matter the battery level.. I for one love the one preteen read...and the duke that reports out is actually in /sys/devices/platform/cpcap_battery/power_supply/battery
And it's something in the battery management services that reports to these files that is broken... I've been looking into this... But haven't figured out a quick fix till one percent can be made properly...

Edit: first sentence makes sense now

We have nothing to fear but running out of beer


----------



## cubsfan187

Well I'm glad someone is still trying for this. Its a feature I definitely miss. If there is anything I can test, just ask. I'm always happy to learn and help when I can.


----------



## blaineevans

Nemo aeternamn said:


> No... as the studio the same matter the battery level... I for one love the one preteen read...and the duke that reports out is actually in /sys/devices/platform/cpcap_battery/power_supply/battery
> And it's something in the battery management services that reports to these files that is broken... I've been looking into this... But haven't figured out a quick fix till one percent can be made properly...
> 
> We have nothing to fear but running out of beer


Took me a few read through's to get the first couple sentences, haha. Auto-correct fail I'm assuming.


----------



## cubsfan187

I'm hoping there is something that I can try/test to get this working. I'm gonna ask in the miui thread too. I wanna know if the charging led 'bug' and 1% are connected somehow.


----------



## Nemo aeternamn

"cubsfan187 said:


> Well I'm glad someone is still trying for this. Its a feature I definitely miss. If there is anything I can test, just ask. I'm always happy to learn and help when I can.


If you want... What I'm doing right now... Take apart a blur build... And grab the battery files... Not the ones in the location noted above... As they only report what's being read..

This would be easier if I had a phone to play around with... as I only have my day to day phone to use

We have nothing to fear but running out of beer


----------



## strikeir13

cubsfan187 said:


> I'm hoping there is something that I can try/test to get this working. I'm gonna ask in the miui thread too. I wanna know if the charging led 'bug' and 1% are connected somehow.


I doubt this very much. Based on Nis's explanation of how battery percentages are read, I would be very surprised to hear that the charging LED is at all related to them.

Some might think that because the LED goes off when the phone is completely charged that they would be related, but I bet more that the LED is related to whether the phone is drawing current from the charger or not.

If anyone knows for certain otherwise, please correct me...

Sent from my CM7 DROIDX.


----------



## cubsfan187

Same here. Only my everyday X.

What location do I need to look in for the batt files?


----------



## cubsfan187

"strikeir13 said:


> I doubt this very much. Based on Nis's explanation of how battery percentages are read, I would be very surprised to hear that the charging LED is at all related to them.
> 
> Some might think that because the LED goes off when the phone is completely charged that they would be related, but I bet more that the LED is related to whether the phone is drawing current from the charger or not.
> 
> If anyone knows for certain otherwise, please correct me...
> 
> Sent from my CM7 DROIDX.


I would think the best way to try this is to (maybe) is to try and get a logcat on a blur based rom while a 1% widget is working and then on a 2nd init rom. Maybe compare the differences. Just a thought.

I have no experience with adb or alogcat.


----------



## BMc08GT

Anyone still on miui froyo than can pull something for me?

Email me at [email protected]


----------



## DXC

I'm working on 1%, you can view my project notes in the link in my signature. They're really just notes for me so don't expect them to be entirely coherent.


----------



## Jordan8

BMc08GT said:


> Anyone still on miui froyo than can pull something for me?
> 
> Email me at [email protected]


I'm on cm7 Froyo if that counts.


----------



## cubsfan187

Hopefully you can pull a logcat and see what is happening when it's reporting 1% and then it will narrow down (I think) what to look at on gb.


----------



## cubsfan187

"droidxchat said:


> I'm working on 1%, you can view my project notes in the link in my signature. They're really just notes for me so don't expect them to be entirely coherent.


I finally got to read your notes on it and about 1/2 of it I got...lol. hopefully it all works out soon. If I can be any help somehow let me know please. Thanks for your hard work on this much missed feature.


----------



## DXC

I'm working on it as we speak, here's what i'm lookin at now:

http://img508.imageshack.us/img508/8375/dxccomparison.jpg


----------



## cubsfan187

Awesome!! It looks like it's closer (kinda) to being figured out. I'm not sure which side of the pic is froyo and which is GB but I can see the differences in the coding and the way it reads out.


----------



## bobAbooey

woot woo

You guys are great


----------



## cubsfan187

Lol! Not me...it's all DroidXChat. I'm just trying to help anyway I can (with NO coding or programming experience) to get it working on the GB kernel. Let's just hope that it works.


----------



## cubsfan187

droidxchat said:


> I'm working on 1%, you can view my project notes in the link in my signature. They're really just notes for me so don't expect them to be entirely coherent.


I was trying to follow those notes but it looks like you changed your sig and it doesn't include them anymore.


----------



## cubsfan187

Chevy tweeted earlier that he's got it working (testing) and may have the 1% working!!

Sent from my CM7 DROIDX using RootzWiki Forums


----------



## bobAbooey

Woot wooooooooooo


----------



## Nemo aeternamn

"cubsfan187 said:


> Chevy tweeted earlier that he's got it working (testing) and may have the 1% working!!
> 
> Sent from my CM7 DROIDX using RootzWiki Forums


Awesome!!

We have nothing to fear but running out of beer


----------



## ImaComputa

Nice. I wonder if it will be accurate?


----------



## cubsfan187

He said not as accurate as the charge count but very close. I tried to get him on twitter but no answer on it yet.

Sent from my CM7 DROIDX using RootzWiki Forums


----------



## DXC

"cubsfan187 said:


> He said not as accurate as the charge count but very close. I tried to get him on twitter but no answer on it yet.
> 
> Sent from my CM7 DROIDX using RootzWiki Forums


He's using the voltage, its really not reliable but better than nothing I guess


----------



## cubsfan187

"droidxchat said:


> He's using the voltage, its really reliable but better than nothing I guess


Its a start to keep diggin into it. Maybe there will be an answer in it somewhere.

Sent from my CM7 DROIDX using RootzWiki Forums


----------



## Nemo aeternamn

"droidxchat said:


> He's using the voltage, its really not reliable but better than nothing I guess


That's for sure... Battery monitor by simmo does that... And it will say forty or fifty percent as it's shutting down

But it's still nice to have

We have nothing to fear but running out of beer


----------



## cubsfan187

Well hopefully it will be WAY more accurate than battery monitor. That was so far off it was a joke. Battery meter reads 100% but the widget was at 63%?? That's not even close.


----------



## cpurick

My guess is that Moto went with 10% increments specifically because being accurate to 1% is so hard in the first place. I take my phone off power and it goes straight to 99% -- probably from voltage sag, but maybe because the battery's almost a year old. Calibration doesn't fix it. I doubt Motorola would appreciate me calling to complain there's something wrong with my phone b/c it won't stay at 100%. There's also the possibility that the voltage could go up as loads vary -- I'm pretty sure they never want to get a call from a customer about that.


----------



## cubsfan187

"cpurick said:


> My guess is that Moto went with 10% increments specifically because being accurate to 1% is so hard in the first place. I take my phone off power and it goes straight to 99% -- probably from voltage sag, but maybe because the battery's almost a year old. Calibration doesn't fix it. I doubt Motorola would appreciate me calling to complain there's something wrong with my phone b/c it won't stay at 100%. There's also the possibility that the voltage could go up as loads vary -- I'm pretty sure they never want to get a call from a customer about that.


They wouldn't care at all if we called for that...lol. If you watch the battery voltage when you unplug the charger, it drops right away. I don't think there's anything that can be done about that. Hopefully Chevy's fix is better.

Sent from my CM7 DROIDX using RootzWiki Forums


----------



## strikeir13

cpurick said:


> My guess is that Moto went with 10% increments specifically because being accurate to 1% is so hard in the first place. I take my phone off power and it goes straight to 99% -- probably from voltage sag, but maybe because the battery's almost a year old. Calibration doesn't fix it. I doubt Motorola would appreciate me calling to complain there's something wrong with my phone b/c it won't stay at 100%. There's also the possibility that the voltage could go up as loads vary -- I'm pretty sure they never want to get a call from a customer about that.


Doesn't the battery drop from 100% right away because from a technical standpoint, as soon as the phone is unplugged from the charger and it begins to use the battery, the battery is no longer fully charged; the phone has used some battery power already. Right? That's how I interpreted it.

Sent from my CM7 DROIDX.


----------



## cubsfan187

Yes that's true. It starts to drain as soon as the charger is removed. But it takes all of 2 sec to drop from 100 to 99. That initial drop is more of a voltage drop than anything else.

Has anyone seen Chevy's 'fix' yet?

Sent from my CM7 DROIDX using RootzWiki Forums


----------



## mav3rick478

have you tried this? Ever since I've done this method I've squeezed in a little more battery life and it does not drop to 90% instantly anymore. http://forum.xda-developers.com/showpost.php?p=11803458&postcount=10


----------



## cubsfan187

mav3rick478 said:


> have you tried this? Ever since I've done this method I've squeezed in a little more battery life and it does not drop to 90% instantly anymore. http://forum.xda-developers.com/showpost.php?p=11803458&postcount=10


Yes I have done that. But when your phone reports in 1%, as soon as you take the charger off, it drops within 30 seconds. Always did. Even after that trick. It's just the way the stats report. Now with an extended battery it's probably different but I'm not sure. Never seen anyone say anything about it.


----------



## DXC

hey guys, to elaborate on what i said before, since i got some PM's about it:

Chevy's fix reads voltage. I think once he sees how unreliable that is, he's going to abandon it. You can see the voltage yourself by (using a file explorer) going to /sys/devices/platform/cpcap_battery/power_supply/battery/voltage_now. Check it every few minutes and you'll see what I mean, it will even increase sometimes. Also, when you plug and unplug your charger, the voltage_now reading will jump all over the place. That's why no one really uses it.

In the same folder, theres a file called charge_counter. This is the one that usually output the exact battery level (in 1%). Unfortunately, ours reads about -1.3billion (theres a different of about a few hundred btw CM's reading and MIUI's reading, for unknown reasons). This is why we switched back to reading the file called "capacity" which shows the 10%-based voltage. Once we find a fix, we will switch back to reading the charge_counter file.

The question becomes, what writes the value to the charge_counter file. Well the answer is a network of files, mainly /system/bin/battd and /system/lib/libandroid_servers.so, which work together with the kernel itself. When the kernel changed to GB, it began reporting differently to that network of files. Since we cannot modify the kernel, we're forced to modify those files. This creates a few problems:

1) The content of these files cannot normally be access/modified without the source code, which we have no access to. I have software that can disassemble the files, and, despite how obfuscated it all is, I can see the changes that I need to make, but to this point, I haven't been able to successfully reassemble the files from that point. I'm still working on that.
2) We cannot simply swap these files out with the stock ones, because in some cases, such as with MIUI, they have been modified by the developers (the guys in China), to include things that are needed to make the ROM functional. They also rely on other custom system files, so swapping them out would require replacing other files as well, and those other files have dependencies of their own, so in the end to make it all work, you'd pretty much have to replace everything with stock files, and then, well, whats the point right?

So basically, replacing the files is out of the question... we have to modify them. I've contacted CVPCS, as he is the most familiar with this type of situation, but he told me once he saw the problem, he abandoned it with the hope that someone would figure out another way. We're on our own.... but I'm not giving up yet.


----------



## BMc08GT

"droidxchat said:


> hey guys, to elaborate on what i said before, since i got some PM's about it:
> 
> Chevy's fix reads voltage. I think once he sees how unreliable that is, he's going to abandon it. You can see the voltage yourself by (using a file explorer) going to /sys/devices/platform/cpcap_battery/power_supply/battery/voltage_now. Check it every few minutes and you'll see what I mean, it will even increase sometimes. Also, when you plug and unplug your charger, the voltage_now reading will jump all over the place. That's why no one really uses it.
> 
> In the same folder, theres a file called charge_counter. This is the one that usually output the exact battery level (in 1%). Unfortunately, ours reads about -1.3billion (theres a different of about a few hundred btw CM's reading and MIUI's reading, for unknown reasons). This is why we switched back to reading the file called "capacity" which shows the 10%-based voltage. Once we find a fix, we will switch back to reading the charge_counter file.
> 
> The question becomes, what writes the value to the charge_counter file. Well the answer is a network of files, mainly /system/bin/battd and /system/lib/libandroid_servers.so, which work together with the kernel itself. When the kernel changed to GB, it began reporting differently to that network of files. Since we cannot modify the kernel, we're forced to modify those files. This creates a few problems:
> 
> 1) The content of these files cannot normally be access/modified without the source code, which we have no access to. I have software that can disassemble the files, and, despite how obfuscated it all is, I can see the changes that I need to make, but to this point, I haven't been able to successfully reassemble the files from that point. I'm still working on that.
> 2) We cannot simply swap these files out with the stock ones, because in some cases, such as with MIUI, they have been modified by the developers (the guys in China), to include things that are needed to make the ROM functional. They also rely on other custom system files, so swapping them out would require replacing other files as well, and those other files have dependencies of their own, so in the end to make it all work, you'd pretty much have to replace everything with stock files, and then, well, whats the point right?
> 
> So basically, replacing the files is out of the question... we have to modify them. I've contacted CVPCS, as he is the most familiar with this type of situation, but he told me once he saw the problem, he abandoned it with the hope that someone would figure out another way. We're on our own.... but I'm not giving up yet.


Hey dxc I take it swapping the files from 1.9.9 is out of question to considering its froyo right?


----------



## cubsfan187

"BMc08GT said:


> Hey dxc I take it swapping the files from 1.9.9 is out of question to considering its froyo right?


That's a good question. Would that work? Judging by what you wrote it wont. But I wonder if there a way to "rewrite" them enough to work. Maybe (man I hope not) its a lost cause. But until o hear those words....I'll hold out hope.

Sent from my CM7 DROIDX using RootzWiki Forums


----------



## BMc08GT

"cubsfan187 said:


> That's a good question. Would that work? Judging by what you wrote it wont. But I wonder if there a way to "rewrite" them enough to work. Maybe (man I hope not) its a lost cause. But until o hear those words....I'll hold out hope.
> 
> Sent from my CM7 DROIDX using RootzWiki Forums


Ya that's what I was getting at.


----------



## DXC

the swapped files from froyo will put you back on the initial battery bug we had when GB miui was first released (the bug where it reads 100% at all times).

but good news, I'm working with RevNumbers who pointed out to me that source for CM7 libandroid_server is available. With the source it should be straightforward to get 1% on cm7 working, but getting it working on miui will be a bit tougher since cm7 android_servers is different from miui's and miui's source isnt available.


----------



## cubsfan187

"droidxchat said:


> the swapped files from froyo will put you back on the initial battery bug we had when GB miui was first released (the bug where it reads 100% at all times).
> 
> but good news, I'm working with RevNumbers who pointed out to me that source for CM7 libandroid_server is available. With the source it should be straightforward to get 1% on cm7 working, but getting it working on miui will be a bit tougher since cm7 android_servers is different from miui's and miui's source isnt available.


That's awesome news!! Can't wait to get this back for cm7. Again if any help is needed, please just ask.

Sent from my CM7 DROIDX using RootzWiki Forums


----------



## Nemo aeternamn

"droidxchat said:


> the swapped files from froyo will put you back on the initial battery bug we had when GB miui was first released (the bug where it reads 100% at all times).
> 
> but good news, I'm working with RevNumbers who pointed out to me that source for CM7 libandroid_server is available. With the source it should be straightforward to get 1% on cm7 working, but getting it working on miui will be a bit tougher since cm7 android_servers is different from miui's and miui's source isnt available.


Awesome news!! To bad miui had to wait add I know you are heavily involved with that...

We have nothing to fear but running out of beer


----------



## cubsfan187

Yeah I agree that it stinks that MIUI will be harder to get it in 1% but I love that CM7 'should' have it soon!


----------



## cubsfan187

Just a bump to make sure this doesn't get shoved back pages in the forum. Sorry for being selfish...lol.


----------



## cubsfan187

DXC...any progress updates?


----------



## bobAbooey

very interesting

http://twitpic.com/6vl6an


----------



## cubsfan187

Damn!! Ninja'd! I was just coming here to post that pic too. Hopefully Rev will grab up the source and implement in into cm.


----------



## bobAbooey




----------



## ImaComputa

Hopefully its accurate


----------



## cubsfan187

According to his tweet, he's had it running for a few days and it's stayed accurate. No release date set for his SSX 2.2 rom but he did say that Rev wanted his source for CM, he could use it.


----------



## cubsfan187

I can't wait to try SSX 2.2 when it's released. Even if just for this reason.


----------



## cubsfan187

Bump for DXC. Any progress?


----------



## Nemo aeternamn

"cubsfan187 said:


> Bump for DXC. Any progress?


Well... simmo has a great app for it... It's not released yet... But I'm testing it for him... And it seems to to be working extremely well

We have nothing to fear but running out of beer


----------



## cubsfan187

Really? That's awesome. I didn't know they were redoing their app.


----------



## Nemo aeternamn

Yup... Really... And it's out now... It's version 9... And it works so good...

We have nothing to fear but running out of beer


----------



## cubsfan187

Cool. I'll give it a shot and see how it holds up. Hopefully we will have them in the roms soon but until then, this will work.


----------



## NUNsLAUGHTER92

Nemo aeternamn said:


> Yup... Really... And it's out now... It's version 9... And it works so good...
> 
> We have nothing to fear but running out of beer


Where's the app? I've.never heard of simmo before..
Edit: never mind, went to Droid x forums and found it.

"Without man, there is no problem, no man no problem." -Stalin


----------



## razorloves

https://market.android.com/details?id=battery.monitor


----------



## Nemo aeternamn

cubsfan187 said:


> Cool. I'll give it a shot and see how it holds up. Hopefully we will have them in the roms soon but until then, this will work.


that's what i was thinking... this is awesome... but when we get the one percent in our roms... it will be amazing....


----------



## bobAbooey

They have 1% on the new liberty build


----------



## ejgilkey

"bobAbooey said:


> They have 1% on the new liberty build


I would guess this is right around the corner for the 2nd init roms. Don't see why you couldn't make it work on stock if he can get it working on Liberty.


----------



## DXC

1% works on stock -- the 1% readouts are naturally written to the file charge_counter, all that you need to do from there is set it up so the statusbar reads from that file. that's what liberty did.

on 2nd-init roms, we still have -1.3 billion in the charge_counter file. it won't change until we're about to change our /system/bin/battd (which should also turn off charging LED). but we can't change our /system/bin/battd until we figure out what is causing it to not recognize other battd, and it looks like its the 2nd-init process


----------



## JBirdVegas

droidxchat said:


> 1% works on stock -- the 1% readouts are naturally written to the file charge_counter, all that you need to do from there is set it up so the statusbar reads from that file. that's what liberty did.
> 
> on 2nd-init roms, we still have -1.3 billion in the charge_counter file. it won't change until we're about to change our /system/bin/battd (which should also turn off charging LED). but we can't change our /system/bin/battd until we figure out what is causing it to not recognize other battd, and it looks like its the 2nd-init process


Exactly what we found when we started looking into it for Liquid 3.0

We tried all sorts of stuff but from the moment logcat starts its printout we get -1.3b

...chevy uses voltage to form his 1% its not as good as charge_counter but still very nice; hats off really good work

I wish moto would give us the source 
It would take an hour to fix if we had the kernel source


----------



## bobAbooey

Thanks for the info guys.


----------



## DXC

"JBirdVegas said:


> Exactly what we found when we started looking into it for Liquid 3.0
> 
> We tried all sorts of stuff but from the moment logcat starts its printout we get -1.3b
> 
> ...chevy uses voltage to form his 1% its not as good as charge_counter but still very nice; hats off really good work
> 
> I wish moto would give us the source
> It would take an hour to fix if we had the kernel source


edittt


----------



## Brav1111

FYI, kejar said he got 1% working in his new liberty build.

I am still flashing so I can't confirm, but it is sounding like we are getting really close to 1% for gb, if we are not there already.

Not exactly sure what it means for 2nd init, but we will see i guess.


----------



## DXC

Brav1111 said:


> FYI, kejar said he got 1% working in his new liberty build.
> 
> I am still flashing so I can't confirm, but it is sounding like we are getting really close to 1% for gb, if we are not there already.
> 
> Not exactly sure what it means for 2nd init, but we will see i guess.


read above! it won't help 2nd-init unfortunately


----------



## DXC

i took the stock rom and added the 2nd-init process to it, booted it back up, it still has correct chargecounter readings. confirms that this issue is not directly related to 2nd-init. it's likely a library issue that all 2nd-init roms have inherited from cm7?


----------



## Brav1111

droidxchat said:


> read above! it won't help 2nd-init unfortunately


Sorry missed that, that's too bad.


----------



## cubsfan187

"droidxchat said:


> i took the stock rom and added the 2nd-init process to it, booted it back up, it still has correct chargecounter readings. confirms that this issue is not directly related to 2nd-init. it's likely a library issue that all 2nd-init roms have inherited from cm7?


Well that's a step in the right direction to solving the issue anyway. It seems to me that it is a cm7 file somewhere deep in the coding that's causing it. I'm starting to "attempt" to learn Java and coding on my own now. Hopefully it's still possible. Thanks for the update DXC!


----------



## DXC

just took the battd that we're stuck on and put it onto the stock rom. as the only change to the stock rom, it immediately set charge_full_design back down to 0 from 1500, and gave us the usual -1.3b in chargecounter. this suggests that the GB battd has a dependency on something else in the stock system that wasn't moved over to our roms (hopefully not blur lol).

ive also confirmed that this battd we're stuck on is causing the LED on while charging.


----------



## cubsfan187

"droidxchat said:


> just took the battd that we're stuck on and put it onto the stock rom. as the only change to the stock rom, it immediately set charge_full_design back down to 0 from 1500, and gave us the usual -1.3b in chargecounter. this suggests that the GB battd has a dependency on something else in the stock system that wasn't moved over to our roms (hopefully not blur lol).
> 
> ive also confirmed that this battd we're stuck on is causing the LED on while charging.


Awesome work DXC. Sounds like you're getting narrowed it down even more. Progress bro, progress.


----------



## Brav1111

So now that Chevy has 1% working in SSX which is based off of CM&, how long before it gets moved over to the CM7 build?


----------



## bikedude880

\"Brav1111\" said:


> So now that Chevy has 1% working in SSX which is based off of CM&, how long before it gets moved over to the CM7 build?


D2G team has been working on 1% on and off since we got our GB leak and thusfar have had mild success. Depending on the battd/libbattd combination, you can either get charge_counter reporting right and no charge_design (e.g. charging, discharging) but not both (yet). Hashcode wrote a custom bit of code in the framework (?) that calculates 1% off voltage and a bit of algorithm.


----------



## DXC

bikerdude can u point me to the battd combo that doesn\'t give charge design but gives counter


----------



## bikedude880

\\\\\\\"droidxchat\\\\\\\" said:


> bikerdude can u point me to the battd combo that doesn\\\\\\\\\\\\\\\'t give charge design but gives counter


It was either defy or droid2...

This repo holds common proprietary files
https://github.com/cvpcs/android_device_motorola_common


----------



## Brav1111

Do we need to reinvent something that is already figured out in SSX? I think he built it off of the CM7 base, unless I have no clue what I am talking about, which could be very possible.


----------



## Nemo aeternamn

Brav1111 said:


> Do we need to reinvent something that is already figured out in SSX? I think he built it off of the CM7 base, unless I have no clue what I am talking about, which could be very possible.


This isn't reinventing... As ssx goes off of the voltage.. Buy in a different way so it's pretty accurate... They're trying to figure out why the charge_counter file in /sys/devices/platform/cpcap_battery/power_supply/battery/ 
Aka the factory file isn't reporting properly... Ssx has a work around

We have nothing to fear but running out of beer


----------



## runnirr

I'm not sure if this is relevant to anything but running liberty in boot manager has the 1% and charge counters. CM7 is my phone rom. I don't know what BootManager does exactly so this could be completely useless information.


----------



## Nemo aeternamn

runnirr said:


> I'm not sure if this is relevant to anything but running liberty in boot manager has the 1% and charge counters. CM7 is my phone rom. I don't know what BootManager does exactly so this could be completely useless information.


It doesn't help... Because when you use boot manager it it boots up with all blur so it's as if you ate running that rom.. Your also able to charge while off when running a blur rom the rom manager

We have nothing to fear but running out of beer


----------



## TeutonJon78

JBirdVegas said:


> I wish moto would give us the source
> 
> 
> 
> 
> 
> 
> 
> 
> It would take an hour to fix if we had the kernel source


Fancy that, I just emailed the Moto devs to reupload the kernel source for the recently preleased 605 kernel dump (the original kernel code dump was corrupt). https://sourceforge.net/projects/droidx.motorola/files/DroidX%20Source%20GB/VRZ_MB810_4.5.605/

It just just re-uploaded a few hours ago. I did a little look through the code, but as I don't know the kernel code at all, didn't really find anything.


----------

