win
2 major things.
Number 1, why the hell are you complaining here, Sony won't read your complaint here, go shove it at them not us.
Number 2. Actually that requires hardware support which may not be implemented on the device. LED brightness cannot actually be safely controlled via normal means, they have a fixed voltage they must run at for prolonged life and as such it is impractical to use voltage manipulation to alter the brightness, current draws are always fixed for a given voltage so thats out the window too. The correct method is PWM, effectively to achieve a half brightness with PWM, it repeatedly turns the LED on or off hundreds of times per second, the human eye cant catch the on/off transition and just sees it as a dimly lit LED, however this requires hardware support and device drivers or device drivers which consume a nasty amount of CPU time to emulate PWM. It is most likely that they dont have it rigged up to PWM.
Related
Is it possible to change the light colors within the registry, like Bluetooths light makes a nice sexy blue blink, I would like to have that as my SERVICE light instead, I know it must be possible because the lights change when u charge it, etc. So if you have any expierence or ideas on how, post up guys!
I'm going to go out on a limb here and say that's probably NOT possible.
My reasoning being that "charging" and "having service" is not a software controlled issue. The main unit itself takes care of that so therefore I doubt there's some magic registry hack to switch them over.
Also since the Windows Mobile 2003 SE operating system is designed for multiple devices, a lot of devices won't have Bluetooth lights and green service lights, so I think this further backs up that it's not controlled by software.
Of course with all things... I could be wrong, but I'm not really holding my breath.
Sorry!
I've been wondering, would it be possible to make an app that kicks in when you're on a call, that uses the light sensor as a proximity sensor.
The basic idea is, you put the phone to your ear, it blocks light and the screen locks, take it away from your ear, it detects more light, and unlocks the screen so you can enter numbers etc.
I was also thinking instead of being set at specific light levels (less than 50 for off, over 50 for on etc) it could work on a factor of relative brightness, so if it gets 5 times brighter it knows to unlock the screen.
Does this sound possible?
I don't think this can work. What happens during the night?
very old idea
phone must have bio sensor near speaker which touch to ear, so only hardware solving
using light sensor will work only with light, at dark place\time it doesnt work
another way is to make sensitive top of sensor display for touching but other part of display must be blocked
deadend
Tha X1 speaker is right next to the earpice, it's almost part of it, that's why gave me the idea.+As for dark places, that's why I suggested it measures a differennce in brightness, rather than specific values. Obviously at a certain point, it won't detect any change, I guess then the programdetect darkness up until the point of answering the call, and disable itself.
Or maybe there's a way to use the backlight to create a lightsource but have the touch part off...
Brightness would increase as the phone approached the ear, then drop off as it got there, then similar when you take it away.
Actually, based on the intention, I think it would be sufficient if the phone app is active, the screen is on and locked if phone app is inactive. Touching cheeks, etc are all not real problems in my opinion.
xperia tweak
xperiatweak will fix this issue.
Is there a way to tweak the behaviour of the auto-brightness backlight? At the moment it correctly goes up to full brightness in sunlight, but it doesn't go as dim as I would like under artificial light. At home, after dark, under electric light, I can manually turn the screen brightness down to the minimum level, and it's still bright enough - the auto setting is much brighter than that(although clearly much dimmer than it is in sunlight, so it is doing something).
Can this be tweaked? Failing that, is there an easier way to control the brightness manually - something I can keep running all the time, and which doesn't require the stylus to change the setting?
Try GLight
http://www.ageye.de/index.php?s=glight/about
JustBored said:
Try GLight
http://www.ageye.de/index.php?s=glight/about
Click to expand...
Click to collapse
Thanks, I'll give that a try.
I find Lumos to be more stable and reliable
http://forum.xda-developers.com/showthread.php?t=450318
Ok I havn't tried either of them before but I just installed G-Light.
After a bit of config. it's ok. You need to give each backlight number a wider setting.
Otherwise it'll just flip back and forward in brightness.
So far G-Light is proving rather dissapointing. The phone's built-in "Auto" setting works well, apart from the fact that the brightness doesn't go low enough in dim light - in particular, it manages to choose a good level and then stick to it. G-Light, by contrast, keeps changing the brightness up and down all the time.
I think the notion of having absolute brightness bands may be the wrong way to go. You really want a set-up where the threshold values are in different places depending on whether the light is getting brighter or dimmer. So, as the light fades, you cross a threshold and dim the screen - but when the light goes slightly back up over that threshold, you don't brighten the screen again until it gets significantly higher than that. That way, regardless of the light level, the screen brightness will be steady unless the ambient light level is changing a lot. If you use single threshold values then whenever the ambient light happens to be very close to a threshold value you will always get the brightness going constantly up and down.
Edit: some of the things Lumos does (like averaging across multiple readings) sound hopeful, though. I'll give that a try.
Shasarak said:
So far G-Light is proving rather dissapointing. The phone's built-in "Auto" setting works well, apart from the fact that the brightness doesn't go low enough in dim light - in particular, it manages to choose a good level and then stick to it. G-Light, by contrast, keeps changing the brightness up and down all the time.
I think the notion of having absolute brightness bands may be the wrong way to go. You really want a set-up where the threshold values are in different places depending on whether the light is getting brighter or dimmer. So, as the light fades, you cross a threshold and dim the screen - but when the light goes slightly back up over that threshold, you don't brighten the screen again until it gets significantly higher than that. That way, regardless of the light level, the screen brightness will be steady unless the ambient light level is changing a lot. If you use single threshold values then whenever the ambient light happens to be very close to a threshold value you will always get the brightness going constantly up and down.
Edit: some of the things Lumos does (like averaging across multiple readings) sound hopeful, though. I'll give that a try.
Click to expand...
Click to collapse
Let me know how Lumos is.
Yes as I said earlier you need to widen those settings.
For now I have 5 set to 0-81
6 set to 82-200
8 set to 201-600
10 set to 601-1000
All the rest are disabled by setting the values to -1 to -1
HeavyComponent said:
Let me know how Lumos is.
Click to expand...
Click to collapse
Lumos is also proving dissapointing. It's partly the fault of the hardware - the sensor seems to read 0 even in surprisingly bright light, so the app has no way of telling whether you're at a light level where backlight 1 is appropriate or a light level where backlight 3 is appropriate - both read 0 on the sensor. (This is probably why the default auto option doesn't go below 3 in the first place).
As for Lumos, the author needs to realise that perception of brightness is actually based on an exponential curve. That means that all of the values between level 1 and level 5 are somewhere between 0 and 80 sensor reading. The graph interface is useless for editing custom values with that level of precision - it's trying to squeeze over 2000 values into less than 800 pixels of screen space, and the pixels are tiny! I think you can edit the values directly in the settings.txt file, but that's fiddly - there should be spinboxes, really (as with G-Light).
In any case, you don't want to be editing the values directly! What you want to be doing is taking the phone out of your pocket, looking at it, and thinking "hmm, the screen is too bright at the moment" then adjusting the brightness to whatever level is comfortable for the current ambient light level. The programme should then interpolate the curve that you want, and progressively refine it each time you decide it isn't quite right and tweak the brightness.
I haven't tried to Lumos program yet, but I've been using Glight for a few days. At first I had some issues with it but then I realized that you have to turn the auto light adjustment off in settings first. If not, they'll both be fighting against one another.
Also, you have to set your thresholds pretty carefully as has been already stated. Mine is set to go bright only in bright outside and lowest in a dark room with no light at all.
1 0 to 5
3 10 to 799
8 800 to 2500
I've got mine set low for better battery life and the screen is always readable to me no matter what anyway.
Also, if you're using a the snap on rubber protector (I got a T-Mobile one) it will interfere with the light sensor. I just got one and the lighting is all over the place now. Time to order a full body screen protector.
GLight doesn't seem to work for me. keeps crashing, and the settings don't seem to save at all.
I don't want a sliding scale that Lumos has since i don't think the light sensor is all that accurate (sometimes thinks it's too bright and sometimes thinks its too dark). would rather just have a few settings (pitch black setting, super bright setting, and in the middle) as shawndh suggested.
i have the verizon tp2 - not sure if this might be causing some of the glight probs.
I was thinking that since the OLED screen does not use any backlight, lighting up a few pixels just to form a little led blinking would not tax too much the battery.
I don't know, however, whether waking-up the phone entails significant increase in battery usage. A middle solution would be to wake it every 2 minutes for 10 seconds in order to display the notification and the let it sleep again.
What do you think?
Sounds good good but im not to sure about that... there was another post about having the illuminating back button flash, maybe both menu and back buttons.. alternating between each one with a speed setting?
i love the idea, but the screen is 'off' for a reason...
first of all i don't know if oled screens can 'burn' (meaning the pixels are still showing when they are suppost to be 'off', because they have been 'on' to long)
Also, if it means the chips that control the screen have to be active instead of inactive, your battery drain may be kinda big....
I don't know that OLED would have burn-in (that's more a CRT thing), but they might well burn out - they do have a finite lifespan.
But you're probably right, it would likely mean that the phone couldn't completely go to sleep.
Mithent said:
I don't know that OLED would have burn-in (that's more a CRT thing), but they might well burn out - they do have a finite lifespan.
But you're probably right, it would likely mean that the phone couldn't completely go to sleep.
Click to expand...
Click to collapse
well, in such a case we could rotate randomly the pixels to be lit up (as in real old time screensavers).
With regard to out of sleep battery consumption you have a point. Maybe we could just wake it up for a few seconds and then have it sleep again. In any case if we assume that the major battery draw is the typically screen, then such an arrangement might prove to be acceptable - at least in some cases.
Why not use the backlight on the menu and back button? They shouldn't use too much power or get burned?
Keychar said:
Why not use the backlight on the menu and back button? They shouldn't use too much power or get burned?
Click to expand...
Click to collapse
Yes - I agree this is a very good alternative - yet I do not know how bright these leds are.
Nevertheless, I noticed that the screen is able to display a big animated icon of the battery charging even when the phone is off! (I just received it and I put it in the charger). Thus, I assume there is some kind of control of what the display shows without having to wake-up the system (at least the whole of it).
If this is the case, we could have some led like notification even when the android is in sleep!!
what you say is not necessarily true.. that icon is when the phone is off. which does not translate to being able to display something on a sleeping phone when it is on.. two totaly different issues ..
lgkahn said:
what you say is not necessarily true.. that icon is when the phone is off. which does not translate to being able to display something on a sleeping phone when it is on.. two totaly different issues ..
Click to expand...
Click to collapse
True. I will check whether it is displayed when the phone is on sleep (still off and charging). It implies, however, that the screen can be controlled (also?) independently of the OS.
(all in all the touch buttons respond / light up when touched though the phone is off and charging).
Go guys!
I'm waiting this modification to buy this phone!
I belong to you!
Up !
Very funny topic one year later !
NoLED, BLN ...
The community is very powerfull !
Thank you all
Guys, just search NoLed on market and it's already made ^^. However, following neldar thread on BLN, NoLed use about 10% more battery per hour than off screen. BLN which is found in most of the kernel ( Except damianGTO one ) use about 1% more battery per hour and turn on the backlight of the touch key. Hope this will help you
The battery saver mode page allows for tweaking four settings:
Max brightness
Always-on-display
Disable vibration
Restrict background data
Now, if you disable(!) all of those you still receive minor savings, at least from what the prediction overview (listing all available battery modes) shows. First question: What remains "tweaked" internally to allow for that?
Furthermore, from enabling the items one by one, adjusting max brightness offers a large impact on the predicted runtime. That's no surprise. However, I would have thought that disabling the always-on-display leads to more savings but, looking at the predicted time, it actually doesn't. The impact is close to zero.
Vibration has a minor impact, more than AOD, while a HUGE gain of additional standby hours can be achieved by selecting the "Restrict background data" option. I wonder how that turns out in the everyday use but I think that, if one app would suffer, I would just exclude it and leave the rest in the "saving" position.
Concerning the (assumed) internal changes, I've logged the CPU frequency for a while with the extended battery mode on and off and can't see that throttling is active like I saw with other phones and their battery saver modes, so that's a nice trait. The chipset still clocks to max when needed, same as with the extended mode off.
How are your experiences with that mode? Does it offer more runtime (namely: are the predictions somehow in line with reality?) or is it leading to added lag or other problems? Currently, it seems like taking a lock at that background data option is worth a shot.
BasicallyCP said:
The battery saver mode page allows for tweaking four settings:
Max brightness
Always-on-display
Disable vibration
Restrict background data
Now, if you disable(!) all of those you still receive minor savings, at least from what the prediction overview (listing all available battery modes) shows. First question: What remains "tweaked" internally to allow for that?
Furthermore, from enabling the items one by one, adjusting max brightness offers a large impact on the predicted runtime. That's no surprise. However, I would have thought that disabling the always-on-display leads to more savings but, looking at the predicted time, it actually doesn't. The impact is close to zero.
Vibration has a minor impact, more than AOD, while a HUGE gain of additional standby hours can be achieved by selecting the "Restrict background data" option. I wonder how that turns out in the everyday use but I think that, if one app would suffer, I would just exclude it and leave the rest in the "saving" position.
Concerning the (assumed) internal changes, I've logged the CPU frequency for a while with the extended battery mode on and off and can't see that throttling is active like I saw with other phones and their battery saver modes, so that's a nice trait. The chipset still clocks to max when needed, same as with the extended mode off.
How are your experiences with that mode? Does it offer more runtime (namely: are the predictions somehow in line with reality?) or is it leading to added lag or other problems? Currently, it seems like taking a lock at that background data option is worth a shot.
Click to expand...
Click to collapse
Only thing I've noticed is when I have my phone set to Extended and I've set Max Brightness to 80%. However, I've seen my Brightness go over 80% on Auto especially when I was outdoors (saw it hit 100% and Boosted). Under Manual Brightness, I can have it go to 100% too. So that 80% is misleading?
Good find. I was wondering too since the prediction page instantly applies a gain in standby hours (and a significant one at that) by just enabling the "max brightness" feature. Since it can not know when or for how long the display will be on and what range the "auto" feature will use in a given situation, it seems like a very optimistic value, especially if you just use a limit of 95% for example.
But regarding your question, it's indeed strange to see "auto" exceeding the max brightness limit. I mean, the limit is there for the auto mode only. Might be a bug, unless we struggle to see the logic behind acting like that.
Personally, I would leave max brightness alone since it's more useful to have the display ramp up to max in order to actually see something when needed. If "auto" generally sets up the display as being too bright, one can still adjust the slider (even in auto mode) to tune the point of optimal brightness. I think it acts as an offset to the actual (internal) value the automatic comes up with. At least, that's how I perceived the feature on this and other phones so far.