---
parrotgeek1 said:
don't have this device, but could someone try decompilng framework-res.apk and go to res/values/config.xml and add these
Code:
<!-- Is the notification LED intrusive? Used to decide if there should be a disable option -->
<bool name="config_intrusiveNotificationLed">true</bool>
<!-- Is the battery LED intrusive? Used to decide if there should be a disable option -->
<bool name="config_intrusiveBatteryLed">true</bool>
<!-- Does the battery LED support multiple colors? Used to decide if the user can change the colors -->
<bool name="config_multiColorBatteryLed">false</bool>
<!-- Default color for notification LED is white. -->
<color name="config_defaultNotificationColor">#ffffffff</color>
Of course you can change config_defaultNotificationColor to any html color in lowercase, but start with white for testing.
Then download lights.shamu.so from aosp (one that supports notifications afaict)
https://android.googlesource.com/device/moto/shamu/+archive/master/liblight.tar.gz extract the tgz
and put the .so in /system/lib/hw (replace the old one)
then recompile framework-res DON'T SIGN IT! or use a kitchen and reflash
reboot go into notification settings and turn the lights on
it COULD also enable the green battery charging led natively, idk
Click to expand...
Click to collapse
Didn't work... I see the option for "Pulse Notification Light" and it's enabled but it doesn't light up when I try to text myself and receive the message with the screen off.
1. There is no config.xml.
2. I modified the bools in bools.xml and the color in colors.xml (no modification needed for colors).
parrotgeek1 said:
don't have this device, but could someone try decompilng framework-res.apk and go to res/values/config.xml and add these
Code:
<!-- Is the notification LED intrusive? Used to decide if there should be a disable option -->
<bool name="config_intrusiveNotificationLed">true</bool>
<!-- Is the battery LED intrusive? Used to decide if there should be a disable option -->
<bool name="config_intrusiveBatteryLed">true</bool>
<!-- Does the battery LED support multiple colors? Used to decide if the user can change the colors -->
<bool name="config_multiColorBatteryLed">false</bool>
<!-- Default color for notification LED is white. -->
<color name="config_defaultNotificationColor">#ffffffff</color>
Of course you can change config_defaultNotificationColor to any html color in lowercase, but start with white for testing.
Then download lights.shamu.so from aosp (one that supports notifications afaict)
https://android.googlesource.com/device/moto/shamu/+archive/master/liblight.tar.gz extract the tgz
and put the .so in /system/lib/hw (replace the old one)
then recompile framework-res DON'T SIGN IT! or use a kitchen and reflash
reboot go into notification settings and turn the lights on
it COULD also enable the green battery charging led natively, idk
Click to expand...
Click to collapse
Hey so I tried by baking it into my AOSP build. ( config_multiColorBatteryLed is not in the XSD so i did not include that) Nothing so far. Good thought! Im going to keep looking, at least I was able to add allow All Rotation to my build .
There is no ledtrig heartbeat trigger included and stock kernel does not support loading modules
.
parrotgeek1 said:
Please elaborate.... what's a heartbeat trigger
Click to expand...
Click to collapse
Well to put simply, it's the method that causes the LED's to flash like a heartbeat. (From what I can remember).
ie. OFF - - - ON OFF ON OFF - - - ON OFF ON OFF (so on and so forth).
The way Linux led works in nutshell as i understand it from my quick research is either setting brightness level manually (slow and unreoiable, better to be done at low level) or setting max brightness and setting appropriate trigger kernel module, e.g. set trigger to none to disable or mmc0 to blink to indicate card write activity and so on, ledtrig_heartbeat used to pulse the led and it is not an option in our triggers in nexus 6 (not in kernel) and without modules support we can not load it.
So just enabling led string would not be enough to get pulse notifications. Waiting for custom kernels.
Take a look http://fabiobaltieri.com/2011/09/21/linux-led-subsystem/
So, its working for me. What I did was just used light flow. I enabled root mode, then I enabled run every command as root, then I enabled direct mode. Then I had to choose the correct led for it to use in the other menu and when I ran the test it came on.
Xileforce said:
So, its working for me. What I did was just used light flow. I enabled root mode, then I enabled run every command as root, then I enabled direct mode. Then I had to choose the correct led for it to use in the other menu and when I ran the test it came on.
Click to expand...
Click to collapse
I believe the goal here is to have led notifications natively, without an app running in the background constantly.
Roger that, sorry wasn't sure, figured I would share just to be safe
The source is available, why not just compile a kernel with module support?
Random mutterings...
Note: I don't have a personal build environment set up at the moment, so it's really difficult for me to check these things properly.
# should already be set
CONFIG_LEDS_QPNP=y
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
Using these, it's already possible to, for example, activate a charging LED. (echo battery-charging-or-full > /sys/class/leds/charging/trigger) Where is the kernel support for those charging related triggers? Not finding it in drivers/leds/trigger, but it might be specific to a charging chip? No build environment means no grepping code for the strings...
# not set, but why not? does QPNP not support it?
#CONFIG_LEDS_TRIGGER_TIMER is not set
A "timer" trigger is one of the methods to create a blinking LED. (not heartbeat) the ONESHOT might also be useful. FYI, the heartbeat trigger is documented in the kernel as:
This allows LEDs to be controlled by a CPU load average. The flash frequency is a hyperbolic function of the 1-minute load average.
Click to expand...
Click to collapse
How are the triggers configured for hammerhead or perhaps for a motoX device, and how is that different from shamu? As well as kernel support, there needs to be liblights.so support for the kernel parameters, JNI support, and JAVA support. Some or all of these might already exist. Not sure yet.
The "three" LED's (red/green/blue) in shamu are configured as GPIO devices (see apq8084-shamu.dtsi.) In leds-qpnp.c, blink_store(), an ID of 8 (GPIO) will result in an error. Does that matter? If they are GPIO devices, why not configure them with leds-gpio instead of leds-qpnp?
In contrast, the "charging" LED in shamu (defined in apq8084-moto-common.dtsi, I think) appears to set up differently (MPP?) and should support blink types (that does work, actually.)
...
Why is the "charging" LED handled so differently from the 3 color LED? If I'm going to mess with the LED's, I'm going to get them blinking the way they should, dammit.
What is the disconnect between the kernel (which, at the very least, supports a charging LED properly) and the rest of android? It's been several years (i9300 -- galaxy S3?) since I've messed with the LED code in android...
Odd: there's no source for liblights.so in the shamu code device tree (just a compiled lib), but there IS source for liblights for other platforms (if there's any lib at all.) Not sure I've ever seen the LED stuff being considered a proprietary blob (especially when it's kernel driven and the kernel source is all intact.)
You know your losing your mind when you start excessively replying to yourself in forum threads. It's worse when you have to re-learn something you were very familiar with just a few years ago.
android notification system uses LightsService for various LED related stuff. (This includes the screen lighting.) LightsService relies on some jni code (com_android_server_lights_LightsService.cpp) to interface to the liblights library. The JNI module is tiny, and really doesn't need to be mucked with. However, it's a really nice place to put logging code. The JNI only has three methods: init_native(), finalize_native(), and setLight_native().
The init is called for each type of LED "device". they are backlight, keyboard, buttons, battery, notifications, attention, bluetooth and wifi. Add logging code here to see which ones are returning a valid pointer, and which ones aren't. (I'm guessing that only backlight is being returned. I hope I'm wrong, but if I'm not, then lights.shamu.so will have to be re-written from scratch to support the other device types.)
The only other interesting place will be in setLightnative(). This takes a crapload of parameters, which are all packed down to a light device pointer and a "state" structure. These are passed to the native (lights.shamu.so) code for processing. Adding logging here might be useful. It also might not be (depending on if the damn light initializes or not.)
Why does this all seem so damn familiar to me? (because I've done it before and managed to forget most of it.) (hopefully, by typing all this, I'll be able to find it again in the future via google searches.)
I was getting bored, so figured I'd reply to myself. Again.
It appears that lights.shamu.so is the base of the problem. (There might be other issues, of course, but one of the ways to dig these things out is to start at the lowest level and work your way up...)
Kernel: has support
sysfs supports (if somewhat limited)
The next layer is liblights.so (or, in this case, lights.shamu.so.) The ONLY "light" that this lib seems to support is "backlight." The following all give errors: "keyboard", "buttons", "battery", "notifications", "attention", "bluetooth" and "wifi"
I am curious what the "battery" light type is. Is that designed to be the charging LED, or have some other purpose within android? Will need to check that out...
Anyway, I'll whip up a "lights.shamu.so" replacement and see what happens with that..
hrmm.. I've never seen this before:
Code:
E/HAL ( 957): load: module=/system/lib/hw/lights.shamu.so
E/HAL ( 957): dlopen failed: empty/missing DT_HASH in "lights.shamu.so" (built with --hash-style=gnu?)
Of course, the obvious thing would be to edit device/moto/shamu/liblight/Android.mk and add "LOCAL_LDFLAGS := --hash-style=both", but that's giving me a compiler error:
Code:
arm-linux-androideabi-g++: error: unrecognized command line option '--hash-style=both'
Now, why is an LD flag being passed to the c++ compiler and not to the linker? For that matter, why is it using g++ instead of gcc? hmm... This should be easier than this.
I figured I should thank you for doing all these
garyd9 said:
hrmm.. I've never seen this before:
Code:
E/HAL ( 957): load: module=/system/lib/hw/lights.shamu.so
E/HAL ( 957): dlopen failed: empty/missing DT_HASH in "lights.shamu.so" (built with --hash-style=gnu?)
Of course, the obvious thing would be to edit device/moto/shamu/liblight/Android.mk and add "LOCAL_LDFLAGS := --hash-style=both", but that's giving me a compiler error:
Code:
arm-linux-androideabi-g++: error: unrecognized command line option '--hash-style=both'
Now, why is an LD flag being passed to the c++ compiler and not to the linker? For that matter, why is it using g++ instead of gcc? hmm... This should be easier than this.
Click to expand...
Click to collapse
I believe in you Gary! Seriously though thanks for taking the time to work on this.
I appreciate the support, but I hope everyone remembers that I have a full time job that takes priority. That generally means that most of my android "fun" work gets deferred during the working week.
The task will get done, but please be patient...
Take care
Gary
We definitely appreciate everything you and the other devs do! I'm very much enjoying the AOSP Email! I did not want to use Gmail for my work email. I know it might have some benefits but I just needed the basic email app so that was very much appreciated!
Related
Ok kernel guys, since all the custom kernels seem like they come with dimmed lights by default, how can I change them to stock through a reboot? Mine look terrible when I edit the /currents.txt below 14. I added a line to /init.d without success... Tia
ducky1131 said:
Ok kernel guys, since all the custom kernels seem like they come with dimmed lights by default, how can I change them to stock through a reboot? Mine look terrible when I edit the /currents.txt below 14. I added a line to /init.d without success... Tia
Click to expand...
Click to collapse
Can you post up the actual methods you have followed?
As far as I understood, these can be controlled through the sysfs area.
Some of the custom kernels might have an application or script installed which on boot echo's the dimmed value to the sysfs area. Some other custom kernels might hard code the dimmed value for the sysfs area into the kernel source files when they compile, but they should still be adjustable.
The method of echo'n a value to the sysfs file is going to be the same whether adjusting screen brightness, capactivite key brightness, toggling their power on/off, or making the same adjustments with the LEDs. Their control files are all held in the sysfs space.
Gave an example or two previously here: http://forum.xda-developers.com/showpost.php?p=18171890&postcount=8
Hope that helps!
This post I made shows what I have tried with no success. http://vaelek.com/index.php?/topic/1952-couple-of-issues-with-rc2/
ducky1131 said:
This post I made shows what I have tried with no success. http://vaelek.com/index.php?/topic/1952-couple-of-issues-with-rc2/
Click to expand...
Click to collapse
In your post you indicate you already know how to change them. I have no idea what Vaelpak or whatever is. What method have you used to make changes to the brightness?
If you're using the approach I'm thinking of, echo'n values to sysfs, the two methods I listed above are probably the most common methods of making the values stick:
a script which runs on boot
or an android app which runs on boot
hope that helps!
Hello xda !
(first, excuse me for my bad english, my first language is french)
You know, the project "freexperia" provide CyanogenMod on xperia phones.
One feature of this phone is that it has a multicolored LED bar. 3 group led with three primary color.
You probably know the application "Illumination bar". But it interacts with the bar led through an API, written by Sony. (correct me if I'm wrong).
Some ports work. Others do not. It depends on many factors actually.
So I wrote an application, initially for my own personal use. I decided to share with you, to know your opinions and ideas.
The application itself is not very interesting. It can adjust the color of the LED bar.
Well, once the service is launched, it will execute a bash script. In an infinite loop, the script will constantly check if the LCD screen is on or not. If it is, the LED bar lights up with the values you have chosen. Otherwise, it turns off.
The LED bar also check the battery level, if the energy saving option is enabled, and the level will drop to 15% ~ 20% of what you have previously configured.
Simply. This roughly reproduces what happens with a stock ROM. Except that the ROM completely off the led bar after a certain period of inactivity (and reactivate it if you push a ranom button).
Currently, bar LED will remain lit as long as the screen is on. I write a piece of code to add this feature later if that tells you
I now propose to try the application. The root is required because the application will execute a bash script (I told you earlier).
No need to patch or enter recovery mode. Just install an APK. Link in the description.
Now I count on your opinion. Hope you like it.
Thank you in advance!
Note: The application is designed to work without any further application to interact with the LED bar. It is for these roms without service "Illumination" this application has been designed. Thank you!
----------------------
Changelog : v1.1
Updated : Preparing for control three colors independently, but not immediately
Updated : Light bar is not updated when the screen is off. But always updated when the screen is on (for battery saving)
Updated : Presets values (Red, Green, Blue, Magenta, Yellow, Cyan, Sony Blue)
Improve performances. But not sure.
Removed : Wake lock permission. Useless, maybe in the future...
Updated : ... wait, I have forgotten the rest ...
thunbs up for developing this app.
Can you make it work on ICS also? I would really like to see it..
does this app allow to choose 3 different colors at the same time? I have been waiting for an app to do this since I have bought XU!
ICS
nice work mon frere but it makes my phone very slow
Good job guy !
I test it and I give my results for battery consumption and if lags are present
evildev said:
thunbs up for developing this app.
Can you make it work on ICS also? I would really like to see it..
Click to expand...
Click to collapse
for the next update, it should not pose too much trouble. Theoretically.
heatseeker_x04 said:
does this app allow to choose 3 different colors at the same time? I have been waiting for an app to do this since I have bought XU!
ICS
Click to expand...
Click to collapse
I'll see what I can do.
dips777 said:
nice work mon frere but it makes my phone very slow
Click to expand...
Click to collapse
Oh. This is weird. Now question is whether this comes from application or another program that is in conflict.
The question is whether "bash" is the source of the problem (this is the process that executes the main script).
For that, go in the developer options, and activate "Show CPU usage". It should display an overlay. And tell me if the process "bash" is top of the list.
Info4Geek said:
Good job guy !
I test it and I give my results for battery consumption and if lags are present
Click to expand...
Click to collapse
Thank you !
Consumption should still increase. Bar LED consumes a significant portion of energy.
Do not hesitate to lower the light levels in the application. A little less light can save a few minutes.
I am looking particularly off led bar after a certain time when the phone screen on.
-------------------------------------
If any questions, or ideas, do not hesitate.
No lags on my phone with your app !
For battery consumption, not especially a significant decrease for battery
I'm on CM10.1
Its sencond on the list.
Would really like it if you could modify the app.........like add preset colours and make the light work like exactly in the stock rom(switch off after sometime....turn on when press buttons). :laugh:
Hello there ! I developed an update!
More than a week without news. I know.
I added some features and optimized the script (a feature coming soon!).
I added a preset list of basic colors for the light bar. Of course you can always put the values you want. It does not change and will never change.
The script has been optimized (especially when the screen is off) and now I'm working on the option requested to independently apply a color on a single LED.
You will understand: 3 different color for different LEDs present on the bar! But it will not for now.
Soon.
The update is available in the first post.
Can You chose color for single LED? Any new information?
marcinwolosz said:
Can You chose color for single LED? Any new information?
Click to expand...
Click to collapse
It is possible. In the next update, you can choose a color separately from the others.
It will not be available immediately unfortunately. This application is not really my first priority in truth ...
Tiwy57 said:
It is possible. In the next update, you can choose a color separately from the others.
It will not be available immediately unfortunately. This application is not really my first priority in truth ...
Click to expand...
Click to collapse
Thanks for answer. I'm waiting for update
The nexus 6 has two LED (enumerated as 4 devices - one charging, one red, one blue, one green) devices. This thread is to discuss getting them working with android properly.
Issues:
The LED devices, as implemented by moto (or google) don't contain sysfs support for flashing (blinking.) They are seem to support kernel triggers (limited) and brightness controls.
However, at least as seen by the triggers for the charging LED, there is some back-end support for flashing the LED. (I'm not sure, as I can't find the source for the "blink while charging" trigger.)
The triggers for the 3 color LED's are all steady on (or reactionary) triggers.
The shared lib commonly called liblights.so (called lights.shamu.so on the nexus 6) seems to be crippled and only allows controlling the LCD backlight. BATTERY, NOTIFICATION and ATTENTION led's aren't supported. Moto/google doesn't supply the source for lights.shamu.so (which was originally compiled under a different name... lights.apq8084.so)
However, liblights.so is trivial to re-write (once you realize that the google pre-load of android uses sysv hashes and not gnu hashes), and I've already done so to support as much as the sysfs kernel support exposes by default. (charging led attached to BATTERY, red/blue/green LED's attached to ATTENTION/NOTIFICATION.)
(I'll attach source later when I'm home. I can't keep personal android related source at work due to potential conflicts of interest.)
The remaining issue, as mentioned, is that nothing is exposed in sysfs to allow the LED's to flash.
Edit: I'll be asking a moderator to move some of my posts in another section to this thread (for completeness.)
a little something...
The attached file (lights.shamu.so.zip) is a zip file containing only a replacement .so file. (No, you can't install this in recovery. This is just a single file that's been zip'd so xda will accept it as an attachment.)
(warning: I'm purposely being vague in my directions. Don't mess with this unless you know what you're doing!!!)
unzip the file, and manually copy the .so file into /system/lib/hw (overwriting the existing one) and setting the permissions (644) to match the previous file. Reboot (you're phone will likely lock up after replacing the file, but you can still reboot from within adb.)
After the reboot, adb back into the phone and set the ownership of /sys/class/leds/charging/brightness to system.system. Don't reboot after that (as the ownership will revert after a reboot until after kernel ramdisks are updated.) Now unplug your device from any USB cord used with adb.
Until the next time your phone reboots, you'll have a functional charging/battery LED (controlled by android - not by the kernel.)
I've left the notification LED disabled in the attached .so file on purpose (because it's steady-on - not blinking.)
Gary
As an additional note, a repacked kernel init.rc script (or some other mechanism that runs a command line at startup) can write into /sys/class/leds/charging/trigger to enable the charging LED. This doesn't require any special kernel support or shared libs... It appears to work fine "out of the box" with the standard kernel. The following are listed as supported triggers:
none
usb-online
max170xx_battery-online
wireless-online
rfkill0
mmc0
backlight
default-on
battery-charging-or-full
battery-charging
battery-full
battery-charging-blink-full-solid
dc-online
rfkill1
rfkill2
Of these, I've only played with a couple battery related (they seem to work after a short delay), and mmc0 (which is like a disk activity light.) (Please don't ask me what each one of these does. It's more fun to try them out yourself.)
How to play? Here's an example:
Code:
adb shell
su
echo battery-charging-blink-full-solid > /sys/class/leds/charging/trigger
(The above example, as far as I can tell, does the obvious: the green LED blinks while it's charging and goes solid when the battery is charged.)
By the way... if someone decides they want to take some of this information and publish an app that basically does nothing but write to sysfs files, that's fine. However, please make it a free app.
Why? Because this community is about development and sharing ideas freely. Profiteering from those ideas (especially when they are as trivial as obvious sysfs writes) is despicable, and really goes against what I feel xda-developers is about.
God, I HATE when I make stupid mistakes. I'm throwing together a kernel (to test some ideas with the LEDs) and forgot to change the fstab (so it doesn't force encrypt.) I didn't even install the "new" kernel, but just did a "fastboot boot kernel.img" (to see if it would boot.)
It booted.... and now it's encrypting my phone. (This is the bad thing. Encryption is one-way.. once your encrypted, the only way to decrypt is to basically factory reset the device.)
...and now for the "rookie mistake": I never bothered to make a backup of my userdata partitions. DUH!
(Actually, the reason I didn't back it up is that I'm running out of space on the phone.)
Damn.
Damn, I just realized I don't have mod ability in this dev discussion section. If a moderator comes by, can you please clean up the thread?
Anyway...
As I'm working my way to defeat android's encryption, I'll report on what I've managed...
The only thing "blocking" this project from being successful and done is that I can't get the color LED's to blink on their own. I've tried adding a timer trigger to the LED code (LED_TRIGGER_TIMER or something) and that works.. kind of: I push "timer" into the trigger file, and then I can write to "delay_on" and "delay_off" files that magically appear in the sysfs.
The problem is that those are kernel timers, and not hardware timers. In other words, the kernel has to wake up the device to turn the LED on or off. So, if the delay on/off are set to 1000ms each, that likely means that the kernel will wake the device out of deep sleep every second to change the LED brightness. I suspect that would drain a battery...
On the other hand, I simply can't believe that there'd be any LED in any android device that doesn't have some kind of blinking control baked into the hardware. The problem is finding where it's baked in, as moto/google apparently doesn't want us to know... :laugh:
I believe hardware timers are available here: https://github.com/imoseyon/leanKernel-shamu/blob/lk-lp/drivers/leds/leds-qpnp.c
I don't have time to dig into the code in detail but it coulb be tricky to enable them.
EDIT: nope i don't think hardware supports it
Yeah I haven't seen anything hardware side either.
I'm trying to unravel the mess of device trees.. Some random questions (to no one in particular... more just "typing out loud.")
It appears that the RGB LED's are GPIO controlled. However, moto/google isn't using leds-gpio, but instead they're using a GPIO mode within leds-qpnp.
Does leds-qpnp offer any functionality over leds-gpio? It appears that leds-qpnp treats GPIO based LED's in the most simple form.
Could the led's be controlled via leds-gpio instead of leds-qpnp? Would/Could that offer additional functionality (if possible)?
What other devices use leds-gpio? (hammerhead?) Do those devices support flashing LED's?
It's very possible that the hardware DOES support some type of blinking mode, but that moto never bothered to implement it as it was never needed.
garyd9 said:
I'm trying to unravel the mess of device trees..
Click to expand...
Click to collapse
hammerhead uses rgb_pwm (not gpio, etc.)
leds-gpio.c isn't going to be any help without more knowledge.
Unless there's a gpio pin that allows hardware control of the LED flashing, and I can somehow discover that, the only "blinking" that the RGB LED will be doing will be "soft blink." (software turns it on, waits for a timer, turns it off, waits for a timer, etc.)
Which would be worse on an android device's battery that's idle/sleeping: a constant on LED, or a kernel that wakes up the device every couple of seconds to change the state of the LED?
(While charging, this doesn't matter because the device doesn't actually go into deep sleep while charging.)
ah man I'm trying to remember what I did to probe for support for hardware accelerated blinking. I made some tweaks to arch/arm/boot/dts/apq8084-shamu/apq8084-shamu.dtsi to enable various different modes, but each time I tried to enable a mode other than QPNP_ID_LED_GPIO (default), the phone doesn't boot.
Imoseyon said:
ah man I'm trying to remember what I did to probe for support for hardware accelerated blinking. I made some tweaks to arch/arm/boot/dts/apq8084-shamu/apq8084-shamu.dtsi to enable various different modes, but each time I tried to enable a mode other than QPNP_ID_LED_GPIO (default), the phone doesn't boot.
Click to expand...
Click to collapse
I'm starting to think about reversing things: The charging LED has hardware blinking support, but the RGB doesn't... so I could just make the RGB cluster be the "charging LED" (with soft blinking) and the brighter green LED be the notification LED....
Extra "battery drain" used while software blinking wouldn't actually mean anything as the unit is being charged (and doesn't go into deep sleep while charging anyway.)
Of course, we'd then be forced to only GREEN notification lights. On the other hand, a single color LED notification with 0 excess battery drain is better than none at all. (My last phone was an HTC M8, and that only had orange and green.)
In fact, doing that, I could have some fun with the RGB LED while charging by changing the LED color based on the charge percentage. (I just need to figure out how to get the current battery percentage into liblights.so.)
Best of all, it's Friday, so I'll have some time to work on it over the weekend.
Sounds like fun.
notes:
liblights can access the current charge level (1-100) from sysfs /sys/class/power_supply/battery/capacity, and the charge status (Full/Charging) from /sys/class/power_supply/battery/status
edit for more notes:
For the 3 sysfs nodes representing the RGB LED, the "brightness" setting doesn't seem to have any impact. A brightness of "1" looks the same to me as a brightness of "20" (which is the max.) I'll have to retest that in a dark room.
Just a status update... I didn't get to work on thing as much as I'd wanted over the weekend. I did spend some time looking at the charging LED related code. It's attached to a "MPP" (multi-purpose pin) in the device. There's a MPP mode in the kernel code (leds-qpnp) for supporting hardware blinking, but it relies on using a PWM channel to control it.
I'm not familiar enough to PWM channels to know if I can just just assign one and it'll work, or if it requires hardware wiring in order to work. Obviously, if it requires hardware wiring that doesn't exist, there's nothing I can do there. I'd rather I had some idea what I was doing before I just randomly assigned a number as a pwm channel and booted it.
If anyone has a clue about this, I'd appreciate them chiming in. Despite the "developers only" tag on the subforum, that does NOT mean "recognized developers only." It means anyone who develops/engineers/creates/etc.
Just thought I'd share something I found while cruising T&A.
By @registered-user
http://forum.xda-developers.com/nexus-6/themes-apps/app-charging-led-mode-changer-t2963847
i took these screenshots using Tricksters LED Control settings.
When using
Code:
battery-charging-blink-full-solid
i get the light to blink while charging...
the thread has been cleaned so I have opened it up.
Please keep in mind that this is a dev discussion and as long as the post is related the discussion it is OK.
As with any thread on XDA if you think a post is in the wrong place then REPORT IT!!!!! DO NOT REPLY!!!!
@garyd9 you should PM Sevitus to find if Mod permissions are available
I have found out what some of the triggers is doing but the list is not complete yet.
none (default, LED does nothing)
usb-online (lights up when USB connected)
max170xx_battery-online
wireless-online
rfkill0 (Bluetooth enabled)
mmc0 (I/O triggered, lights when mmc0 is in use) Storage access
backlight (Backlight on the AMOLED display)
default-on (always on)
battery-charging-or-full (full time ON LED when charging or charged)
battery-charging (full time ON LED when charging)
battery-full (full time ON LED when charged)
battery-charging-blink-full-solid (blinks until charged)
dc-online
rfkill1
rfkill2
I found what the rfkill0 is doing on this page: https://github.com/ev3dev/ev3dev/wiki/Using-the-LEDs and the others is from this one: http://andrux-and-me.blogspot.com/2014/11/moto-g-play-with-led.html
IceXcube84 said:
I have found out what some of the triggers is doing but the list is not complete yet.
Click to expand...
Click to collapse
..and? I don't understand how this contributes to the development discussion concerning adding notification LED support with hardware blinking to the android device.
Are you suggesting that one of existing kernel triggers has code for enabling hardware blinking? I know that the "blink on charge" trigger uses software blinking (and that's discussed earlier.) However, I didn't dig into some of the other triggers (that are in modules outside of kernel/drivers/led/triggers)
Even if the LED lights have to be swapped if it can't be figured out is still ok.
Can we get a TWRP installable zip file to enable the charging + notification LED in CM12 or even stock image? The notification LED (even if swapped with charging LED) seriously needs to be added to CM12 builds or even stock images.
The night light feature on my Pixel 3a doesn't go low enough for my preference, so I'm trying to override it.
Setting the secure setting manually for "night_display_color_temperature" only works whilst transitioning between states, as soon as it has transitioned, it no longer has an effect.
I believe this is due to the "config_nightDisplayColorTemperatureMin" flag (as referenced here) being higher than the value set, so I wanted to know if there was a way to override these flag values after the system has been built. Normally you would use overlays, but since I don't have the source code, that isn't going to work.
If anyone knows where the config.xml options are compiled to, or a way to override them, that would be really helpful.
Thanks in advance
So apparently the 1 III suffers from the same issues as its Sony Predecessors... The Flashlight is very bright when you use it as camera flash, but when you turn on the flashlight, its artifically throttled to idk, prevent overheating?
So for the older Xperias there were ways to modify flashlight configs and librarys. However, I havent found a way to edit the current parameter for the flashlight on the 1 III. For the 5 II the GodlyTorch App seemed to work, according to a report in https://forum.xda-developers.com/t/...ness-fix-torch-light-not-photo-flash.4203293/, but that doesnt want to work on my 1 III (I have Root)
Now the question: Can someone find the parameters to increase Flashlight LED Current via Magisk Module, XPosed/LSPosed Module or manual edit? I'd be even willing to donate to a kind developer who builds a usable flashlight mod for the 1 III.
Thanks in advance.
When flashlight is on and your device is rooted, you can change the value of
Code:
/sys/class/leds/led:torch_0/brightness
/sys/class/leds/led:torch_3/brightness
(There are two flash LEDs)
The max value you can set is given by the max_brightness file in the same directory.
I didn't find a way (yet) to apply this by default, you have to have the flashlight running in order to change its brightness that way.
However, I do warn you that I am not responsible in any way if using your LED at full power causes damage to your device.
MK73DS said:
When flashlight is on and your device is rooted, you can change the value of
Code:
/sys/class/leds/led:torch_0/brightness
/sys/class/leds/led:torch_3/brightness
(There are two flash LEDs)
The max value you can set is given by the max_brightness file in the same directory.
I didn't find a way (yet) to apply this by default, you have to have the flashlight running in order to change its brightness that way.
However, I do warn you that I am not responsible in any way if using your LED at full power causes damage to your device.
Click to expand...
Click to collapse
Thanks for this info, working fine for me!
I played a bit around with this and tested the brightness values with 150; working fine in terms of short term heat development.
Edit 2: After a few days I start to notice a very slight discoloration of the diffusor with a value of 150. Its not affecting anything and barely visible, but I'd recommend to go lower than 150, because I suspect the LED may get too warm for the diffusor. I changed the guide to use 30 for now (which equals double the brightness compared to stock), please test your values for yourself, its probably better to not exaggerate it.
Make sure you type in the values right! Too high values and the LED Diffusor may melt, or the LED might die. Do this modification at your own risk, no matter at which brightness you target! I am not responsible for side effects resulting from the mod.
With Terminal Shortcut Pro and assigned Root Priviliges I made myself a Home Screen Icon that will boost the values for me in the current "Torch session" once the LED is turned on before. Other terminal emulator apps will work too.
In the Shortcut I set Run with Root and used the following command
Code:
echo 30 >> /sys/class/leds/led:torch_0/brightness && echo 30 >> /sys/class/leds/led:torch_3/brightness
Basically just a command that writes the 30 brightness value to the 2 files.
If someone can find a terminal command that turns on the flash in the first place, we could combine the commands to potentially make a simple but working replacement quick settings for the torch.
Edit: Thanks to the XDA Community and a Tool I was able to recreate the Torch experience with a Quick setting
You need https://play.google.com/store/apps/details?id=com.quinny898.app.customquicksettings
You have to buy the premium in app purchase for 1,29€ to unlock Root Command Running. Then you configure your quick setting (choose the Advanced -> Root Command under Preset) and paste the following script (credits to https://forum.xda-developers.com/t/increasing-torch-power-with-root.3637773/post-73098701, modified by me for 1 III)
Code:
#!/system/bin/sh
toggle=$(cat /sys/class/leds/led:switch_0/brightness)
if [ "$toggle" = "0" ];then
echo 30 > /sys/class/leds/led:torch_0/brightness
echo 30 > /sys/class/leds/led:torch_3/brightness
echo 1 > /sys/class/leds/led:switch_0/brightness
echo "on"
else
echo 0 > /sys/class/leds/led:torch_0/brightness
echo 0 > /sys/class/leds/led:torch_3/brightness
echo 0 > /sys/class/leds/led:switch_0/brightness
echo "off"
fi
Once again, make sure you type in the values right! Too high values and the LED Diffusor may melt, or the LED might die. Do this modification at your own risk, no matter at which brightness you target! I am not responsible side effects resulting from the mod.
Then you get rename the toggle, give it a nice Torch Icon and set the color to grey. It will function like the normal quick setting: Tap once, it turns on, Tap again, turns off. Even works locked.
Good luck and best regards.
If you want to use the Google Assistant Button as a torch toggle and also have Quick Settings Toggle (sadly its always toggled on) i found an app that can do both.
You need:
LSposed/Xposed
Root Shell access (adb shell)
Xposed Edge pro
Busybox for Android NDK (Magisk Module)
XperiaGAButtonRemap (Magisk Module)
Open a cmd or powershell
execute adb shell
execute su
accept root permissions on your phone
execute vi /bin/torch
press the key i
paste the script:
einhuman197 said:
Code:
#!/system/bin/sh
toggle=$(cat /sys/class/leds/led:switch_0/brightness)
if [ "$toggle" = "0" ];then
echo 150 > /sys/class/leds/led:torch_0/brightness
echo 150 > /sys/class/leds/led:torch_3/brightness
echo 1 > /sys/class/leds/led:switch_0/brightness
echo "on"
else
echo 0 > /sys/class/leds/led:torch_0/brightness
echo 0 > /sys/class/leds/led:torch_3/brightness
echo 0 > /sys/class/leds/led:switch_0/brightness
echo "off"
fi
Click to expand...
Click to collapse
press ESC
type :wq and press ENTER
execute chmod +x /bin/torch
Now you can execute /bin/torch as root and it will toggle the torch with higher brightness values.
In Xposed Edge enable "Keys" toggle and open it. Tap on "+ Add" at the bottom, press the Google Assistant Button, it should be recognized as "KEYCODE_PROG_BLUE", then set the action of either click/double click/long press (whatever you prefer as the torch toggle) to execute a Shell command, enter /bin/torch in the input field and enable the "Root access" toggle.
If you want, you can also set other custom things to the Google Assistant button for the other 2 states.
For the quicksettings menu tap on "Quick settings tiles" in the main menu of Xposed Edge and enable the first tile and open the settings for that tile. Set the action, again, to a shell command, input /bin/torch and enable Root Access. You can set the label to "Torch" and choose the Torch icon found in "Built-in icons". As i already said, the toggle will always be turned on for some reason. It just executes a shell command after all.
Good luck
Amazing, thank you everyone.
However, please let me insist that this may damage your phone if you put values too high... trust me. I accidentally put a brightness of 350 instead of 150 while trying the script in a terminal, and a few seconds were enough for the plastic underneath the glass to melt... Thankfully, it is still transparent so I can still use my flashlight, but no doubt it could have done a lot more damage if I let it run for longer. So please, use this with a lot of care (and double check what you write).
That's why in lots of countries, rooting voids your (hardware) warranty, you can do physical damage to your device so again, please be careful. Thankfully, this plastic bit and even the LED underneath are easily replaceable (the plastic bit is separated from the rear glass and the LED is on a separate ribbon cable). However, there don't seem to be a lot of OEM replacement parts for this phone yet.
Seems like a lot of work for little return and added threat of damage to an expensive phone. I agree that the brightness is dimmer than other phones I have had...but I did a test in a completely dark room and it actually is bright enough to find "whatever" you may be looking for. So I can live with it. Maybe Sony will do something to improve it a little?
jaseman said:
Seems like a lot of work for little return and added threat of damage to an expensive phone. I agree that the brightness is dimmer than other phones I have had...but I did a test in a completely dark room and it actually is bright enough to find "whatever" you may be looking for. So I can live with it. Maybe Sony will do something to improve it a little?
Click to expand...
Click to collapse
Sony could definitely improve it. But it seems like they had a history for compareably dim Flashlights.
I edited my explanation post to adapt lower brightness, because 150 as value starts to slightly discolor my diffusor, so I suspect we should run it lower.
MK73DS said:
太棒了，谢谢大家。
但是，请让我坚持，如果您将值设置为高，这可能会损坏您的。......我相信在终端中尝试手机时，我不小心将恢复设置为 350 而不是 150 ，几秒钟就可以让玻璃下面的恢复正常……幸好还是可以的，所以我可以使用我的手电筒，但有疑问，如果我能运行更长时间，它会请小心使用它（并仔细检查你写的内容）。
这就是为什么在国家/地区，root 导致您的许多（硬件）故障，您可能会再次对您的设备造成物理损坏，请小心。值得庆幸的是，塑料钻头甚至下面的 LED 都可以轻松更换（塑料钻头与后玻璃分离，LED 还位于单独的带状电缆上）。
Click to expand...
Click to collapse
darken5404 said:
Click to expand...
Click to collapse
You can't say I didn't warn you!
Indeed flashlight in mark 3 and older xperias is very bad.
I compared it to an iPhone and it's like day and night. Many aspects xperia brand is suffering like front camera, flashlight, no 21:9 pics, missing 4k 60fps recording in main app with stabilization, poor screen brightness, insufficient battery capacity, no any cooling system (especially at this price there should be vapor chamber or any other advanced cooling and not throttling cpu as a solution...), Not to mention regular software apps like Album, email and others :/
MK73DS said:
You can't say I didn't warn you!
Click to expand...
Click to collapse
I got it fixed through sony aftermarket and has ip68,fixed the screen for me by the way
On android 12 after rebooting the function stops working.
So I got to the area of the phone you guys specified, but as of today, the default values are WAY different that what yall found. Let me take a few screen shots
Here is the systems default peramitors. Any idea why they are so different?
Edit- Okay, so extra piece to the puzzle. When torch is off, the brightness file is 0, but when it is on the file is set to 15.
editing the file while the torch is on does nothing.
Edit 2 - Just wanted to note that for those who just want a demonstration of the changes possible, the fallowing app will do just that
Release v1.4.6 · BRoy98/GodlyTorch
Merge pull request #2 from TheDorkKnightRises/patch Fix LED file path for OnePlus One (bacon), proper device names for OP Merge pull request #3 from TheDorkKnightRises/patch Fix default double-...
github.com
this app needs root. Run it as a HTC 10 and it works just fine. However, I would like to recommend NOT going over the half way point. its VERY bright and will probably kill your LED if you do. You have manual control over the brightness. You can add it as a shortcut in the drop down menu of your phone. simply use the standard torch button, and then click the godly torch button to activate whatever preset you gave it.
Edit 3 - setting the brightness in Godly Torch to 50% Intensity sets the brightness to 135. Given that we know damage starts to happen at 150, I set the brightness in Godly to 15% (under the "toggle Intensity" shown in the screen shot), which brings the brightness to a value of 45. Its easily double as bright. I would not recommend going past this point.
I would say by using godly torch as a HTC 10 worked...mind you I double checked the brightness by just hitting the quick toggle and then messing with godly torch. The lower setting is matching just turning on the quick toggle the higher setting is what I'm comfortable with, but idk how long I'm comfortable running it at that brightness.
BlazingKahn35 said:
On android 12 after rebooting the function stops working.
Click to expand...
Click to collapse
For those on stock who use the assistant button :
If it stops working after reboot, copy the binary file to somewhere safe on your sd card, then using XPosed edge just add a long press gesture to your assistant button that recopys the file from your sd card, then sets the permissions again (make sure to check run as root)
cp /sdcard/torch /bin/ | chmod +x /bin/torch