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.
Related
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
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.
Hello everyone. My name is tony. First off sorry for being a noob. I should have been learned this. I would like to ask if i could get some help. I want to create a simple calculator that just has a GUI with a grid like layout of clickable buttons at the lower-left-hand side of the activity that has the value 0-9,addition, subtraction,
multiplication,division,decimal, percentage,calculate,clear and clear all . I would like a Text-view above the buttons to display the values of the buttons when clicked. I also would like the result of the calculation to be in the upper right hand corner of the screen that fades in when the user clicks the calculate button .I have searched around and have looked at lots of source code for calculators but there not really "nooob friendlyy"
Some Logic of what im wanting:
user click numbutton -> button pushes its value to Text-View -> user click numbutton -> button pushes its value to Text-View
->user clicks an operand-> Text-View clears its Text on next numbutton press (but still holding that prior value the user entered)->user clicks another numbutton (if they clicked a numbutton it's value would be set to the text-view) or the calculate button -> calculate the two values using the clicked operand and set it to the TextView Result->TextView Result fades in at the top right hand corner of the activity.
Here is were i get
(1)I'm trying to use int/longs and float/doubles depending if the decimal is in the text view when the user clicks the operand.
if is there, expect and return floats and if not, expect and return int's.
(2)parse commands parseInt().gettext().tostring coverts the int to string and respectively for the other data types correct?Is there some benefit to covering to strings?
Rather is it possible to have this implemented using a switch statement?
tone5992 said:
Hello everyone. My name is tony. First off sorry for being a noob. I should have been learned this. I would like to ask if i could get some help. I want to create a simple calculator that just has a GUI with a grid like layout of clickable buttons at the lower-left-hand side of the activity that has the value 0-9,addition, subtraction,
multiplication,division,decimal, percentage,calculate,clear and clear all . I would like a Text-view above the buttons to display the values of the buttons when clicked. I also would like the result of the calculation to be in the upper right hand corner of the screen that fades in when the user clicks the calculate button .I have searched around and have looked at lots of source code for calculators but there not really "nooob friendlyy"
Some Logic of what im wanting:
user click numbutton -> button pushes its value to Text-View -> user click numbutton -> button pushes its value to Text-View
->user clicks an operand-> Text-View clears its Text on next numbutton press (but still holding that prior value the user entered)->user clicks another numbutton (if they clicked a numbutton it's value would be set to the text-view) or the calculate button -> calculate the two values using the clicked operand and set it to the TextView Result->TextView Result fades in at the top right hand corner of the activity.
Here is were i get
(1)I'm trying to use int/longs and float/doubles depending if the decimal is in the text view when the user clicks the operand.
if is there, expect and return floats and if not, expect and return int's.
(2)parse commands parseInt().gettext().tostring coverts the int to string and respectively for the other data types correct?Is there some benefit to covering to strings?
Rather is it possible to have this implemented using a switch statement?
Click to expand...
Click to collapse
You should use Double.parseDouble method
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);
so, I was googling around a bit, a few days ago, and found out you can control the torch (and other leds) from the command line, or a bash script.
Prerequisites
root (magisk or superSU)
FX file manager or Termux
Text editor
Instructions
Create a file in a directory of your choice with a '.sh' extension
Add the following code to the file:
Code:
su -c 'echo 255 > /sys/class/leds/torch/brightness'
Run the shell script in termux (cd to the directory and run it) or run it using FX, it will ask for root access if you haven't already granted it
Your torch is now on!
To turn it off create another file with
Code:
su -c 'echo 0 > /sys/class/leds/torch/brightness'
in it
Tested on an Honor 9 and P10+
If you have dual tone flash, yo may find different values cause either led to come on, for me, '255' is the yellow flash and '1' is the white flash
For a bit more messing around, cd to the '/sys/class/leds' directory, you will see a few more directories for other LEDs on your device, controlling them is exactly the same as the torch!
Works for me, thanks a bunch dude
EDIT: on honor 7x/Huawei mate se
Thank you so much for this but I found in my own experience, and from comments I saw where this has been shared, that a bash script perhaps wasn't the most effective to have to run each time so I thought of implementing this to Tasker, create a "pseudo toggle" and allocate it to a quick setting tile. The algorithm is:
Code:
If flashlightStatus = TRUE then
Run shell command: su -c 'echo 0 /sys/class/leds/torch/brightness'
Set variable flashlightStatus to FALSE
Else
Run shell command: su -c 'echo 3 /sys/class/leds/torch/brightness'
Set variable flashlightStatus to TRUE
End If
I set it up this way because if you've never set the variable before (or if it clears on reboot or something) then it won't equal true and would still enable. Also, when I set the brightness to 255 the torch had a slight yellow tint so upon further reading, despite that 255 should be full brightness, apparently max brightness is 3 and is a white light (this seems to disable automatically after around 750ms however). Hope this will help those who are still without a torch on treble GSIs.
P.S. I also set up a quick profile that if the flashlight status variable = true then to wait 750ms and check if still true then change to false and turn off the torch; this would reset to compensate for the OS turning the torch off automatically but Tasker still thinking it was on. I'm not sure how necessary this is or whether it's overkill or not.
beejkitsune said:
Thank you so much for this but I found in my own experience, and from comments I saw where this has been shared, that a bash script perhaps wasn't the most effective to have to run each time so I thought of implementing this to Tasker, create a "pseudo toggle" and allocate it to a quick setting tile. The algorithm is:
Code:
If flashlightStatus = TRUE then
Run shell command: su -c 'echo 0 /sys/class/leds/torch/brightness'
Set variable flashlightStatus to FALSE
Else
Run shell command: su -c 'echo 3 /sys/class/leds/torch/brightness'
Set variable flashlightStatus to TRUE
End If
I set it up this way because if you've never set the variable before (or if it clears on reboot or something) then it won't equal true and would still enable. Also, when I set the brightness to 255 the torch had a slight yellow tint so upon further reading, despite that 255 should be full brightness, apparently max brightness is 3 and is a white light (this seems to disable automatically after around 750ms however). Hope this will help those who are still without a torch on treble GSIs.
P.S. I also set up a quick profile that if the flashlight status variable = true then to wait 750ms and check if still true then change to false and turn off the torch; this would reset to compensate for the OS turning the torch off automatically but Tasker still thinking it was on. I'm not sure how necessary this is or whether it's overkill or not.
Click to expand...
Click to collapse
mind if i improve this?
Code:
su -c 'if grep -q 1 /sys/class/leds/torch/brightness; then echo 0 > /sys/class/leds/torch/brightness; else echo 1 > /sys/class/leds/torch/brightness; fi'
-- obviously you can change the 1 to whatever you want
that is the code i'm using, prevents the use of an unnecessary variable, so is faster, and will use less resources, plus its pretty much fail safe, since it reads the current state of the torch to determine if its on or off, so if something else sets it to a state it still works, if something else set you variable externally then the torch becomes messed up until a reboot.
plus, im assuming that variable is a tasker thing? not everyone will use tasker, so eliminating the variable all together makes it work on any app that can add custom quick settings tiles
ambitiousButRubbish said:
mind if i improve this?
Code:
su -c 'if grep -q 1 /sys/class/leds/torch/brightness; then echo 0 > /sys/class/leds/torch/brightness; else echo 1 > /sys/class/leds/torch/brightness; fi'
-- obviously you can change the 1 to whatever you want
that is the code i'm using, prevents the use of an unnecessary variable, so is faster, and will use less resources, plus its pretty much fail safe, since it reads the current state of the torch to determine if its on or off, so if something else sets it to a state it still works, if something else set you variable externally then the torch becomes messed up until a reboot.
plus, im assuming that variable is a tasker thing? not everyone will use tasker, so eliminating the variable all together makes it work on any app that can add custom quick settings tiles
Click to expand...
Click to collapse
Yes, the variable is a Tasker thing so I'm glad there is a solution that wouldn't rely on it. Thanks for the upgrade and I've already switched out my Tasker profile for this. Doesn't seem any quicker or anything but more simple!