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.
Change the minimum brightness level from usual 10 to 1. It doesn't modify the autobrightness level map so automatic brightness won't be lowered (though it can be easily adjusted on CM11).
This is so far exactly the same as GravityBox offers (modifying 'config_screenBrightnessSettingMinimum').
But Minimum Brightness offers one unique feature - it also modifies the lower brightness levels in MX Player (free/paid). Because no matter whatever you use manual or auto brightness, MX Player always uses minimum brightness of 0.05 (12/255, 19/255, 27/255, 36/255...). To actually lower the brightness, you would have to turn off brightness control in MX Player or use one of many 'overlay filter brightness app'.
So Minimum Brightness module retains the same quadratic function for brightness levels but includes lower values (1/255, 4/255, 9/255, 16/255, 25/255...).
Minimum Brightness uses value 1/255 which might not be suitable for every display (meaning LCD) but it suits perfectly my Super AMOLED screens (Galaxy S5 / Galaxy Tab S 8.4) and watching videos at night is still enjoyable.
There are many excellent auto brightness apps (Lux, Darker etc) that can use overlay filters to lower brightness even more so it's up to everyone to try and decide.
This module has been merged into new module http://forum.xda-developers.com/xposed/modules/mod-xposed-tweaks-cm-t3279109. Please check that module for any future updates.
Hello! Thanks for the mod, I will test
Works very nice on Xperia Z2, however minimum brightness is absolute darkness Could you please add an option to define minimum brightness value?
_mysiak_ said:
Works very nice on Xperia Z2, however minimum brightness is absolute darkness Could you please add an option to define minimum brightness value?
Click to expand...
Click to collapse
The situation is the same on my Xperia SP. When I set the brightness to miniumum the screen is totally black, also when the backlight decreases after 10 seconds screen gets black.
Hi! Tried min brightness but when screen is set to the lowest level, I get a white screen after locking the phone.
Sent from my DIAMOND D1 using XDA Free mobile app
Really great tweak!! I'm noobie in Android enviroment with my new Elephone P3000S and the lowest screen brightness is to high for me so your tweak is very usefull.
I also have the issue that the lowest brightness level sets the screen completly black and I have been scared for 1 hour truing to solve a completely black, touching all buttons but the phone didn't "wake up". Finally, pressing power buttom + volumen up + home soft key it has worked :angel:
So it would be very important to prevent black screen by allowing the user to set the minimun level.
Thanks!
Hey, I know making GUI is a pain in the ass so can you please make alternative version with minimum brightness set to 2? That will satisfy most of people complaining here. Your app is currently the only dimmer working on lollipop.
Dri0m said:
Hey, I know making GUI is a pain in the ass so can you please make alternative version with minimum brightness set to 2? That will satisfy most of people complaining here. Your app is currently the only dimmer working on lollipop.
Click to expand...
Click to collapse
I will have a new device soon so that could make me change my mind about lowest value and UI.
@Dri0m
In the first post you can find archive containing multiple versions of module with different low values.
How to disable this module...?
I installed this module last night, enabled it in Xposed Framework, but did nothing with it. Then this afternoon I opened the Settings menu, went to Display, and before I could do anything else I received a phone call. As I terminated the call, the screen flashed, the phone rebooted--and after restarting it is completely, or almost completely blank. If I repeatedly tap the power button I get a fraction-of-a-second glimpse of the SIM PIN screen at normal brightness. This leads me to the suspicion that, by some weird combination of bad luck and an accidental touch of a finger after terminating the phone call, that the Minimum Brightness somehow got set--although why the phone then rebooted I don't know.
Anyway, by luck and good judgement I finally managed to enter the correct SIM PIN and then the phone unlock PIN. However, I can do nothing else. The screen is still blank, and as the phone is currently unlocked I don't want to touch the power button. Before sending the phone back to the manufacturer or anything drastic like that, I would like to try disabling the Xposed Framework. Whilst trying to find something useful in Windows Explorer I found Xposed-Disabler-Recovery.zip in the Internal storage\Android\data\de.robv.android.xposed.installer\files folder on my phone. I assume that this should be what I need. However, as I cannot see anything on the screen I would need to know the exact buttons to press, in which order and how many times etc, in order to enter the Recovery menu and do what is needed. According to the phone manufacturer the OS is unmodified Android 4.4.2., although strangely they will not even tell me which keys to press to enter the Recovery menu (long story, the upshot is, they flat out refuse to help apart from suggesting returning the phone).
Note that I only suspect it is the Minimum Brightness module that is causing the problem, however the problem did not exist before yesterday (when I installed the module), and as I was about to do something with the brightness when the phone rebooted itself, it seems too much of a coincidence to be anything else. If I cannot disable the module/framework, the only other thing I can think of is a factory reset--but again I would need to know exactly which buttons to press, in which order etc. Unfortunately at the moment USB debugging is not enabled, and again without the screen I cannot access it to turn it on.
Any help or suggestions hugely appreciated.
PL
@Papalazzzaru
Xposed now sports a safemode which allows you to disable Xposed during bootloops. To disable Xposed, you'll have to repeatedly tap one of the hardware buttons (Power, Volume, or Home) on your device during startup.
During boot, your device will vibrate twice when it detects the first key press. You'll then have five seconds to press that same button four more times, with each keystroke producing a short single vibration. After ending with a long vibration, your device will disable and prevent most of Xposed's actions, allowing you to easily troubleshoot problematic modules.
Sorted
Outstanding, thanks.
Papalazzzaru said:
I installed thi............. gely appreciated.
PL
Click to expand...
Click to collapse
Device model please?
Caterpillar S50, on Android 4.4.2, baseband version LTE_S0201121.0_S50_0.017.00.
it is compatible with lollipop?
imam88 said:
it is compatible with lollipop?
Click to expand...
Click to collapse
The MX Player part still works. I don't know about the lowest value of brightness in general but at least with CM12 & Samsung the brightness goes to the hardware minimum by default.
Thanks, this is exactly what I want.
Could you make it for LP ?
I want my phone be absolute zero brightness for driving navigation.
Tested it on CM12.1 Nightly on the Nexus 6. It works here, but on 0 the screen is a bit purple. However, I guess this is the screen's fault
Gesendet von meinem Nexus 6 mit Tapatalk
moneytoo said:
The MX Player part still works. I don't know about the lowest value of brightness in general but at least with CM12 & Samsung the brightness goes to the hardware minimum by default.
Click to expand...
Click to collapse
Yes it works
This module seems to be working well on the Moto X Pure Edition (Motorola xt1095) running Lollipop 5.1. It's an AMOLED screen, and I personally find the minimum brightness on 5.1 too bright, so this has helped solve that.