Enabling charging/notification LED

[garyd9]

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.)

 

[garyd9]

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

 

[garyd9]

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:

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.)

 

[garyd9]

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.

 

[garyd9]

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.

 

[garyd9]

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:

 

[Imoseyon]

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

 

[itsmikeramsay]

Yeah I haven't seen anything hardware side either.

 

[garyd9]

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]

I'm trying to unravel the mess of device trees..

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.)

 

[Imoseyon]

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.

 

[garyd9]

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.

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.

 

[garyd9]

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.

 

[upndwn4par]

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

 

[plasticarmyman]

i took these screenshots using Tricksters LED Control settings.
When using

battery-charging-blink-full-solid

i get the light to blink while charging...

 

[Toledo_JAB]

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

 

[IceXcube84]

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

 

[garyd9]

I have found out what some of the triggers is doing but the list is not complete yet.

..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)

 

[raiden]

Even if the LED lights have to be swapped if it can't be figured out is still ok.

 

[raiden]

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.