Enabling charging/notification LED

[jova33]

didn't the dev for lightflow get something working? I was looking for that thread when I found this one.

 

[doitright]

Who says that notification's even need to blink? It isn't like low output LEDs are going to suck the battery dead. Having blinking LEDs really made more sense back in the days before you had multiple colors or multiple meanings, or shared the same led between charging and notification. If you just had a red and a green LED in one spot, you needed to be able to blink them in order to signify between different things, i.e. solid red/green for charging/charged, blinking green for notification, blinking red for error. That really is a total of 4 states to be described, and together that did an adequate job.

Now we have a bit more LED to play with. Can do blinking green/green for charging, and three different colors for notifications.

 

[raiden]

Forget lightflow, This should be integrated into either stock or cyanogen mod 12.

 

[dparrothead1]

Validus ROM has the notification lights working.

Sent from my Nexus 6 using XDA Premium 4 mobile app

 

[datajosh]

Validus ROM has the notification lights working.

Sent from my Nexus 6 using XDA Premium 4 mobile app

Looks like this is a result of a device commit to LiquidSmooth, I believe it's this one:

https://github.com/LiquidSmooth-Dev...mmit/47a8f67950ebfb300d466a7b6094dea34d6a08d1

 

[SLMcc]

I just want to say I really hope you can get the notification lights back without having to root. I have zero idea how to do that. And no desire to ruin my phone learning. I just want my notification LED back.

Thank you for working on this. Lollipop and the N6 are a real disappointment.

 

[doitright]

I just want to say I really hope you can get the notification lights back without having to root. I have zero idea how to do that. And no desire to ruin my phone learning. I just want my notification LED back.

Thank you for working on this. Lollipop and the N6 are a real disappointment.

Android 5 is by no means a disappointment. It has nothing at all to do with the lack of lights on N6. N6 is a showcase device -- Google is using it to show off the on-screen notification system.

Regardless of that, I absolutely promise you that enabling the notification light ABSOLUTELY requires root. It can only be done by changing files in the /system partition.

But don't get scared. This is one of the INTENDED features of all Nexus devices. Unlike almost every other device out there, Nexus is *intended* for you to mess with. Root access *DOES NOT* require ANY hacks.

fastboot oem unlock
fastboot boot CF-auto-root.img

That's it. Two commands you run from your desktop/laptop/refrigerator, and you have root.

---------- Post added at 02:44 PM ---------- Previous post was at 02:40 PM ----------

Looks like this is a result of a device commit to LiquidSmooth, I believe it's this one:

https://github.com/LiquidSmooth-Dev...mmit/47a8f67950ebfb300d466a7b6094dea34d6a08d1

Wonder why they aren't using the charging LED for charger notifications?

 

[Surge1223]

[R&D][DEV] Fix Standard Kernel Features

I'm going to assume not enough people know a about the devs only thread, that or we have an extremely low number of devs that code themselves. Anywho, as we all know, the nexus 6 should be able to manage LEDS itself at the kernel level and indeed the qpnp-led drivers are in the kernel source. As far as actually adding the support and led features to the kernel, this is done by editing the dts files in the arch/arm/boot/dts and arch/arm/boot/dts/qcom and by editing them to support the gpio led drivers does indeed enable leds and led management auto managed by the kernel I'll link to the edits I made on git at the end.

Unfortunately getting full support isn't so cut and dry, for example charging red led will turn on if I turn on my display while charging (instead of off) but the green indicator for full charge works fine. Before someone replies linking me to the light app devs thread or liquids ROM which both control LEDs at the sysfs level, realize that, but I want to enable auto managed leds from the kernel itself the way it's supposed to be.


were not really going to echo commands into sysfs to control this are we? With all the talent we have here I'm sure we can solve this.

here's the git I'm working from https://github.com/Surge1223/android_kernel_moto_shamu/commits/master

if anyone has any ideas on dts edits that could help that would be awesome.

I'm using the purified_shamu_defconfig and currently I have red charging led only when charging when screen on, green led kicks in when charge is complete though.

ramdisk is stock, I have not messed with writing sysfs values via editing ramdisk because it should not be needed. We should fix the basic issue instead of using work arounds.

I half way expect no other devs to reply here either, so is the nature of the beast, but hey maybe (hopefully?) I'm wrong and we can set an example of how open source and community efforts can effect a device.

I'm going to ask moderators to strictly limit posts to development only.


This is a nexus dev forum, let's start acting like it and fix this issue together.

 

[DespairFactor]

I'm going to assume not enough people know a about the devs only thread, that or we have an extremely low number of devs that code themselves. Anywho, as we all know, the nexus 6 should be able to manage LEDS itself at the kernel level and indeed the qpnp-led drivers are in the kernel source. As far as actually adding the support and led features to the kernel, this is done by editing the dts files in the arch/arm/boot/dts and arch/arm/boot/dts/qcom and by editing them to support the gpio led drivers does indeed enable leds and led management auto managed by the kernel I'll link to the edits I made on git at the end.

Unfortunately getting full support isn't so cut and dry, for example charging red led will turn on if I turn on my display while charging (instead of off) but the green indicator for full charge works fine. Before someone replies linking me to the light app devs thread or liquids ROM which both control LEDs at the sysfs level, realize that, but I want to enable auto managed leds from the kernel itself the way it's supposed to be.


were not really going to echo commands into sysfs to control this are we? With all the talent we have here I'm sure we can solve this.

here's the git I'm working from https://github.com/Surge1223/android_kernel_moto_shamu/commits/master

if anyone has any ideas on dts edits that could help that would be awesome.

I'm using the purified_shamu_defconfig and currently I have red charging led only when charging when screen on, green led kicks in when charge is complete though.

ramdisk is stock, I have not messed with writing sysfs values via editing ramdisk because it should not be needed. We should fix the basic issue instead of using work arounds.

I half way expect no other devs to reply here either, so is the nature of the beast, but hey maybe (hopefully?) I'm wrong and we can set an example of how open source and community efforts can effect a device.

I'm going to ask moderators to strictly limit posts to development only.


This is a nexus dev forum, let's start acting like it and fix this issue together.

I am not 100% sure how we can do this, but if you need some help poking around and testing modifications I am here and am willing to fork your repo to work on this.

 

[Surge1223]

I am not 100% sure how we can do this, but if you need some help poking around and testing modifications I am here and am willing to fork your repo to work on this.

Awesome good to see fellow kernel devs interested in helping

So this is what im doing I'm basically looking at qcoms commits here and here trying to understand their methodology and what they found/changed and for what reason. Theres more than a few commits directly referring to LED capability and enabling/disabling functions and indeed implementing some edits does effect the way the LEDS are controlled and shown, for example I have 8 entries in /sys/class/leds and I have gotten the charging LED to work (albeit, somewhat backwards in implementation)

The way I see it, I think having the right combo of edits/fixs in dts and the qpnp-led drivers will result in full functionality. Take a look at the commits in the link and let me know what you think

More specifically this link

 

[DespairFactor]

Awesome good to see fellow kernel devs interested in helping

So this is what im doing I'm basically looking at qcoms commits here and here trying to understand their methodology and what they found/changed and for what reason. Theres more than a few commits directly referring to LED capability and enabling/disabling functions and indeed implementing some edits does effect the way the LEDS are controlled and shown, for example I have 8 entries in /sys/class/leds and I have gotten the charging LED to work (albeit, somewhat backwards in implementation)

The way I see it, I think having the right combo of edits/fixs in dts and the qpnp-led drivers will result in full functionality. Take a look at the commits in the link and let me know what you think

More specifically this link

A real question is, where is the samsung code? Could we not look at this since it's the same hardware? There must be something that can at least be looked at from that side, I think at least


I also just saw this https://www.codeaurora.org/cgit/qui...e&id=c4bf9abc80b74cc53e3d6565a259a83b541d8c3a

Definitely something to look at since it's enabling LED on an 8084 variant.

 

[skeezer308]

Slight OT.. Surge! Good to see you over here. I got away from the VZW SGS4 soon as I could. Loving this phone. Still keeping an eye on your threads over that way though. Also, on a more related note, I noticed that Chroma, here, has integrated native LED.

 

[DespairFactor]

@Surge1223 any luck thus far with what we discussed?

Also, BUMP!

 

[stumpy352]

A real question is, where is the samsung code? Could we not look at this since it's the same hardware? There must be something that can at least be looked at from that side, I think at least


I also just saw this https://www.codeaurora.org/cgit/qui...e&id=c4bf9abc80b74cc53e3d6565a259a83b541d8c3a

Definitely something to look at since it's enabling LED on an 8084 variant.

This looks promising. Not that I'm a coder or anything, but I can at least see the similarities & differences between these to sources. My question is, can you have more than one entry for each device. i.e will enabling, say the blue led for notifications cause that device to be unavailable for any other function?

 

[DespairFactor]

This looks promising. Not that I'm a coder or anything, but I can at least see the similarities & differences between these to sources. My question is, can you have more than one entry for each device. i.e will enabling, say the blue led for notifications cause that device to be unavailable for any other function?

I was thinking even a generic color for notifications would be fine(blinking) with a charge light. I think surge was testing this in his source, I am just awaiting his feedback

 

[stumpy352]

I was thinking even a generic color for notifications would be fine(blinking) with a charge light. I think surge was testing this in his source, I am just awaiting his feedback

This is what I was thinking also. Blue for notifications makes sense. Then red/green for battery states. i.e red=low bat, red&green(orange kinda)=charging, green=charged. I can sort of see how you could implement this, but how to add heartbeat. I think I remember, while scouring the kernel source that these triggers and blink functions were implemented at a higher level somewhere.

 

[DespairFactor]

This is what I was thinking also. Blue for notifications makes sense. Then red/green for battery states. i.e red=low bat, red&green(orange kinda)=charging, green=charged. I can sort of see how you could implement this, but how to add heartbeat. I think I remember, while scouring the kernel source that these triggers and blink functions were implemented at a higher level somewhere.

Look at the code I presented, that's what I believe is the note 4 LED code. It specifically has a notification setting for one of them. I am thinking we can maybe port that over somehow. If you wish to discuss further it might be easier to hangout me.

 

[stumpy352]

Look at the code I presented, that's what I believe is the note 4 LED code. It specifically has a notification setting for one of them. I am thinking we can maybe port that over somehow. If you wish to discuss further it might be easier to hangout me.

Looks like the code you presented is shamu code. PM'd you.

 

[DespairFactor]

Looks like the code you presented is shamu code. PM'd you.

I responded but got nothing from you yet

 

[doitright]

You guys realize that there are actually FOUR DISTINCT LEDs on this thing, right? Two if you count the RGB as just one. Hard to justify that though, since they don't blend.

/sys/class/leds/red
/sys/class/leds/green
/sys/class/leds/blue
/sys/class/leds/charging

The charging led has a BLINKER.

Edit: The charging LED is also green like the green LED, and happens to be within the same cluster of LEDs as the other 3, but is definitely distinct, since turning it on increases the brightness of green.

Edit2: Hmm.. I can set a trigger of "battery-charging-blink-full-solid" to the red/green/blue LEDs, and they also blink. Wonder what the blink mechanism there is?