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.
Related
I have one little problem I could not find a fix on. When i boot into Android or reinstall it my Orange LED stays on it and it never goes off. Is there a fix for it.
Thanks
This is a known problem, see the bottom of the thread in my signature for a full list of known problems.
The notification LED will stay like this until one of the developers fixes it, when fixed, a kernel update will be available for you to download.
Currently, the LED usually indicates sleep state. Orange for awake, blinking for going into sleep mode, and solid green for deep sleep.
Soon, hopefully, the LED will be changed so that it indicates new messages or missed calls on the phone.
Thanks
Is there a way to turn it off or disable it?
The only problem I have with it is will it drain the battier faster (then normal)
DVA4890 said:
Thanks
Is there a way to turn it off or disable it?
The only problem I have with it is will it drain the battier faster (then normal)
Click to expand...
Click to collapse
It will not drain the battery any faster than normal.
Please read the FAQ, the LED is currently used to indicate sleep state - let me tell you, the phone not sleeping is MUCH worse than any LED being constantly on...
arrrghhh said:
It will not drain the battery any faster than normal.
Please read the FAQ, the LED is currently used to indicate sleep state - let me tell you, the phone not sleeping is MUCH worse than any LED being constantly on...
Click to expand...
Click to collapse
Well, solid green WILL drain faster than "off" - however, the drain is negligible compared to even the sleep mode drain of the radio.
The only time you might see more than a few minutes difference with the solid-green vs. off in terms of battery life is in airplane mode and in sleep for many hours - but who puts their phone in airplane mode and doesn't use it at all for many hours? The almost negligible difference in battery life is made up for by the improvement in power management debugging capability. Once we kill all of the Sleeps of Death, failed wakes, and RIL crashes (all current work in progress), the LED behavior will get changed.
However - If you are running one of WisTilt2's PM kernels and you see the phone stay in solid orange or blinking green for extended periods of time, some app or setting you are using is preventing deep sleep. Do a dmesg and look for wakelocks, or do the following:
Disable GPS - when enabled, it prevents deep sleep until disabled
Use Advanced Task Killer to kill background apps. Some apps wakelock the hell out of our phones. Facebook is particularly bad here.
If you're not running a WisTilt2 kernel, there is no difference between "on/temporary wake due to alarm/interrupt" and "attempting to sleep". WisTilt2's kernels change LED behavior during "attempting to sleep" to blinking green.
Now how do I do a dmesg where cam I find out how to do that
Thanks
DVA4890 said:
Now how do I do a dmesg where cam I find out how to do that
Thanks
Click to expand...
Click to collapse
2 ways:
ADB:
Windows
Other OS
Terminal:
Install Android Terminal Emulator.
Open and type:
su [enter]
dmesg > /sdcard/dmesg.txt [enter] (or other direction)
Open file manager.
Go to your sdcad and open dmesg.txt
Fairly certain mortals can view dmesg output, so no need for su I think.
Entropy512 said:
Fairly certain mortals can view dmesg output, so no need for su I think.
Click to expand...
Click to collapse
lol @ mortals.
This is correct, you do not need su rights to use/view dmesg.
There is a nifty app called OSMonitor in the market that among other things will let view dmesg live. Just found it yesterday.
I saw a review of the lovely Nokia N9, and I noticed that whenever it is put in sleep mode, it does not shut off the screen entirely - instead, it shows a clock that moves around the screen to prevent burn-in. I rather like this idea, and it apparently draws very little juice from the AMOLED screen (which is what my Captivate has).
I spent some time looking for an Android app that accomplishes something like this, but I didn't find anything like it. If there is such an app, could someone point me towards it? If not, is this even possible?
Alright, since this thread doesn't seem to be generating much interest, allow me to bump it with some ideas that might help spark your imagination.
- Replaces sleep mode completely, and might even replace lockscreens
- Displays notification alerts
- Can be toggled on/off by, say, holding down the volume rocker for a few seconds
- Uses the proximity sensor to disable itself when facing down or when placed in one's pocket
- Can be configured to only display under certain conditions (e.g. at night time when plugged in, so as to function as a bedside clock)
- Can cook bacon and eggs
Something like this probably doesn't exist, but would anyone else be interested in something like this if it doesn't use too much battery? If so, I might put up a bounty for whomever brings this to fruition. Would a developer be able to tell me if this is possible? I realize it would probably require root access, but that's fine with me.
So I got tasker up and running and have set up a small scene for when I plug my headphones in. It pops up a small screen asking what I'm doing, and I can either click do nothing (does just that), play music (sets volume levels and starts music), or car mode, which sets volume levels/wifi/blutooth/gps sensors and starts my ecu communication app (torque).
The only problem is, like any good computer science student, I know to unload something when done with it, and I unload the scene. This has the wonderfull effect reverting everything that little menu did back to it's previous state. I've come up with a few possible solutions, but have some gripes with each of them (see below). My question is though, is there any way to make those system changes static, so that when I unload the menu, it doesn't revert it's changes?
Solution 1 - Do not unload the menu, just hide it and have the profile that activates when I unplug my headphones unload it.
Problem - This leaves it in memory. Not the largest chunk of wasted space ever, but still less than desirable. Looks better to me than solution 2 though.
-------------------------------------------------------------------------
Solution 2 - Have the button set a variable which when active starts another profile to do all those things
Problem - That just creates 1 (or more) extra profiles that I assume tasker is constantly monitoring the status of. That's wasted cpu cycles right there.
-----------------------------------------------------------------------
Solution 3 - Somehow make the changes persistent, so that they do not revert when the scene is unloaded.
Problem - I'm not sure if it's possible to do this. Help would be appreciated, thank you!
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
---
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!