[Defy Android Development] gkai:
Hi Eps3,

after a lot of tests and using CPU Spy/ Power tutor, I think I start to get the correct picture about power usage on latest kernel (wifitest3):

-when screen is on: main power draw is the screen backlight...And there is probably a problem with automatic backlight: When using fixed backlight in settings, one can go from about 900 mW (max brightness), about 650 mW (mid brightness) to 350 mW (min brightness). When auto brightness is active, it works (the screen brightness is adjusted with ambient light), but do not change LCD power draw at all,power draw remain at the last fixed brightness used. It is like auto brightness work by changing colors, not reducing backlight. Maybe because fixed is part of normal settings and auto, with all it's specific CM7 tuning, is part of CM7? Anyway, this is the major problem for power use when using the phone (screen on), especially in the night, as min fixed brightness is still too bright so reducing backlight further would save battery life. I am not sure power tutor is reliable...but those findinds are coherent with []Al[] gaming test and the battery use report from CM7, which always show screen as main power usage as soon as phone is not let off all the time. 350 mW also seems quite high for minimal brightness imho, but I am not sure: maybe someone running stock froyo could try power tutor and report LCD power usage, to get a comparison...

-when screen is off: latest kernel (wifitest3) is not able to go into deepsleep because of the warning. I agree the error -16 is a warning, and kernel plan to go into deepsleep after some task cleanup...but it never achieve this cleanup, there is one process that refuse to go into deepsleep (log shows this sequence with error -16 continuously, kernel nerver achieve deepsleep even if it constantly try). This is coherent with CPU Spy report (deepsleep state 0% of the time, CPU instead stay at min freq). I am very confident on CPU spy on this, because there is a simple way to let wifitest3 go into deepsleep: set the phone into airplane mode. As soon as it is in airplane mode, screen off will trigger deepsleep (smartass governor, default settings except reduced Vsels) and CPU Spy will report a lot of time spent in deep sleep state.

It thus seems that deepsleep failure is radio related (not cam related, the cam message appear also in airplane mode...but do not prevent deepsleep). In my case, airplane mode de-activated only 2G (no 3G, no data, no wifi nor bluetooth, only 2G and deepsleep is prevented). There was a lot of work around radios (for solving wifi issues), so I wonder if the deepsleep issue did not crept due to those changes.

Hope that those observations helps improve Battery life of CM7: it is so stable and feature complete imho that it explains why people are now mainly concerned with power draws ;-)

Another point: I think u are the french translator for CM7 defy? In french, the menu about power widget settings (widget at the top of the pull down notification menu, the one that appear when you pull down notification bar) is not present, while it is in English. It means that currently, to change thse settings, you have to go to english, change widgets/widgets order, and go back to french.

Sorry for this long rant, but I hope it has been useful for you devs,

Greg.

Edit: I had a look about power tutor measurement procedure, and I think it can not be considered reliable: it works by measuring LCD backlight status, and then, using a database for devices, get an a priori power draw for this particular backlight. The actual power draw of the LCD is never directly measured....probably because such a measure is not possible. There is 2 problem with this:

1) Defy is not in their database, so it uses the value from another phone. I think they use the N1.

2) I probably read the backlight as defined by normal settings, not CM7 settings and not actual value set by auto backlight algorithm. This explain the strange feature of always reporting the same value depending on the last fixed backlight, not changing with ambiant light when auto backlight is choosen. So the only "reliable test" would be to force the screen on, and measure power draw/5h under 2 backlight settings (2 ambeint light levels for auto). Not an easy test to do.

I somehow suspect that the high screen usage reported by battery use suffer from the same drawback: without a direct screen power measure, it relies on estimates...and if the estimator do not have access to the backlight level set by the auto backlight feature, it can not be correct...