Guest burstlam Posted March 10, 2011 Report Share Posted March 10, 2011 proximity works fine with dalvik cache cleaned. power consumed in idle status performs similiar to previous fix. for me I do think it is a 2.3.3 issue of high power consumption Link to comment Share on other sites More sharing options...
Guest Rotmann Posted March 10, 2011 Report Share Posted March 10, 2011 (edited) Just made a call and its back :( a quick cover of the sensor brought the screen back though. Seems better than before but still a bit random. Screen now staying black every time, covering sensor brings it back on. It worked perfectly on 5 test calls immediately after flashing new kernal. The phone was then left about 1 hour then problem returned. No changes to settings were made in this time. Did you tick "Always use proximity" in Settings-Call settings? A restart is good too. Edited March 10, 2011 by Rotmann Link to comment Share on other sites More sharing options...
Guest t0mm13b Posted March 10, 2011 Report Share Posted March 10, 2011 what about wlan.ko? Just to heads up everyone.... I am in absolute 100% agreement with Tom_G, that this CONFIG_ZTE_SUSPEND_WAKEUP_MONITOR within the kernel/power/wakelock.c is spewing out a load of crap into the log, which could explain some who have reported that the home screen was laggy ... There are a few places in the kernel config that is spewing out event logging etc... which can be switched off and hence fine tuning and tweaking this to remove unnnecessary extra modules and minimize distribution of updater.zip... So keep tuned! :( Link to comment Share on other sites More sharing options...
Guest gingerninja Posted March 10, 2011 Report Share Posted March 10, 2011 Did you tick "Always use proximity" in Settings-Call settings? A restart is good too. Yes its ticked just tried a reboot and its working again. Problem reoccured after phone had been sleeping for about 1 hour. Link to comment Share on other sites More sharing options...
Guest jt_mcg Posted March 10, 2011 Report Share Posted March 10, 2011 (edited) Hi Great work t0mm13b!, In addition to css's find of "rotuer" in the kernel I found it again in rpcrouter_sdio_xprt.c. I really don't have any complaints about sleeping battery drain anymore. Last night, I put the phone to sleep using the power button with end-button behavior set to put to sleep, I have auto rotation off, wifi and data connections off. It was 32% remaining and when the alarm went off 8hrs later it was still 32% remaining. Keep up the good work! Edit: on a home build just before RC2, it shows "RC2" in about phone and a kernel I built/compiled/whatever with the various fixes previous to your newest finds. Edited March 10, 2011 by jt_mcg Link to comment Share on other sites More sharing options...
Guest hecatae Posted March 10, 2011 Report Share Posted March 10, 2011 Just to heads up everyone.... I am in absolute 100% agreement with Tom_G, that this CONFIG_ZTE_SUSPEND_WAKEUP_MONITOR within the kernel/power/wakelock.c is spewing out a load of crap into the log, which could explain some who have reported that the home screen was laggy ... There are a few places in the kernel config that is spewing out event logging etc... which can be switched off and hence fine tuning and tweaking this to remove unnnecessary extra modules and minimize distribution of updater.zip... So keep tuned! :( is it a lot of work? soon as these things are sorted we can look at kernel updating Link to comment Share on other sites More sharing options...
Guest Frankish Posted March 10, 2011 Report Share Posted March 10, 2011 Hi Great work t0mm13b!, In addition to css's find of "rotuer" in the kernel I found it again in rpcrouter_sdio_xprt.c. I really don't have any complaints about sleeping battery drain anymore. Last night, I put the phone to sleep using the power button with end-button behavior set to put to sleep, I have auto rotation off, wifi and data connections off. It was 32% remaining and when the alarm went off 8hrs later it was still 32% remaining. Keep up the good work! Realistic battery measurements are always in the lower portion like this! I hate people posting/complaining that their battery stayed at 100% for 2 hours then dropped to 88% in 5 minutes of usage. Between 0 and 89% makes most sense. What kernel was that jt? This one? Link to comment Share on other sites More sharing options...
Guest jt_mcg Posted March 10, 2011 Report Share Posted March 10, 2011 Realistic battery measurements are always in the lower portion like this! I hate people posting/complaining that their battery stayed at 100% for 2 hours then dropped to 88% in 5 minutes of usage. Between 0 and 89% makes most sense. What kernel was that jt? This one? I edited my post to say it's a home build with the fixes to the .config t0mm13b found previously and css's rpc rotuer fix(es). I completely agree with where you're looking to measure the drops because if I understand correctly it can report charged/100% when it's actually dropping to around 90% while on the charged to prevent overcharging. No luck with the radio yet either mate! You getting any sleep! Link to comment Share on other sites More sharing options...
Guest Smiff2 Posted March 10, 2011 Report Share Posted March 10, 2011 it's amazing this s**t works at all with typos like that from ZTE all over the place. Link to comment Share on other sites More sharing options...
Guest Frankish Posted March 10, 2011 Report Share Posted March 10, 2011 I edited my post to say it's a home build with the fixes to the .config t0mm13b found previously and css's rpc rotuer fix(es). I completely agree with where you're looking to measure the drops because if I understand correctly it can report charged/100% when it's actually dropping to around 90% while on the charged to prevent overcharging. No luck with the radio yet either mate! You getting any sleep! The Desire was the same, it used to charge to 100 then stop...drop to 90 then charge again. But didn't display it. You literally could take the phone off charge and it would go from 100% to 89% in 10 seconds flat :( Too bad on the radio but maybe someone will figure it eventually :) Getting plenty of sleep still. She's a little angel. I'm sure it will all change eventually though :( Link to comment Share on other sites More sharing options...
Guest jt_mcg Posted March 10, 2011 Report Share Posted March 10, 2011 The Desire was the same, it used to charge to 100 then stop...drop to 90 then charge again. But didn't display it. You literally could take the phone off charge and it would go from 100% to 89% in 10 seconds flat :( Too bad on the radio but maybe someone will figure it eventually :) Getting plenty of sleep still. She's a little angel. I'm sure it will all change eventually though :( What's strange about the radio, is that a lot of other devices have included libs like fmradioservice.lib and ours doesn't that I can find. I'm looking at andorko's kernel changes and the ones by kk that you pointed me to, but every radio app fcs: zte's, andorko's, and cm's. I found an interesting post about how some guys got a radio working on a motorola that didn't have one, but I'm too much of a noob to come up with something! She sounds like an angel btw! Link to comment Share on other sites More sharing options...
Guest gat2011 Posted March 10, 2011 Report Share Posted March 10, 2011 yipeee! flashed rc2 again last night, hoping prox sensor would work for me. it didn't. just flashed again with fix and ticked always use proximity. have rung the boring bint that gives all my contract info several times, longest one 3.5 mins and it worked each time!!! being picky, is a little slower than flb 2.2, which comes back on instantly. i have a small delay with rc2. but it works! thx guys. i love this rom and this was the one thing making me go back to 2.2. Link to comment Share on other sites More sharing options...
Guest fonix232 Posted March 10, 2011 Report Share Posted March 10, 2011 what effect would switching from a 2G/2G VMSPLIT to a 3G/1G VMSPLIT have on battery life? CM7 already uses a 3G VMSplit kernel, that's why we can only see less than 200MB of the 416MB free RAM... BTW, good work, t0mm13b, I can't wait to see your repo of the kernel :( Can you add that router fix too? Link to comment Share on other sites More sharing options...
Guest naxuu Posted March 10, 2011 Report Share Posted March 10, 2011 i tested this too, and it doesen't work for me :( screen stays off like before. did wipe cache and dalvik.cache. Then reinstal nightly 15 and fixed kernel. Now it works (also ticked always use proximity settings) Link to comment Share on other sites More sharing options...
Guest Scoopading Posted March 10, 2011 Report Share Posted March 10, 2011 (edited) Realistic battery measurements are always in the lower portion like this! I hate people posting/complaining that their battery stayed at 100% for 2 hours then dropped to 88% in 5 minutes of usage. Well, this past week, I've more-or-less had the Blade constantly on standby testing CM7! So I learned more about this stuff than I'd care to or ever want to again!! :( It's true that, without care, people can look at a 100% reading and think it means 100% when it's not. In fact a 100% reading never appears to be accurate when taken with the phone on. Whilst Android will deactivate the charge at 100%, even if you switch the phone off straight away (as soon as it reaches 100%, so that it hasn't had a chance to drain anything) you should find it will actually charge (often for quite a while) with the phone off before the status light turns green. So "100%" on Android doesn't EVER, at any stage, appear to mean 100% as far as the phones own hardware/status light is concerned. Even when the phone is charged for an additional period this way, it's pretty typical that Android will still only report 99% by the time it reaches the launcher after you switch it back on. However, if you start using it straight away, it will consistently show 100 or 99% battery for the first approx 3 hours on standby, suggesting that there is indeed some additional charge present. This difference might well mean you get a slightly "better" (longer lasting) charge with the Blade switched off than with it on, though I've not personally done any testing to confirm this. But it does confirm that you need to have the Blade off-charge and on standby for at least 3 hours before you can even BEGIN to start counting drain in a valid fashion. After this period, from about 98% down to below 50%, the behaviour is extremely consistent under CM7. There appears to be a constant drain of approx 1.75-2% per hour in standby. That's averaged out after many hours and not typical of other roms I'm aware of. If you don't average it out over many hours you're also subject to Androids own inconsistent battery percentage status reporting. By that I mean that (at least on CM7) it seems its rather fond of dropping the battery percentage status in 3% increments - at least until about 35-40%. I haven't done much testing beyond that due to the time it takes! (More than a day). But I do know that CM7 didn't manage 48 hours on standby for me personally, which is not the case with other roms presently. So, just as there should be caution about measuring from a 100% charge, there also needs to be some understanding about the inconsistent nature of Androids battery status reporting. You might well check a phone and have it report the same percentage after some hours of standby. However it's extremely common that, only minutes later, it will report a battery status several percentage points lower. You really have to test over an extended period of time to get a better idea. So it's just to say, multiple times, my own testing has found that the battery drain behaviour is pretty consistent between 98% and about 40% or thereabouts. It might change after that point but it would take a day on standby to reach that point and personally I'm done with testing Blade battery issues for now :) EDIT - Oh and just to be clear, these comments don't apply to the kernel posted here - Which I haven't personally tested :( Edited March 10, 2011 by Scoopading Link to comment Share on other sites More sharing options...
Guest Grain Posted March 10, 2011 Report Share Posted March 10, 2011 (edited) Re first post and via IRC, seems CONFIG_SCREEN_ON_WITHOUT_KEYOCDE makes a difference indeed concerning the proximity issue; it was removed by accident here. Tom_G is aware of that. The typo is irrelevant BTW. Removal of the CONFIG_ZTE_SUSPEND_WAKEUP_MONITOR code should be okay. Edited March 10, 2011 by Grain Link to comment Share on other sites More sharing options...
Guest samjam Posted March 10, 2011 Report Share Posted March 10, 2011 CM7 already uses a 3G VMSplit kernel, that's why we can only see less than 200MB of the 416MB free RAM... What? Is that 3rd-Generation or 3 gigabytes? ...I don't want to loose so much RAM Link to comment Share on other sites More sharing options...
Guest hc_1540 Posted March 10, 2011 Report Share Posted March 10, 2011 Colour me impressed!!! Needed a reboot after ticking 'Always Use proximity' but since then the proximity sensor seems to be behaving. 6 calls so far, longest one being 4 minutes but looking good. Time to rumage around and properly appreciate all that lovely RC2 goodness. Tom, you are a star!!! :( :( Link to comment Share on other sites More sharing options...
Guest anneliese Posted March 10, 2011 Report Share Posted March 10, 2011 Tom, you are a star!!! :( :( Yes Tom is a star. RC2 and proximity working. Great! Link to comment Share on other sites More sharing options...
Guest JK-FINN Posted March 10, 2011 Report Share Posted March 10, 2011 Would it be possible to add andorko's RDS FM radio to modded CM7? Like kallt_kaffe did with Japanese Jellyfish RLS9. http://android.modaco.com/content/zte-blad...01-24-oled-tft/ http://android.modaco.com/content/zte-blad...r-zte-blade-sf/ Link to comment Share on other sites More sharing options...
Guest DonJamal Posted March 10, 2011 Report Share Posted March 10, 2011 (edited) oooops...at about 2hours sleeping mod got a call and the proximity doesnt work :( tried after a call.. maybe it was caused by the 2hours sleep mod but not...doesnt work restart works again :/ wtf? is this becuz didnt do wipe just flash? Edited March 10, 2011 by DonJamal Link to comment Share on other sites More sharing options...
Guest t0mm13b Posted March 10, 2011 Report Share Posted March 10, 2011 Ok, Heads up, this is a refresh, all debugging/unnecessary logging is stripped out of it... (heh! all your logging base belongs to us :)) so I would be inclined to think it should speed it up slightly... :( Once we get satisfaction from users on their experience with this update then we'll use this as the base configuration to fix up other issues, and perhaps integrate andorko's FM radio ..... :( Now, a simple matter of flashing via clockwork and all should be good to go... ;) Cheers. ;)t0mm13b_update2_signed.zip Link to comment Share on other sites More sharing options...
Guest ootyposoo Posted March 10, 2011 Report Share Posted March 10, 2011 (edited) How do I use the custom Kernel? Edited March 10, 2011 by ootyposoo Link to comment Share on other sites More sharing options...
Guest k0nrad Posted March 10, 2011 Report Share Posted March 10, 2011 (edited) I've just made quite a long call (+10 min) after phone was left aside for few hours. Had no problems with in-call waking up to suspend the call at some point. When the call ended (by other side) it woke up on lockscreen after a few seconds (I have "always back to call log" unticked). I hadn't restarted the phone between flashing the fixed kernel (wbaw's upload) and the call. So, it works great for me so far! EDIT: To make things straight - are these changes (incl. planned integration of FM radio) going to be included in official CM for Blade, or every CM Kernel update is going to require custom fixing? I'm just not overly familiar with the way CM deals with individual devices and not sure if the fixes were made in 'mainstream' part of kernel, or Blade-specific portions, that's why I'm asking :( Edited March 10, 2011 by k0nrad Link to comment Share on other sites More sharing options...
Guest gingerninja Posted March 10, 2011 Report Share Posted March 10, 2011 (edited) Ok, Heads up, this is a refresh, all debugging/unnecessary logging is stripped out of it... (heh! all your logging base belongs to us :)) so I would be inclined to think it should speed it up slightly... :( Once we get satisfaction from users on their experience with this update then we'll use this as the base configuration to fix up other issues, and perhaps integrate andorko's FM radio ..... :( Now, a simple matter of flashing via clockwork and all should be good to go... ;) Cheers. ;) Does this fix the problem with blank screen reoccuring after sleep. Sleep time of 1 hour repeated the problem for me. Thanks again Edited March 10, 2011 by gingerninja Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now