Some of you would already know that the lightsensor filter in the Evo kernels is now working ( I would say atleast 80% working ) and responds best to Desire builds.
I have it working just fine for the last few hours on the AndroidMedaUltimate 1.3 version. Here are my settings in case you wanna try out.
CAUTION : If you change the values too many times, lightsensor stops responding and you will not see any changes in values. I believe thats CM related.
My Setup
Build : AndroidMedaUltimate 1.3
Kernel : StockEvo Autobuild dated Oct 29
(No SetCpU/taskkillers/etc)
1. Make sure Auto Brightness is disabled under Settings->Display
2. Goto Settings->Cyanogenmod Settings->User Interface->Automatic Backlight
3. Under Light Sensor filter, make sure Enabled is unchecked (No filters!)
4. Under Light levels, check "Allow Light Decrease" and set "Decrease hysteresis" to 0% (Yes thats no typo, for some reason sensor responds faster this way )
5. Check "Use Custom"
6. Tap on Edit Other Levels...
7. Now set values as in below screenshot and table
Lower ....... Upper ............Screen...........Buttons
0 ____________ 169 _______________ 85 _____________ 255
170 __________ 279 _______________ 120 ____________ 255
280 __________ 749 _______________ 170 ____________ 255
800 __________ () _______________ 254 ____________ 255
Note - The last value is 254, for some reason when I had it as 255 and went outside, brightness got stuck at max and sensor stopped responding
Click to expand...
Click to collapse
8. Tap Save & Apply
9. Wait for few seconds and try covering and changing light, you should see the sensor values change on top
10. Once that starts happening, enable Auto Brightness under Display settings
11. Reboot (Best Practice )
---------------
You can add more levels and adjust the lower/upper range alongwith the Screen values (30-255) to suit you better. However, the more you change it the more its likely to end up not working. Dont know why.
Interesting, will be testing this today with Shubcraft 2.0 and post my findings.
thanks, done the changes and testing with Htcclays V1.4.
edit: it is working very well for me.no lightsensor issue for me.
many thanks for your tip.
Thank you works grat
v-b-n said:
1. Make sure Auto Brightness is disabled under Settings->Display
2. Goto Settings->Cyanogenmod Settings->User Interface->Automatic Backlight
3. Under Light Sensor filter, make sure Enabled is unchecked (No filters!)
4. Under Light levels, check "Allow Light Decrease" and set "Decrease hysteresis" to 0% (Yes thats no typo, for some reason sensor responds faster this way )
5. Check "Use Custom"
6. Tap on Edit Other Levels...
7. Now set values as in below screenshot and table
8. Tap Save & Apply
9. Wait for few seconds and try covering and changing light, you should see the sensor values change on top
10. Once that starts happening, enable Auto Brightness under Display settings
11. Reboot (Best Practice )
---------------
You can add more levels and adjust the lower/upper range alongwith the Screen values (30-255) to suit you better. However, the more you change it the more its likely to end up not working. Dont know why.
Click to expand...
Click to collapse
Thanks very much for this, a few questions if you please.....
I'm using Typhoon 3.8.0.
I'm finding these settings under
Settings->Cyanogenmod Settings->Display->Automatic Backlight
not
Settings->Cyanogenmod Settings->User Interface->Automatic Backlight
And I don't know if that has any underlying significance - like it not being implemented in the same way in Typhoon?
Secondly you don't mention the "screen dim level" setting I see in the same "Display" menu. I've wound it down to 6 (default is 20), but not seeing much difference?
Thirdly, I've used the settings in the "other levels" as your table shows, but I wonder why you used those settings, what drove you to pick those numbers?
Finally, you talk about changing it too much stopping it working....when that happens what do you do to revert? Reboot? Or return to defaults and reboot? or something else?
Thanks, I'm hoping this will help balance out the fact that up to now I've not used auto-brightness so as to keep the battery life up but it's a bit of a pain in bright light to see the screen....
Thanks
Our Nexus S has been blessed with the release of ICS 4.0 in which the light sensor values have been significantly improved over GB. In GB we had about 5 or 6 light sensor values which would decide how bright to set the screen. This created an opportunity for the CyanogenMod team to code the Automatic backlight settings with filtered values in between to try to help the community with correct brightness levels. Still it was a far cry from what is now possible because of the fine increments in light sensor delivered in with the 4.0 binaries.
These settings are a good starting point and can serve well as default values for most. However, depending on your eyes and Voodoo settings you might have to adjust them to your own comfort. So lets get started.
Open the CyanogenMod Settings (if you don't have them in your app menu, ask your ROM developer to integrate them)
Go to Display-> Automatic backlight
Enable - obviously turn this on
Window length - set as low as possible. 2 is the lowest currently. Since our sensor values degradation is very fine now, this is less of use
Reset threshold - set to disabled. Again, this depends on the window length
Sample interval - set to 2s. This will ask the processor to check the brightness level every 2 seconds. You can set it based on what you feel is correct but obviously low values can improve accuracy but uses more cpu and drains your battery quicker
Use custom - check this. we'll set our own values
Screen dim level - this is the default setting for your screen lowest dim level. I use 10 but you might have to use more or less depending on the quality built of your screen and voodoo settings.
Edit other levels... - skip this to the last step
Allow light to decrease - check this.
Decrease hysteresis - set to 0%
Now tap on "Edit other levels..."
Scroll down and tap "set number of levels" set it to 25. Now set the "Lower" value and a "Screen" value for it. The first "Lower" value is set to 0 and can't be modified. "Upper" value is set automatically based on the two values of "Lower" and "Screen". "Buttons" value never worked on the Nexus but with proper kernel support they can change based on light sensor conditions. For now, set all button values to 255.
All values can be set from 0 to 255. Here are my default values:
Code:
Lower | Screen
0 | 10
5 | 20
10 | 30
15 | 40
20 | 50
30 | 60
40 | 70
50 | 80
60 | 90
80 | 100
100 | 110
120 | 120
140 | 130
180 | 140
220 | 150
260 | 160
300 | 170
380 | 180
460 | 190
540 | 200
620 | 210
1240 | 220
2480 | 230
4960 | 240
10000 | 255
Go up and hit "save and apply" after setting it up.
If you're wondering why these values, I doubled the last increment every 4th value. Since the lowest values are the most important for us because we usually are indoors with different lightning conditions, the higher values can be quickly set to max 255 screen brightness when anything over 10,000 hits the sensor such as sitting too close to a powerful light bulb or if you happen to find yourself on Mercury during the day (might want to bring a suit also ).
Modifications and adjustments:
If the screen seems too bright or too dim at any time, go back to the "light sensor levels" screen and look up the current screen value. It's the 2nd line after "Sensor (filtered/raw)". Then scroll down and find a "Screen" setting which is equal to that value and modify it. Try not to move around and make sure the "Sensor (filtered/raw)" values stay the same. What you are doing is simply adjusting your phone's brightness to fit current light sensor level so if it changes while you set it, you wont know if it worked. Also, you can adjust all "Screen" values by 5 or more (down or up) if it feels like it's all off your comfort level.
If you really want to get down and dirty and understand all the fuzz in details byrong over at HTC Droid Incredible forums posted a great explanation and all the science behind it. Just remember that their phone is limited to just a few light sensor values where ours has virtually thousands and that's why I chose to almost eliminate the filtered value to control flicker. But it's up to you if you want to play with that. Also, he has a great post on CPU usage titled "Effects of CPU Frequency and Screen Brightness on Power Consumption". Make sure to check it out.
And one last note regarding the voodoo settings... your screen is different than other phones. I have 4 Nexus S phones and none of them can be set to the same voodoo settings to create the same colors. Depending on screen fabrication quality and possibly date of manufacture, it will vary slightly and sometimes greatly. So if you post your voodoo settings and someone says they suck now you know why.
Awesome guide, thanks!
Or if you're not on CM, grab this app : https://market.android.com/details?id=com.vito.lux , you can set levels based on lux values with ease. Also on new year's sale now at half the price.
madd0g said:
Or if you're not on CM, grab this app : https://market.android.com/details?id=com.vito.lux , you can set levels based on lux values with ease. Also on new year's sale now at half the price.
Click to expand...
Click to collapse
Tried it, works great.
I have this enabled on CM setting and followed your directions...One question? Am I supposed to have automatic brightness levels checked in system settings, display, brightness? Thanks! I believe yes but just want to be sure
Necro but how are these settings in regards to battery life?
This is a hacky fix but it is a fix.
It gives you a backlight that will go from dim to full bright without the need for any other apps running. It's not uber configurable like dedicated apps as it's limited by hardware but it requires 0 ram, 0 runtime and 0 battery
Append the following to hw_config.sh. The sleep is a hack but a viable one - hw_config is fired up by one of the rc files as a oneshot service so it should be OK to extend it's operation
If you prefer you could just make a standalone script with everything after the sleep command (make sure you have the dev= assignment from hw_setup too!) and fire it off with a script executer of your choice
Code:
#this sleep ensures that the system is up and done [email protected] with light levels before setup
sleep 30
#select als group for backlight
echo 1 > $dev/leds/lcd-backlight1/als_group
echo 1 > $dev/leds/lcd-backlight2/als_group
#set both to max. brightness - als will lower
echo 255 > $dev/leds/lcd-backlight1/brightness
echo 255 > $dev/leds/lcd-backlight2/brightness
#set custom als curve
echo 7,1,48,72,24,255,0 > $dev/als_group1
#set custom filter frequency
echo 1000 > $dev/als_filter_down_speed_mHz
echo 1000 > $dev/als_filter_up_speed_mHz
#turn on hardware als
echo 1 > $dev/als_on
Notes
Make sure you have completely uninstalled any other light controllers - Velis in particular wreaks havoc even when disabled - it still receives the screen on intent and resets the brightness which results in a black display - guess how I know ....
Make sure you have disabled auto brightness control in the standard Sony settings and set the slider to full bright for good measure
I use nobootanimation so my phone boots a bit quicker than some. It might be that sleep 30 isn't long enough for an animated startup
Best thing is probably to create a setup script and run that to satisfy yourself the hack works. Then add it to hw_config and increase the delay if it doesn't work!
If you want to know more about the als setup check HERE or read the AS3677 datasheet.
Sadly I wasn't able to find out how the ALS curves are loaded into the current system, hence the direct hardware poking
There's some useful debug capability built into the sysfs
cat $dev/debug to see light sensor outputs and calculated backlight settings
cat als_group1 to read back the curve settings complete with a graph showing the response curve
A software guy could probably easily make an apk that hooked to the SCREEN_ON intent to program all this (and have a nice gui to show/edit the curve) but I'm a hardware engineer so that ain't me!
It's easier to just use Lux. Thanks anyway.
pakatsui said:
It's easier to just use Lux. Thanks anyway.
Click to expand...
Click to collapse
LUX, YAB or other brightness app will don`t work correct on all my Xperias. Only with "system brightness settings" active in the background this apps will change the brightness in realtime. When i close the systemsettings brightness will change no longer or with some luck once when unlocking.
so i will test this Hack, hope it helps to become a wide range in realtime.
heross said:
LUX, YAB or other brightness app will don`t work correct on all my Xperias. Only with "system brightness settings" active in the background this apps will change the brightness in realtime. When i close the systemsettings brightness will change no longer or with some luck once when unlocking.
so i will test this Hack, hope it helps to become a wide range in realtime.
Click to expand...
Click to collapse
Lux works fine. I'm using it now.
Sent from my Xperia SP using xda premium
Hello t_o_f,
today i have made test this fix in Car navigation from sunlight to the moon. awesome. this is the best fix i have always seen for xperia autobrightness. :good::laugh::good: ten points from germany.
the best, lowest brightness it is configurable with the Stock slider!
Call me daft. I disabled auto brightness, jacked the brightness to high, and have no other brightness apps installed. I appended the above to /etc/hw_config.sh and rebooted.
auto brightness didn't work. It was still jacked up to high so I enabled it and tested, still not working. Did I do something wrong? I'm on 254 rooted.
I have been trying to work up a tile for my Quick Tiles app that would allow a user to toggle the glowlight from the panel. With the help of @marcoNST (I do not own an NSTG) I have isolated the Glowlight Control dialog but my intention was to have that as an option for a long-press of the tile, while a simple tap would toggle the light without any intensity adjustment.
This toggle is normally handled by a 2-second press of the "n" button. I've been scouring logcats and tracking down smali files in jars but the closest I've come up with is a broadcast which is probably used, among other things, to tell the status bar manager that the light icon needs to be shown/hidden--so it's an after-the-fact thing:
Code:
com.BN.intent.action.SCREEN_LIGHTS_ON (or OFF)
I've exhausted my bag of tricks
Attached is a logcat showing the "n" button used to repeatedly toggle the light. There is a PowerManagerService statement each time, but I distrust this because I see that statement a lot in logcats, even for my NST sans glowlight. In fact, that statement often appears in triples!
So...quite the challenge
I'd appreciate hints or outright solutions. Any takers?
Code:
int i = 128; [b]// 0 (off) to 255 (full on)[/b]
ContentResolver cr = context.getContentResolver();
System.putInt(cr, System.SCREEN_BRIGHTNESS_MODE, System.SCREEN_BRIGHTNESS_MODE_MANUAL);
System.putInt(cr, System.SCREEN_BRIGHTNESS, i);
This is standard Android "screen brightness".
Renate NST said:
Code:
int i = 128; [b]// 0 (off) to 255 (full on)[/b]
ContentResolver cr = context.getContentResolver();
System.putInt(cr, System.SCREEN_BRIGHTNESS_MODE, System.SCREEN_BRIGHTNESS_MODE_MANUAL);
System.putInt(cr, System.SCREEN_BRIGHTNESS, i);
This is standard Android "screen brightness".
Click to expand...
Click to collapse
I thought/hoped as much when I ran across a kvetching post about the NGP and the need for a menu to turn on the light. So the complainer wrote a little app which just toggled the "screen brightness" to 0 for OFF and some arbitrary value he liked for ON.
It seemed wonderfully simple but when I did the same thing and shared the app with an NSTG user, it did absolutely nothing
Edit: I looked at this again and maybe made some progress. Although I have only a non-Glow NST, I did figure out how to call up the light control dialog, so I can do some tentative fiddling. If I use that dialog to turn the non-existent light ON and then change the screen brightness to zero, my tick mark for ON disappears and the slider control moves all the way to the left. That looks promising. One issue was that I saw a warning this time that autobrightness was ON (who knew?) and I had better turn it OFF. So I did that. Unfortunately when I start with the non-existent light in the OFF position, changing the screen brightness to a non-zero value does not place a tick mark in the light control panel showing the light as on. The slider advances, but...
Well, it's hard to test non-existent hardware, so I guess it's time to put together another toggle app and let my co-conspirator with the NSTG test it.
Edit: Nope. Changing the screen brightness to 0 or some other arbitrary value has no effect on the glowlight for the NSTG. Back to square zero.
nmyshkin said:
Back to square zero.
Click to expand...
Click to collapse
I've never had a NSTG, so I can't say.
I use an in-app brightness control in my reader app and it's exactly like the code above.
It works on every device that I have, Nooks, phones, tablets.
Maybe the NSTG is different.
Did you look in the code to see how it was done?
Does it use something native to talk to I2C?
Renate NST said:
I've never had a NSTG, so I can't say.
I use an in-app brightness control in my reader app and it's exactly like the code above.
It works on every device that I have, Nooks, phones, tablets.
Maybe the NSTG is different.
Did you look in the code to see how it was done?
Does it use something native to talk to I2C?
Click to expand...
Click to collapse
To be honest, I finally let it go. It's really hard to troubleshoot without the hardware and there was no real way for me to examine what was going on or not going on other than by report. I ddn't want to exhaust the member with the NSTG, so....
Renate NST said:
I've never had a NSTG, so I can't say.
I use an in-app brightness control in my reader app and it's exactly like the code above.
It works on every device that I have, Nooks, phones, tablets.
Maybe the NSTG is different.
Did you look in the code to see how it was done?
Does it use something native to talk to I2C?
Click to expand...
Click to collapse
Well, yes, actually. I finally tracked down an old NSTG for a reasonable price (a few tiny screen defects with the light, as expected...) and with your hint and some additional sleuthing I am half-way to my goal. There are two values in
/sys/devices/platform/i2c_omap.2/i2c-adapter/i2c-2/2-0040/leds/lcd-backlight/
one is brightness and the other is brightness2. Both are "0" when the light is off. When the light is on, they become the intensity value. Manually changing the value of brightness from "0" to some other number turns the light on (brightness2 stays at "0" when the value of brightness is manually changed, so they are not ganged together; not sure why there are two values). Manually changing the value of brightness back to "0" turns the light off.
This is good, but unfortunately the status bar icon does not change when the values are changed manually A portion of the logcat of the sequence of turning the light on and off in the usual way is below
Code:
D/WindowManager( 789): CALLING monitor
D/StatusBarPolicy( 789): ACTION_SCREEN_LIGHTS_ON
D/SurfaceFlinger( 789): Frame buffer posted; elapsed time = 17 msecs
I/PowerManagerService( 789): setPowerState: mPowerState=0x3 newState=0x3 noChangeLights=false reason=1
D/SurfaceFlinger( 789): Frame buffer posted; elapsed time = 12 msecs
D/WifiService( 789): ACTION_BATTERY_CHANGED pluggedType: 0
I/PowerManagerService( 789): setPowerState: mPowerState=0x3 newState=0x3 noChangeLights=false reason=1
I/PowerManagerService( 789): setPowerState: mPowerState=0x3 newState=0x3 noChangeLights=false reason=1
D/WindowManager( 789): CALLING monitor
I/PowerManagerService( 789): setPowerState: mPowerState=0x3 newState=0x3 noChangeLights=false reason=1
I/PowerManagerService( 789): setPowerState: mPowerState=0x3 newState=0x3 noChangeLights=false reason=1
D/WindowManager( 789): CALLING monitor
D/StatusBarPolicy( 789): ACTION_SCREEN_LIGHTS_OFF
So now the question becomes "How do I make the status bar icon change?" There's not a lot of info (for me) in that logcat snippet. I'm thinking an intent is broadcast when the light is cycled in the intended way, but I don't see evidence of it. I should add that this device is entirely gutted of B&N stuff (yay! I finally figured out how to kill the endless whining for B&N server contact!!), so whatever remains is capable of making the status bar icon change.
?
The two brightnesses could be the two different colors of LED for color tuning.
I'm not sure if this had that.
The backlight is in /system/framework/framework.apk in android.provider.settings.System
If you want, post the file somewhere and I'll take a look.
Yes, the settings are there, but I haven't tracked it to the hardware.
Renate NST said:
The two brightnesses could be the two different colors of LED for color tuning.
I'm not sure if this had that.
The backlight is in /system/framework/framework.apk in android.provider.settings.System
If you want, post the file somewhere and I'll take a look.
Click to expand...
Click to collapse
I assume you mean framework.jar as there is only the framework-res.apk and it contains precious little code.
I've decompiled the jar and taken a look around. It's a little different than what you were anticipating, probably. Any "light" references seem to be in Settings.smali, not the Settings$System.smali. There appears to be a reference to a broadcast intent regarding whether the lights have changed or are on/off but that seems to refer to com.BN which is certainly gone (I think) since I removed all the (visible) B&N stuff, including the jars. And yet it all still works properly if the light is turned on and off with the "n" button. What I don't see is how the status bar is getting wind of the change. But you'll probably see many things I don't
Copy of framework.jar attached.
In short, how in normal Android it's supposed to work.
You change the settings.
Settings is only a content provider, it doesn't know or care about the difference between "screen_brightness" and "activate_doomsday".
Some service puts a ContentObserver on that setting and when it changes it does something.
So for the Glow2:
Code:
services.jar
com.android.server.power.PowerManagerService
systemReady()
ContentResolver.registerContentObserver(Settings.System.SCREEN_BRIGHTNESS)
com.android.server.power.DisplayPowerController
com.android.server.LightsService.Light
setBrightness()
setLightLocked()
setLight_native()
libandroid_servers.so
setLight_native
So look at what you have for settings in:
Code:
# sqlite3 /data/data/com.android.providers.settings/databases/settings.db
.dump
Then:
Code:
# settings put <namespace> <key> <value>
The status bar will only change if you change through Settings, not the I2C.
So maybe the NSTG uses different settings.
Renate NST said:
In short, how in normal Android it's supposed to work.
You change the settings.
So look at what you have for settings in:
Code:
# sqlite3 /data/data/com.android.providers.settings/databases/settings.db
Click to expand...
Click to collapse
I've had a peek at settings.db before. In "system" it shows the last intensity setting of light (so it's non-zero generally, even when the light is off). There is also an entry for "screen brightness mode" for which I show a value of 0 (perhaps it's 1 when the light is on?) and also "dim screen" which shows a value of 1 (again, I copied this file when the light was off).
Hmm...
Aha. If I copy out the settings.db file when the light is on, I get a value of 1 for "screen brightness mode".
Now to try the real thing. Thanks for pointing me in a possible direction. So many of those database values seemed like descriptive artifacts that don't effect real change when you alter them but instead report a change when it has happened. I have been mistaken.
nmyshkin said:
I get a value of 1 for "screen brightness mode".
Click to expand...
Click to collapse
It's "screen_brightness_mode" and that means to use the ambient brightness to modify the display brightness.
None of the Nooks have a sensor, so that really doesn't affect anything.
"screen_brightness" is the stock single value for brightness.
Are there any other settings for brightness/color/temp/whatever?
Post the services.jar
Renate NST said:
It's "screen_brightness_mode" and that means to use the ambient brightness to modify the display brightness.
None of the Nooks have a sensor, so that really doesn't affect anything.
"screen_brightness" is the stock single value for brightness.
Are there any other settings for brightness/color/temp/whatever?
Post the services.jar
Click to expand...
Click to collapse
Using sqlite to change the value of screen_brightness_mode in settings.db does not, in fact, turn on the light. What is does do is (bizarre) tick the box that says the light is on in the quick settings panel for the light :silly:
I've attached services.jar. There are no other entries in settings.db that could plausibly be construed as having to do with the light.
nmyshkin said:
I've attached services.jar.
Click to expand...
Click to collapse
I can see that PowerManagerService$SettingsObserver.smali is only tracking changes to screen_brightness_mode.
I can see that B&N strayed from stock here quite a bit.
I can see that this jar has been modified by something called "ModUtils"
So:
If you want to turn on the light, use a ContentResolver, set screen_brightness, then set screen_brightness_mode to 1;
If you want to turn off the light, use a ContentResolver, set screen_brightness_mode to 0;
If you want to change the level of the light, use a ContentResolver, set screen_brightness, then increment screen_brightness_mode (so as to effect a change).
Renate NST said:
I can see that PowerManagerService$SettingsObserver.smali is only tracking changes to screen_brightness_mode.
Click to expand...
Click to collapse
So that's the place, then.
I can see that B&N strayed from stock here quite a bit.
Click to expand...
Click to collapse
Based on the principle that enough is never enough.
I can see that this jar has been modified by something called "ModUtils"
Click to expand...
Click to collapse
Yes, service and framework jar both have small modifications in them from NookTouchModManager and GApps installation.
So:
If you want to turn on the light, use a ContentResolver, set screen_brightness, then set screen_brightness_mode to 1;
If you want to turn off the light, use a ContentResolver, set screen_brightness_mode to 0;
If you want to change the level of the light, use a ContentResolver, set screen_brightness, then increment screen_brightness_mode (so as to effect a change).
Click to expand...
Click to collapse
I assume you are suggesting this so that the changes will be broadcast to whatever routine is updating the idiot icon in the status bar to show that the light is either on or off (I mean, if you can't tell the light is on or off by looking at the screen, an icon is probably not going to help you...). Otherwise the same effect can be accomplished by changing the values of "brightness" and "brightness2".
Since I'm not going to be addressing this issue via JAVA, I need to keep looking for a method to address the status bar icon change. If I had that, I'd be fine with writing a simple value change via shell command to turn the light on/off.
The Law of Unintended Consequences
Mark this "sorta solved", I guess.
While mulling over the possibilities I decided to go ahead with setting up the device and flashed the only available kernel that includes both No Refresh and USB host. This kernel is, unfortunately, based on FW 1.1.5 but it behaves fine on my NST running FW 1.2.2.
It does not like the Glowlight option. What it does is interesting: a long-press of the "n" button, which should turn the light on/off at the last used intensity, changes the status bar icon but does not turn the light on or off. Accessing the light from the control panel changes the status bar icon but only turns the light on if the slider is touched. To actually turn the light off, it is necessary to push the slider all the way down manually before changing the status bar icon. And actually, you cannot get to "0" by manually pushing the slider. The stored value turns out to be "3".
While still not revealing how the status bar icon gets the word, this did enable me to construct a software "solution" from shell commands that both changes the status bar icon and turns the light off and on, after checking settings.db to see what the last intensity setting was. I could not have done that without my previous delving into the i2c stuff.
In the end none of this mattered because what I really wanted to do was move the function from a long-press of the "n" button to some other hardware button. This was possible to do with Nook Touch Mod Manager, but when I addressed the hardware button with a sendevent command via Tasker, it responded as the stock hardware assignment, not the reassigned button. So game over.
Anyway, I have Glowlight functionality with a kernel based on 1.1.5 and in the end, that's almost as good.
I tried many GSIs with Galaxy Tab A T510 but in all of them whenever I set the brightness to very low or lowest the display goes black and I can't seem to revert this as none can be seen afterwards on screen. Any fix for this, guys?
Mrigendra10 said:
I tried many GSIs with Galaxy Tab A T510 but in all of them whenever I set the brightness to very low or lowest the display goes black and I can't seem to revert this as none can be seen afterwards on screen. Any fix for this, guys?
Click to expand...
Click to collapse
Several system settings govern brightness and can be changed with ADB.
Click here to learn about ADB. According to the Android documentation:
public static final int SCREEN_BRIGHTNESS_MODE_MANUAL
SCREEN_BRIGHTNESS_MODE value for manual mode.
Constant Value: 0
public static final String SCREEN_BRIGHTNESS
The screen backlight brightness between 0 and 255.
Click to expand...
Click to collapse
So executing these two commands should might work:
adb shell settings put system screen_brightness_mode 0
adb shell settings put system screen_brightness 0
Clamtacos said:
Several system settings govern brightness and can be changed with ADB.
Click here to learn about ADB. According to the Android documentation:
So executing these two commands should might work:
adb shell settings put system screen_brightness_mode 0
adb shell settings put system screen_brightness 0
Click to expand...
Click to collapse
Thanks for the method you provided but I already figured it out in phh settings. There is an option to set minimum brightness, I set it to a higher number and it worked like a charm. Oh! And also double tap to wake can be enabled from phh settings too.