Database Users

Camera Blur Gone - Simple Fix

By simply changing the brightness level to -2.0 you will no longer have a blur - it's like changing the ISO on a camera and the FPS will jump by over 50%. check it out in full here: http://www.fuzemobility.com/decrease-the-blur-of-your-camera-really/

bugsykoosh said:
By simply changing the brightness level to -2.0 you will no longer have a blur - it's like changing the ISO on a camera and the FPS will jump by over 50%. check it out in full here: http://www.fuzemobility.com/decrease-the-blur-of-your-camera-really/
Click to expand...
Click to collapse
Sounds excellent, will try this out!!
EDIT
I have tried this and can find no improvement whatsoever. As kkchan stated below, all I notice is the picture has become darker due to the decrease in brightness level. I have even tried this at -1.0, but still no improvement

Hi,
I tried, no improvement, sometime seem even worst because the photo become darker.

kkchan said:
Hi,
I tried, no improvement, sometime seem even worst because the photo become darker.
Click to expand...
Click to collapse
I did it myself on a Touch HD and went from +2 and changed it to -2 and it was a world of difference. At +2 any movement was a blur and at -2 I could move the camera and still get a clean shot

Fallen Spartan said:
Sounds excellent, will try this out!!
EDIT
I have tried this and can find no improvement whatsoever. As kkchan stated below, all I notice is the picture has become darker due to the decrease in brightness level. I have even tried this at -1.0, but still no improvement
Click to expand...
Click to collapse
In extreme light situtations (a bright day) there's almost no difference in speed but the HD never had a problem in very high light. The real impact is in moderate to low light. So far there are 2 comments at FuzeMobility both stating that it works effectively and I tested it last night on the HD and took an unusable camera and had something that could take a photo. Did you guys enable the FPS info to see if there was a change?

bugsykoosh said:
In extreme light situtations (a bright day) there's almost no difference in speed but the HD never had a problem in very high light. The real impact is in moderate to low light. So far there are 2 comments at FuzeMobility both stating that it works effectively and I tested it last night on the HD and took an unusable camera and had something that could take a photo. Did you guys enable the FPS info to see if there was a change?
Click to expand...
Click to collapse
I had already tried tweaking a number of settings for both the camera & video to get a better pic. This may have had some effect on these new settings. I will play around with it and see what I come up with

Fallen Spartan said:
I had already tried tweaking a number of settings for both the camera & video to get a better pic. This may have had some effect on these new settings. I will play around with it and see what I come up with
Click to expand...
Click to collapse
What settings if you don't mind? I'm always up for more tweaking I know about decreasing the delay times:
HKLM/Software/HTC/Camera/Captparam/ and set CaptureTimer = 0 and EnableCapKeyDelay = 0 and CapKeyDelayTime = 0
and changing the panaramic photo size...I hope you have a few more though

bugsykoosh said:
What settings if you don't mind? I'm always up for more tweaking I know about decreasing the delay times:
HKLM/Software/HTC/Camera/Captparam/ and set CaptureTimer = 0 and EnableCapKeyDelay = 0 and CapKeyDelayTime = 0
and changing the panaramic photo size...I hope you have a few more though
Click to expand...
Click to collapse
Basically I read through a lot of threads regarding enhancing camera and have changed numerous things including those mentioned by yourself, some I can't remember to be honest and those mentioned in the wiki listed below. Also using HD Tweak etc
Increase Quality of Photos
To increase the quality of photos, open the Camera, go to Settings, Advanced, then Image Properties. Increase Contrast to 5, Saturation to 5, and Sharpness to 4. Now you will have better definition and much more realistic colours. Also don't forget to choose Super Fine under Quality in Advanced Settings menu.
Reduce Blurriness in Photos
To focus better, have shutter set just to Touch. After you have touched you have the whole three seconds to steady your hand and take a non-blurry photo.
Activate Hidden Photo Modes
You can activate hidden photo modes using the 'HD Tweak' app. Make sure to leave the resolutions for these modes at 1 megapixel though or they may not work properly. For for the more advanced users, use the following reg entries:
To enable Burst mode
Mobile Device\HKLM\Software\HTC\Camera\P6
set "Enable" on "1"
To enable Sports mode:
Mobile Device\HKLM\Software\HTC\Camera\P8
set "Enable" on "1"
To enable Video Share mode:
Mobile Device\HKLM\Software\HTC\Camera\P9
set "Enable" on "1"
To enable GPS Photo mode:
Mobile Device\HKLM\Software\HTC\Camera\P10
set "Enable" on "1"
Get True 5 Mega pixel Resolution When Using Camera
To get 5MP instead of 4MP resolution when using your camera, you must switch off Widescreen mode in the 'Advanced' Menu.
Normal screen = 2592 x 1944 pixels = 5,038,848 pixels = 5MP
Widescreen = 2592 x 1552 pixels = 4,022,784 pixels = 4MP
Get Better Video Quality When Using Camera
Use MPEG format instead of H.263 for better quality video output. This option can be found by going to the Advanced Setting from the Video Settings menu. Once there, go to Capture Format and change format if necessary.
If I can think of any more I'll let you know.
These threads may help:
Best Camera Setting for Taking Pictures
Blackstone Camera 2009 (HTC) Discussion

Fallen Spartan said:
Basically I read through a lot of threads regarding enhancing camera and have changed numerous things including those mentioned by yourself, some I can't remember to be honest and those mentioned in the wiki listed below. Also using HD Tweak etc
Increase Quality of Photos
To increase the quality of photos, open the Camera, go to Settings, Advanced, then Image Properties. Increase Contrast to 5, Saturation to 5, and Sharpness to 4. Now you will have better definition and much more realistic colours. Also don't forget to choose Super Fine under Quality in Advanced Settings menu.
Reduce Blurriness in Photos
To focus better, have shutter set just to Touch. After you have touched you have the whole three seconds to steady your hand and take a non-blurry photo.
Activate Hidden Photo Modes
You can activate hidden photo modes using the 'HD Tweak' app. Make sure to leave the resolutions for these modes at 1 megapixel though or they may not work properly. For for the more advanced users, use the following reg entries:
To enable Burst mode
Mobile Device\HKLM\Software\HTC\Camera\P6
set "Enable" on "1"
To enable Sports mode:
Mobile Device\HKLM\Software\HTC\Camera\P8
set "Enable" on "1"
To enable Video Share mode:
Mobile Device\HKLM\Software\HTC\Camera\P9
set "Enable" on "1"
To enable GPS Photo mode:
Mobile Device\HKLM\Software\HTC\Camera\P10
set "Enable" on "1"
Get True 5 Mega pixel Resolution When Using Camera
To get 5MP instead of 4MP resolution when using your camera, you must switch off Widescreen mode in the 'Advanced' Menu.
Normal screen = 2592 x 1944 pixels = 5,038,848 pixels = 5MP
Widescreen = 2592 x 1552 pixels = 4,022,784 pixels = 4MP
Get Better Video Quality When Using Camera
Use MPEG format instead of H.263 for better quality video output. This option can be found by going to the Advanced Setting from the Video Settings menu. Once there, go to Capture Format and change format if necessary.
If I can think of any more I'll let you know.
These threads may help:
Best Camera Setting for Taking Pictures
Blackstone Camera 2009 (HTC) Discussion
Click to expand...
Click to collapse
Unfortunately I know about those Thank you though - I'm sure a lot of people will benefit from that list. The ability to do infinite zoom is still elusive as far as I know...

bugsykoosh said:
Unfortunately I know about those Thank you though - I'm sure a lot of people will benefit from that list. The ability to do infinite zoom is still elusive as far as I know...
Click to expand...
Click to collapse
More settings/tweaks included in those 2 threads I believe though

[GUIDE] Automatic backlight

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?

[Hack]Improved Hardware Auto Brightness

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.

reduce brightness on NGLP

Wondering if there's a tweak to a config file that could lower the min brightness on the NGLP, would appreciate any input, thank you.

I've always found the slider to be quite good and wouldn't want it lower than the minimum setting unless it was full off. I know that doesn't really answer your question, but if 99.9% of users are happy with the existing slider it is unlikely there will be a patch or tweak made on the off chance. Having said that, you don't get what you don't ask for so someone here may be able to help.
Is there a specific reason for wanting this or is it just because you find the minimum too bright?

Do you use the Settings > Display > Brightness?
That goes down to at least 5%
You can set it yourself in code:
Code:
// int i is from 0 - 255
System.putInt(getContentResolver(), System.SCREEN_BRIGHTNESS, i);

[NSTG] What code toggles the glowlight on/off?

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.