FORUMS
Remove All Ads from XDA

[MOD][FEB 10] MultiROM v33

818 posts
Thanks Meter: 6,156
 
Post Reply Email Thread
8th March 2014, 12:54 PM |#461  
deedeeceleb's Avatar
Senior Member
Thanks Meter: 224
 
More
Also a huge battery drain here with primary rom. Tested velocity, pa and purity..)

Gesendet von meinem Nexus 7 mit Tapatalk
 
 
8th March 2014, 01:01 PM |#462  
Member
Flag near Brussels
Thanks Meter: 11
 
More
Hi, I also have a battery drain with CM. I taught for a long time that it was rom related. Since latests nightlies it seems that the drain has diminished

Sent from my Nexus 4 using XDA Premium 4 mobile app
8th March 2014, 06:45 PM |#463  
Junior Member
Thanks Meter: 0
 
More
I have the battery drain issue as well. I never really thought about multirom as a potential cause until you mentioned it. I have to change once a day.

Sent from my Nexus 7 using Tapatalk
9th March 2014, 12:32 AM |#464  
Quote:
Originally Posted by Tasssadar

I've got somewhat serious question: did anybody notice significant decrease in battery life while booted in the primary ROM after installing MultiROM? Because I and at least one other person did. The device goes into deep sleep just fine, nothing suspicious in tools like BetterBatteryStatus, but it simply drains at least five times as much as usual - over 1% per hour, whilst the normal usage is somewhere around 0.2% per hour.

This happens only on the primary ROM. Did any of you notice something like that? This bug might be present only on certain revisions of Nexus 7, me and the other person with this problem both have 16GB flo, HW revision E (you can see that info in bootloader).

I already have workaround and explanation of what causes it ready, but now I just want to know how widespread is this issue. It took this long to track down because...MultiROM doesn't do anything which should affect battery life, so I blamed it on the ROM. Turns out that was incorrect.

More info comming once I get some infromation from you Thank you.

Same here. Revision e, PAC-rom (uses cm kernel), ~1% loss per hour.
EDIT: Just installed newest update. Thanks for the hard work, man!

Sent from my Nexus 7 using Tapatalk
9th March 2014, 12:52 AM |#465  
Tasssadar's Avatar
OP Inactive Recognized Developer
Flag Brno
Thanks Meter: 6,156
 
Donate to Me
More
MultiROM v22b was released and it fixes excessive battery drain. There is a brief period when screen is completely turned off between MultiROM GUI and ROM's boot animation. The screen drawing code was replaced, if it causes problems on your kernel, you can force using the old one (which causes the battery draining) in recovery -> Advanced -> MultiROM -> Settings, Force using generic screen drawing code.

Now, a more detailed info about what happened: there is a hack in flo's video drivers which turns on display backlight when the device is in recovery. It is triggered by manipulating the framebuffer device, which, on normal device, is done only by recovery, Android uses different methods to draw on screen (which require proprietary libraries). This hack turns something on, and it drains the device's battery, even while in deep sleep. Normaly, you wouldn't encounter that because you're not staying in recovery for long enough.
The problem is that MultiROM uses the same screen drawing method as recovery, but there is no device reset between MultiROM's GUI and Android. That means it triggers the hack and the increased battery consumption in Android is the result. It wasn't happening on secondary ROMs because with kexec-hardboot, there is a device restart after you choose the secondary ROM (to load another kernel) and everything gets reset into its initial state.
The workaround which fixes it is to use different method to draw onto screen - it is called "Qualcomm overlay" and thankfuly, it doesn't trigger that hack in kernel. Other than that, it is comparable to the old method, if somewhat faster. We are very, very lucky this method exist and that I know about it - big thanks to Dees_Troy of TWRP for that. If it did not, the only way to fix it would be find what exactly causes the drain, fix the kernel drivers and then get the fix into all kernels.
Some of you are reporting that this wasn't an issue for you - can't tell you why. Maybe there are kernels where this is fixed, maybe you just didn't notice it. For me, it was happening on every bootloader version, every kernel and every ROM I tried.

It was present in MultiROM since release, over half a year now. I'm somewhat surprised nobody reported it for so long, but I don't blame you - I thought it was the ROM myself, I even switched my main ROM for some other, because MultiROM doesn't do anything which should affect something like power consumption. That hack in kernel is just evil, and you have no idea how long it took me to figure out what the hell was happening.

Anyway, it is "fixed" now. Something like this shouldn't even happen, but it did. Sorry for that.

Oh, and the recovery was updated to TWRP 2.7.
The Following 29 Users Say Thank You to Tasssadar For This Useful Post: [ View ] Gift Tasssadar Ad-Free
9th March 2014, 12:59 AM |#466  
mdamaged's Avatar
Senior Member
Flag South of Heaven
Thanks Meter: 1,452
 
More
Quote:
Originally Posted by Tasssadar

MultiROM v22b was released and it fixes excessive battery drain. There is a brief period when screen is completely turned off between MultiROM GUI and ROM's boot animation. The screen drawing code was replaced, if it causes problems on your kernel, you can force using the old one (which causes the battery draining) in recovery -> Advanced -> MultiROM -> Settings, Force using generic screen drawing code.

Now, a more deailed info about what happened: there is a hack in flo's video drivers which turns on display backlight when the device is in recovery. It is triggered by manupulating the framebuffer device, which, on normal device, is done only by recovery, Android uses different methods to draw on screen (which require proprietary libraries). This hack turns something on, and it drains the device's battery, even while in deep sleep. Normaly, you wouldn't encounter that because you're not staying in recovery for long enough.
The problem is that MultiROM uses the same screen drawing method as recovery, but there is no device reset between MultiROM's GUI and Android. That means it triggers the hack and the increased battery consumption in Android is the result. It wasn't happening on secondary ROMs because with kexec-hardboot, there is a device restart after you choose the secondary ROM (to load another kernel) and everything gets reset into its initial state.
The workaround which fixes it is to use different method to draw onto screen - it is called "Qualcomm overlay" and thankfuly, it doesn't trigger that hack in kernel. Other than that, it is comparable to the old method, if somewhat faster. We are very, very lucky this method exist and that I know about it - big thanks to Dees_Troy of TWRP for that. If it did not, the only way to fix it would be find what exactly causes the drain, fix the kernel drivers and then get the fix into all kernels.
Some of you are reporting that this wasn't an issue for you - can't tell you why. Maybe there are kernels where this is fixed, maybe you just didn't notice it. For me, it was happening on every bootloader version, every kernel and every ROM I tried.

It was present in MultiROM since release, over half a year now. I'm somewhat surprised nobody reported for so long, but I don't blame you - I thought it was the ROM myself, I even switched my main ROM for some else, because MultiROM doesn't do anything which should affect something like power consumption. That hack in kernel is just evil, and you have no idea how long it took me to figure out what the hell was happening.

Anyway, it is "fixed" now. Something like this shouldn't even happen, but it did. Sorry for that.

Oh, and the recovery was updated to TWRP 2.7.



Thanks, again sorry that me reporting this issue caused you more work, but I'm glad you got it working!
9th March 2014, 03:26 AM |#467  
Senior Member
Flag The Land of Coffee
Thanks Meter: 237
 
More
Quote:
Originally Posted by Tasssadar

MultiROM v22b was released and it fixes excessive battery drain. There is a brief period when screen is completely turned off between MultiROM GUI and ROM's boot animation. The screen drawing code was replaced, if it causes problems on your kernel, you can force using the old one (which causes the battery draining) in recovery -> Advanced -> MultiROM -> Settings, Force using generic screen drawing code.

Now, a more detailed info about what happened: there is a hack in flo's video drivers which turns on display backlight when the device is in recovery. It is triggered by manupulating the framebuffer device, which, on normal device, is done only by recovery, Android uses different methods to draw on screen (which require proprietary libraries). This hack turns something on, and it drains the device's battery, even while in deep sleep. Normaly, you wouldn't encounter that because you're not staying in recovery for long enough.
The problem is that MultiROM uses the same screen drawing method as recovery, but there is no device reset between MultiROM's GUI and Android. That means it triggers the hack and the increased battery consumption in Android is the result. It wasn't happening on secondary ROMs because with kexec-hardboot, there is a device restart after you choose the secondary ROM (to load another kernel) and everything gets reset into its initial state.
The workaround which fixes it is to use different method to draw onto screen - it is called "Qualcomm overlay" and thankfuly, it doesn't trigger that hack in kernel. Other than that, it is comparable to the old method, if somewhat faster. We are very, very lucky this method exist and that I know about it - big thanks to Dees_Troy of TWRP for that. If it did not, the only way to fix it would be find what exactly causes the drain, fix the kernel drivers and then get the fix into all kernels.
Some of you are reporting that this wasn't an issue for you - can't tell you why. Maybe there are kernels where this is fixed, maybe you just didn't notice it. For me, it was happening on every bootloader version, every kernel and every ROM I tried.

It was present in MultiROM since release, over half a year now. I'm somewhat surprised nobody reported it for so long, but I don't blame you - I thought it was the ROM myself, I even switched my main ROM for some other, because MultiROM doesn't do anything which should affect something like power consumption. That hack in kernel is just evil, and you have no idea how long it took me to figure out what the hell was happening.

Anyway, it is "fixed" now. Something like this shouldn't even happen, but it did. Sorry for that.

Oh, and the recovery was updated to TWRP 2.7.

I got this issue for months, N7 32G, and even on my N5 once. I had to restore original image of N5 to make it normal again. I thought I was the only one who had this, so I guessed there was some kind of conflict with my existing apps. One more thing, the drainage happens even on secondary roms with shared kernel.
Anyway I'm downloading the updates, hope that will solve all the issues.
Thanks @Tasssadar

Sent from my Nexus 7 using Tapatalk
9th March 2014, 04:02 AM |#468  
aamitabh28's Avatar
Senior Member
Thanks Meter: 410
 
More
Wow i cant beleive this! I was so affected by this issue.. My idle drain was hhuuuge and all i could do was restore factory image again and again. I had no idea because my device wasnt wakelocking or anything. Great news.. Thanks a lot tassadar!

Sent from my Nexus 5 using Tapatalk
9th March 2014, 04:23 AM |#469  
rraaka's Avatar
Senior Member
Thanks Meter: 681
 
More
too early to confirm but the devs word is enough - im thankful i can stay booted into the primary for longer periods of time.

and xda shouldnt give any dev scope to apologise .....this is development
The Following 3 Users Say Thank You to rraaka For This Useful Post: [ View ] Gift rraaka Ad-Free
9th March 2014, 01:48 PM |#470  
z31s1g's Avatar
Recognized Themer
Flag Munich
Thanks Meter: 12,404
 
Donate to Me
More
Info 2 TWRP Holofied theme for MultiROM updated
MultiROM theme updated with ui changes from new dark theme:

09.03.2014
  • Highlight color for button presses made darker
  • Added vibration settings page (time zone setting moved to actionbar)
  • Added capslock support to keyboard
  • Increased spacing for partition lists on "wipe page" and "mount page"
  • Changed color of console to match overall background color
  • Added option to center clock in statusbar
  • Progress bar position now below action bar
  • Font size of tab labels reduced
  • Font color of main buttons, action bar labels and tab labels changed from white to a light grey

Grab it here.
The Following User Says Thank You to z31s1g For This Useful Post: [ View ] Gift z31s1g Ad-Free
9th March 2014, 02:30 PM |#471  
SynnyG's Avatar
Senior Member
Flag Strasbourg
Thanks Meter: 656
 
Donate to Me
More
Quote:
Originally Posted by Tasssadar

MultiROM v22b was released and it fixes excessive battery drain. There is a brief period when screen is completely turned off between MultiROM GUI and ROM's boot animation. The screen drawing code was replaced, if it causes problems on your kernel, you can force using the old one (which causes the battery draining) in recovery -> Advanced -> MultiROM -> Settings, Force using generic screen drawing code.

Now, a more detailed info about what happened: there is a hack in flo's video drivers which turns on display backlight when the device is in recovery. It is triggered by manipulating the framebuffer device, which, on normal device, is done only by recovery, Android uses different methods to draw on screen (which require proprietary libraries). This hack turns something on, and it drains the device's battery, even while in deep sleep. Normaly, you wouldn't encounter that because you're not staying in recovery for long enough.
The problem is that MultiROM uses the same screen drawing method as recovery, but there is no device reset between MultiROM's GUI and Android. That means it triggers the hack and the increased battery consumption in Android is the result. It wasn't happening on secondary ROMs because with kexec-hardboot, there is a device restart after you choose the secondary ROM (to load another kernel) and everything gets reset into its initial state.
The workaround which fixes it is to use different method to draw onto screen - it is called "Qualcomm overlay" and thankfuly, it doesn't trigger that hack in kernel. Other than that, it is comparable to the old method, if somewhat faster. We are very, very lucky this method exist and that I know about it - big thanks to Dees_Troy of TWRP for that. If it did not, the only way to fix it would be find what exactly causes the drain, fix the kernel drivers and then get the fix into all kernels.
Some of you are reporting that this wasn't an issue for you - can't tell you why. Maybe there are kernels where this is fixed, maybe you just didn't notice it. For me, it was happening on every bootloader version, every kernel and every ROM I tried.

It was present in MultiROM since release, over half a year now. I'm somewhat surprised nobody reported it for so long, but I don't blame you - I thought it was the ROM myself, I even switched my main ROM for some other, because MultiROM doesn't do anything which should affect something like power consumption. That hack in kernel is just evil, and you have no idea how long it took me to figure out what the hell was happening.

Anyway, it is "fixed" now. Something like this shouldn't even happen, but it did. Sorry for that.

Oh, and the recovery was updated to TWRP 2.7.

Don't be sorry, you do awesome work and thanks to you, our devices are better and better ! We learn by doing error, but even with some error, MultiROM is perfect.
Again don't be sorry but happy for the discover you've done and the great improvement you've made !

Sent from my LG-D802 using xda app-developers app
Post Reply Subscribe to Thread

Tags
dual boot, multiboot, multirom

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes