Originally Posted by dung8604
no, this was with my anker. I'm much more concerned about standby time. It is my full belief that if you're using the phone, there is only so much that can be done to help battery drain. Right now isn't such a good test of standby time, as I use my phone at work quite a bit.
Regarding tbalden's edits, I would love to use these features. I hardly ever have the auto backlight on anyways, and I would rather have the keyboard always on than rely on the type of lighting it is in. Just seems more convenient and logical to me that way. Additionally, the drain from the keyboard always being on is nothing compared to the drain required to use the front sensor.
Also, from my experience with tbalden's roms, nothing else is affected by deactivating the auto backlight sensor.
I agree completely with what you are saying, both in theory and in practice.
Something else to consider is that it checks the light sensor every 3-6 seconds or so - so that constant CPU usage is also eliminated which not only saves you from having to do that check in the first place, but saves from interrupting (or scheduling around...) other processes happening.
Ideal is what you have said - light on when keyboard out - light off when keyboard closed. You don't need the backlight otherwise.
The only reason I haven't looked further into it yet is because I want to tone down the intensity of the 4 front-facing buttons and as yet there is no way to do so without dropping the illumination level of the keyboard too. A workaround will have to be created to deal with this.
I have a privacy screen protector on my device, so even at the brightest screen setting it is considerably dimmer then the buttons in dim or no light - and it bothers me since my eyes are so sensitive to light.
There are a couple of ways to attack the light issue - one of them is certainly on the kernel level. Appreciate the suggestion!
Towards you and everyone else - some things suggested like this are great idea but may not be immediately implemented for a variety of reasons. Adding another variable to the testing we are doing could skew the results, and it's another thing to keep track of during said testing as a start.
On finished, stable kernels that would be a good thing to implement, but for both our internal testing and the live testing you guys will all be doing for us don't count on things like that right away. As kernels prove out the mods they have been slated for then things like this can be built in. Start with a stable, solid foundation and you can support as many frills as you want...
I don't write this to discourage suggestions - quite the opposite - just trying to give a small window into a bit of the process behind creation so people can understand what's going on a tad more.