Related
[Solved] TS FREEZE FIXED / Orientation offset calibration & G-SENSOR CALIBRATION FIX
UPDATE: (13/11) A patch has been developed that completely eliminates TS FREEZE for good.
Thanks to mdebeljuh and jdivic, I tested it and it seems to be working perfectly.
Check post 140 on page 14:
http://forum.xda-developers.com/showpost.php?p=9194473&postcount=140
UPDATE: (20/11)A new patched 8.2 kernel without logging (better for daily use) is available.
Check post 234 on page 24:
http://forum.xda-developers.com/showpost.php?p=9304396&postcount=234
-----
EDIT: If you did autocalibration and messed your g-sensor, read post 10 & 11 to see a fix for it. (before going through post 1)
EDIT 2: Freezes of sensors and touch screen seem to be related to offset values. See post 10 & 11
Post 1 is for orientation offset. Check post 10 & 11 for g-sensor and ts freeze fix.
----
If your orientation is off when you lay your phone on a level surface and can't calibrate it in Android (because many people found it gets corrupted after auto calibration), this is one way to do so. (Winmo g-sensor calibration does not seem to affect android orientation)
Install an app that displays sensor information along with pitch and roll. (such as SensorDebug from Android market)
Put your phone on a level surface such as the floor or a table.
Note your pitch and roll values.
Use rootexplorer or similar file manager to edit /data/misc/AK8973Prms.txt file. (open in text editor) (For ASTRO CHECK POST 70 in page 7)
You will see AOFFSET.x and AOFFSET.y at the bottom. (May be on top if you autocalibrated previously)
y affects pitch and x affects roll, there is about 4 to 1 ratio.
What you are trying to do is make pitch and roll 0 with minimum flicker.
Press and hold home button to switch between rootexplorer and sensordebug. Your changes will be reflected in realtime (with most builds). Go back and forth a few times to get perfect result. (You can press and hold home button to go back and forth) If you think changing values don't have an affect, try to temprorarily change AOFFSET.x=90 and return to your app. When phone is on the table, your leveling bubble or pitch/roll must be way off. This way you can see if with your build changes are reflected in realtime or not. If not try restarting, use different sensor app and give feedback please. (After that revert AOFFSET.x to 0 or other value your want to fix back orientation)
For example:
If pitch is 3 and roll is -1
you may start by
AOFFSET.x=4
AOFFSET.y=-12
Then adjust with 1 increments to get rid of flicker.
It is best to adjust one value at a time.
EDIT: IF YOU WANT TO CALIBRATE Z AXIS, CHECK POST 61 in page 7
Calibrated AOFFSET values for my phone are x=2 y=-9 z=12
You can use gpsstatus or bubble app (to find bubble app search the market for bz.ktk.bubble and enable "show angle" from bubble apps settings.) for visual check of orientation calibration. Because of the protruding camera lens of hd2, there can be 1 degree difference between sideways and normal orientation. (It seems you can adjust in about 0.25 degree increments by each 1 increment of AOFFSET and compansate by lowering AOFFSET=y by 2 that gives 0 degrees in both normal and sideways orientation in bubble app)
- You don't need to reboot for most builds (if there is no affect check post 11)
- You don't need to kill/restart akmd
- You don't even need to close sensor app
- Because of not perfect kernel/build support for sensors, you may see them freeze when you move the phone (TS will also freeze). With evo kernels, just wait a few seconds and it will resume. (With nexus kernels they may freeze until sleep/wakeup) Interestingly the values of AK8973Prms.txt affect shake/move freezes. I wrote about this in post 10 and 11.
IT IS A GOOD IDEA TO BACKUP COMPLETE ANDROID FOLDER BEFOREHAND just in case something goes wrong. Chefs say you shouldn't auto calibrate your g-sensor under Android because with many people it gets messed up. Also good idea to backup your /data/misc/AK8973Prms.txt
You may have trouble accessing data folder with a file manager other than rootexplorer. Your build must be rooted. (most are) It is a good idea to update your su binary inside superuser app settings TWICE. If you change permissions of /data /data/misc folders you may access them even with standart astro file manager. Try chmod 777 /data from terminal emulator.
This procedure is also possible with adb or droidexplorer. But my way of doing is practical and it is in realtime. If your build has different file name, please tell us.
This IS a development thread, please don't tell me to post in generic section or clutter.
This is manual workaround for non-working auto calibration. If auto-calibration works in the future, it may very well fix your freezes.
Values of AK8973Prms.txt file may solve touch screen/sensor freeze problems with your games. Feedbacks are always welcome. We should find out what the other values do exactly. Also check post 10 & 11
Wow, thank you. I will certainly try this when I am sober (tomorrow morning).
I appreciate your taking the time to share this.
Have a good weekend!
Thanks! worked great....
thanks! worked perfectly
haha.. funny, this is the RIGHT way to do it: (credit goes to me )
1) put your phone on the surface and then
2) Gscript to stop gsen.
3) Go to callibration tool and press callibrate..
4) activate Gsensor through Gscript.
thats it and gsensor is fully callibrated to your way. no need to mess with system files.
eeeeeee said:
haha.. funny, this is the RIGHT way to do it: (credit goes to me )
1) put your phone on the surface and then
2) Gscript to stop gsen.
3) Go to callibration tool and press callibrate..
4) activate Gsensor through Gscript.
thats it and gsensor is fully callibrated to your way. no need to mess with system files.
Click to expand...
Click to collapse
Don't you think I already knew that? I wrote this long procedure because calibration tool corrupts calibration and doesn't work with many people. With many builds, chefs write don't calibrate your sensor. You need the gsensor script to be able to stop gsensor (kill akmd) since you didn't share it, people won't be able to do it anyway.
I suggest backing up complete Android folder before attempting to auto calibrate g-sensor within Android. Forum is full of people who calibrated under android and everything is messed up.
memin1857 said:
Don't you think I already knew that? I wrote this long procedure because calibration tool corrupts calibration and doesn't work with many people. With many builds, chefs write don't calibrate your sensor. You need the gsensor script to be able to stop gsensor (kill akmd) since you didn't share it. People won't be able to it anyway.
I suggest backing up complete Android folder before attempting to auto calibrate g-sensor within Android. Forum is full of people who calibrated under android and everything is messed up.
Click to expand...
Click to collapse
gsensor calibration tool causes nothing.. in my way -> t does exactly what you do..
i know that with the evo kernel the gsensor callibration is kinda corrupted, but it still works perfectly when following my orders.
although i would suggest not doing this with gsensor on.
as long as the gsensor is off when calibrating, there is no risk to mess the gsensor up.
although when callibrating with gsensor on messes the whole thing up, you can fix it following my orders again.
although its still nice that you edited the beginning of your tutorial:
memin1857 said:
If your orientation is off when you lay your phone on a level surface and can't calibrate it in Android (because many people found it gets corrupted after auto calibration), this is one way to do so. (Winmo g-sensor calibration does not seem to affect android orientation)
Click to expand...
Click to collapse
eeeeeee said:
gsensor calibration tool causes nothing.. in my way -> t does exactly what you do..
i know that with the evo kernel the gsensor callibration is kinda corrupted, but it still works perfectly when following my orders.
although i would suggest not doing this with gsensor on.
as long as the gsensor is off when calibrating, there is no risk to mess the gsensor up.
although when callibrating with gsensor on messes the whole thing up, you can fix it following my orders again.
Click to expand...
Click to collapse
I have made extensive tests and found out that you are actually doing no proper calibration. You are breaking other things.
- If you disable g-sensor before you open your sensor app (calibration tool) than you get no data from the g-sensor (since you disabled it) and can't calibrate.
- Phone must be very still while you disable g-sensor or the orientation data will get frozen at wrong values. And sensor app must be open beforehand.
If you fail calibration (y axis) will get messed up badly and won't work again. It wil flicker between full up and full down and further calibration attempts will make compass constantly spin.
- Still if you could do it all, nothing changes, offset is still there and calibration is wrong after following your instructions. (Try bubble app or sensor app with real sensitive degree values and you will see)
I searched your posts and saw that you are complaining about touch freezes. Maybe if you don't do auto calibration you may get less freezes?
Also please DO share anything you know. It is not enough to just say -disable g-sensor with gscript- People don't know that script, and if you don't share they can't do it. I saw your thread, you got 0 replies in 20 days, maybe because it doesn't work.
I advise against doing autocalibration. And remember, this is not a pissing contest. We are not doing this for the credit. We should be doing this for helping community. (You should have written nicer, instead of looking like showing off how genious you are and how fool we are. We know some things too.)
My way of doing it is NOT direct calibration. It is providing offset to g-sensor data that many people can do without the risk and can be restored back easily.
Note: I have found out that calibration tool generates a file named AccPrmsF.ini in the same folder with extreme z value. Sometimes a bma_result.txt gets created again with wrong values. Its content is input to AK8973Prms.txt again with extreme z value. If you restore your original AK8973Prms.txt g-sensor starts working properly again. (see post 10 & 11)
eywallah bro
How to restore g-sensor
If you calibrated with android calibration tool and your g-sensor freaked out. Here is how to fix it:
Use rootexplorer to
Delete AccPrmsF.ini and bma_result.txt file in /data/misc (if they exist)
Edit AK8973Prms.txt in /data/misc folder with rootexplorer to these values:
[AK8973]
HDOE_STATUS_SLIDER_OPEN=1
HDOE_STATUS_SLIDER_CLOSE=0
HDOE_SUCTEMP=114
HDAC_SLIDER_OPEN.x=128
HDAC_SLIDER_OPEN.y=135
HDAC_SLIDER_OPEN.z=4
HOFFSET_SLIDER_OPEN.x=250
HOFFSET_SLIDER_OPEN.y=593
HOFFSET_SLIDER_OPEN.z=175
HDAC_SLIDER_CLOSE.x=0
HDAC_SLIDER_CLOSE.y=0
HDAC_SLIDER_CLOSE.z=0
HOFFSET_SLIDER_CLOSE.x=0
HOFFSET_SLIDER_CLOSE.y=0
HOFFSET_SLIDER_CLOSE.z=0
ASENSE.x=256
ASENSE.y=256
ASENSE.z=256
AOFFSET.x=0
AOFFSET.y=0
AOFFSET.z=0
(These values may not solve freezes, check post 11 for different values that may fix freezes)
Some nexus based builds don't have slider open/close lines.
No need to reboot, just save and it should work instantly with most builds. (If it doesn't check post 11) If you delete AK8973Prms.txt or it may get recreated with wrong values (full zeroes) and freak out again. AOFFSET.z=xxx seems to be the culprit of calibrate tools vertical corruption. (Becomes full up or full down like digital when z=veryhigh). Only editing it to zero may solve the problem.
These values may change in time, or between builds. Those were my values, you may try to boot a new version of your android build and rip the file from it and use that instead.
If your g-sensor does not work at all after reboot you may need to restart it. Open terminal emulator and enter these commands:
su
/system/bin/akmd
Now it should be working.
Please tell if it worked for you. By comparing values and working on these values we may as well make g-sensor much better. (Accelerometer doesn't seem to be calibrated) If your build has different file name, please tell us. The instructions in post 10 may not be perfect and I am still working on this and will post if I find anything new. Of course kernel support is also required for getting less flickers, no freezes, proper poll intervall, correct i2c frequency and proper calibration.
EDIT: The values keep changing by itself. Interesting part is I am getting less shake/move freezes (or freezes in only one direction) in sensor apps or games now! I am experimenting with different values and it definitely affects how often freezes happen. I am trying to get the values of what a real calibration would do. Maybe sensor freezes happen when values are out of range. I am sure a proper calibration will get rid of these freezes but since with the current kernels we can't do proper auto calibration, maybe we can do manual one for now. Seems usual x y z accelerometer values are between 10 and -10. When freezes happen they seem to be more than 10 or less than -10. ASENSE values change the range of x y z (minimum working asense is 45 and the more you set the less range x y z has). Also ppp data seem to freeze/restart when sensor freezes happen. If freezes are eliminated even ppp data might work better! Some of the findings might be wrong, of course.
It seems you can update AK8973Prms.txt in realtime with droidexplorer and changes are reflected in realtime when you reopen, switch to the sensor app or sleep/wakeup. This makes testing easier.
It seems I have found non freezing values. Check next post. (Post 11)
Freezes are fixed now.
EVEN IF YOU ARE NOT GETTING TOUCH SCREEN / G-SENSOR FREEZES WITH USUAL USAGE OF YOUR PHONE, INSTALL SENSOR DEBUG, BUBBLE, COMPASS APP OR GAMES AND TRY IF THEY FREEZE WHEN YOU SHAKE/MOVE THE PHONE OR WALK WITH THE PHONE IN YOUR HAND. Bubble app is the most freezing app. To find it ssearch the market for bz.ktk.bubble. Enable "show angle" from bubble apps settings. Game example: Teeter
Make sure it has been at least 2 minutes since Android has booted. (Or it may fool you as it is busy when first home screen appears after boot)
Freezes have been mostly eliminated with newer builds/kernels, but they are not completely gone.
I am no longer getting any freezes in any app now. Not in compass apps, not in games, not in sensor displaying apps, not in calibration tool. I am also not getting freezes while I am walking with the phone.
I am not yet sure how this exactly happened (as I always had freezes in those apps when the phone moved) but currently my android build updates the AK8973Prms.txt file every minute by itself (doesn't change very much, but quite different from the beginning) and the current values have absolutely no freezes.
These values have no more freezes. (since they keep changing it may not last for days) Please try:
[AK8973]
HDOE_STATUS_SLIDER_OPEN=2
HDOE_STATUS_SLIDER_CLOSE=0
HDOE_SUCTEMP=111
HDAC_SLIDER_OPEN.x=4
HDAC_SLIDER_OPEN.y=135
HDAC_SLIDER_OPEN.z=8
HOFFSET_SLIDER_OPEN.x=-849
HOFFSET_SLIDER_OPEN.y=1179
HOFFSET_SLIDER_OPEN.z=-653
HDAC_SLIDER_CLOSE.x=0
HDAC_SLIDER_CLOSE.y=0
HDAC_SLIDER_CLOSE.z=0
HOFFSET_SLIDER_CLOSE.x=0
HOFFSET_SLIDER_CLOSE.y=0
HOFFSET_SLIDER_CLOSE.z=0
ASENSE.x=256
ASENSE.y=256
ASENSE.z=256
AOFFSET.x=0
AOFFSET.y=0
AOFFSET.z=0
Seems
A low HDAC_SLIDER_OPEN.x value
A large negative HOFFSET_SLIDER_OPEN.x value
A high HOFFSET_SLIDER_OPEN.y value
A large negative HOFFSET_SLIDER_OPEN.z value
and along with some other thing I did/happened fixed my freeze problems.
Some nexus based builds don't have slider open/close lines.
Change the AOFFSET.x y and z values to your device to level it on a table. (check post 1)
I am not attaching the file itself to this post because of differences between windows and linux with text files, just to be safe. (Paragraphs get messed up)
Also using the calibration tool with the phone face down gives better results with z axis. (to be able to tap on calibrate, put your phone on the table and make it just go over the edge of the table and tap from underside)
We need some feedback from other people now. Devs are welcome to use this information to open up ways to fix g-sensor in kernel.
I am using mdeejay desire hd 3.4 build. These may be different in other builds. If you find out please share.
Freezes returned after reboot. I am trying to find out how refix again.
I AM ASKING EVERYBODY TO TELL
1) If they have the freezes with their default configuration with bubble/sensor app moving/walking etc.
2) If my values fix the freeezes
3) If their filenames etc is different
4) Please also write your build and kernel type/version/base winmo rom and radio
Example: (copy paste and edit in your post please)
Default configuration have freezes: YES
New values fix freezes: YES
Different files: NO
Build/Kernel: mdeejay desire hd 3.4 / huanyu #21 evo base miri WM6.5 (21916) v19.1 (3.14 base) 2.15.50 radio
This is not over yet, with feedback we might find exact long term fix for everyone.
EDIT: These values work with some people. If they don't work you, experiment with different values. Since the results are reflected in realtime for most builds (no reboot required) it is much easier. Also don't edit the file on windows pc, it may get messed up. Some builds auto update the values when sensor app is reopened/switched to.
IMPORTANT: Try to temprorarily change AOFFSET.x=90 and return to your app. When phone is on the table, your leveling bubble or pitch/roll must be way off. This way you can see if with your build changes are reflected in realtime or not. If not try restarting and give feedback please. (After that revert AOFFSET.x to 0 or other value your want to fix back orientation)
EDIT 2: My sensors seem to be working perfectly since I also calibrated the z-axis. (post 61 on page 7) I need confirmation on this.
wow! thank you very much!
will try and post results soon.
Default configuration have freezes: YES (from time to time, not always)
New values fix freezes: YES. Post 11
Different files: NO
Build/Kernel: hyperdroid 1.6 / michyprima R11
before, using a live wallpaper called shake them all, the phone would insta-freeze on me.
using your values from post 11 (simple copy paste), no more freezes. And i really abused the wallpaper!
If this changes, i'll report here
EDIT: new answers
Post 1 is not for freeze fixes.
The solution is not long term.
I am extensively trying to find out what exactly made the freezes go away.
Because while it worked for many hours. After reboot freezes came back. I will hopefully find out why. Also the reason why the values change every minute is mistery. Contents of the file (values) change after you start or switch to any app that accesses the sensors. After android has booted it won't get updated unless the sensor reading apps are working.
I have been trying with many builds and kernels for theese freezes and they were never gone before. This time it never froze for several testing hours till I rebooted. That must be something.
Fixing the g-sensor after calibration corruption is ok. Adjusting level offset is also ok. But freezes need some more testing.
new answers in my above post.
you said that after the reboot freezes would happen. i change the permissions to read only on the AK8973Prms file, rebooted and no freezes.
crawlingcity said:
before, using a live wallpaper called shake them all, the phone would insta-freeze on me.
using your values from post 11 (simple copy paste), no more freezes. And i really abused the wallpaper!
...
new answers in my above post.
you said that after the reboot freezes would happen. i change the permissions to read only on the AK8973Prms file, rebooted and no freezes.
Click to expand...
Click to collapse
I am glad it worked for you and we are making progress.
I also had tried changing permissions before but after one minute permissions revert back to writable and the files is updated by the system.
just tested again. restored the default file (with the default values) and as soon as the little droids (or homers in my case) start moving - freeze.
Changed again to your values in post 11, changed permissions to read only, rebooted, played with the phone, i even juggled my HD2! No freezes. I think i won't change anything, unless i need to correct the pitch and the roll.
crawlingcity said:
just tested again. restored the default file (with the default values) and as soon as the little droids (or homers in my case) start moving - freeze.
Changed again to your values in post 11, changed permissions to read only, rebooted, played with the phone, i even juggled my HD2! No freezes. I think i won't change anything, unless i need to correct the pitch and the roll.
Click to expand...
Click to collapse
How are you changing the permissions?
I change permissions to readonly with rootexplorer and after I switch to sensordebug or bubble or phone tester app, the file reverts its permissions back to writable and gets updated.
BTW bubble app freezes more frequently than other apps. But when my freezes were gone, even bubble app never froze even when abused.
I'm just using root explorer. Select the file, uncheck the "write" option, close root explorer. Open sensor debug or whatever, check the file, untouched.
crawlingcity said:
I'm just using root explorer. Select the file, uncheck the "write" option, close root explorer. Open sensor debug or whatever, check the file, untouched.
Click to expand...
Click to collapse
I am doing the same but it becomes writable again. Must be because of different sensors.xxx.so file and build or maybe because you are trying with a wallpaper and not an app.
BTW editing the file on windows pc may not work because of paragraphing difference between windows and linux. If this happens, my phone just adds new zero values to the end of the file.
I am dying to reproduce the fix. I will test with some different builds. That constant file updating is killing me.
Is there any mod that can disable notification LED and sensitive buttons LEDs forever? I know there is a few apps that can do that. But I don't wanna use apps, I noticed some custom ROMs ship with that option. I'm using stock ROM. Sorry for creating a new thread for that. But I can't find a solution for EVO 3D that would work for me. Thanks
I'm sure there will be something released like that. Nothing to my knowledge as of yet. Just something to dim the capacitive buttons.
And this goes in the Q&A section. I hope you have thick skin. Pm a mod to have it moved
Sent from the CM powered 3d
It wouldn't be too hard to do. You can see what needs changed in the kernel in my thread here. I have a version that has no capacitive LEDs and the notification LED will shut off after 5 mins or so.
plotnick said:
Is there any mod that can disable notification LED and sensitive buttons LEDs forever? I know there is a few apps that can do that. But I don't wanna use apps, I noticed some custom ROMs ship with that option. I'm using stock ROM. Sorry for creating a new thread for that. But I can't find a solution for EVO 3D that would work for me. Thanks
Click to expand...
Click to collapse
well... not sure about the blinking LED's... but let me ask you this: how will you know when your phone is charged?
and as for the soft keys, if you have root explorer, navigate to...
/sys/devices/platform/leds-pm8058/leds/button backlight/currents
when you select the button backlight directory, the "currents" is a file. long press on this file until a little menu pops up, select "open in text editor" the value there should be default 20. change it to zero, then hit your menu soft key and select "save and exit"
your leds are now off.
EDIT** and before you do all of that, you will need to select the little grey box at the top of root explorer to mount the system files as "RW", otherwise you wont be able to edit the currents file (as it will be read only)
Questions or Problems Should Not Be Posted in the Development Forum
Please Post in the Correct Forums
Moving to Q&A
it worked but only until the next restart. It restores default value everytime... Why?
plotnick said:
it worked but only until the next restart. It restores default value everytime... Why?
Click to expand...
Click to collapse
because the LED is controlled by the kernel... so, although you can manually fix it for a moment to the value you want, every time the phone boots, the phone resets the value.
the only way to make it permanent is to have a kernel with disabled LEDs
plotnick said:
it worked but only until the next restart. It restores default value everytime... Why?
Click to expand...
Click to collapse
If you just don't want the bottom buttons to light up, use the kernel I linked in my earlier post (assuming you are using a 2.3.4 ROM). If you're still using a 2.3.3 ROM, you can find a kernel call nolights made by joe85 (which is where I found the changes to make in the kernel for 2.3.4).
Yay! Now i will finally be able to sleep at night!
FXP045 released, http://forum.xda-developers.com/showpost.php?p=16822404&postcount=4
Current Issues (FXP045) and unofficial fixes
Hardware keyboard layout scrambled - Old keyboard file is no longer in this ROM but appearently just pasting the old stock file (attached) to /system/usr/keychars/ fixes the layout. The included keyboard changer app force closes.
LEDs under soft keys Return and Menu - Replace /system/etc/hw_config.sh with the attached file.
Screen flicker upon turning on - New issue in fxp045.
can this work on Ray?
the flash does not work either
and the keyboard light does not work when use (when charging, it works)
and the max brightness is not very bright
xutienan9520 said:
can this work on Ray?
the flash does not work either
and the keyboard light does not work when use (when charging, it works)
and the max brightness is not very bright
Click to expand...
Click to collapse
I believe these fixes will work on Ray but you should find the stock values from Ray ROM because there probably are some differences.
Basically, only one issue you're having can potentially be fixed using SK17i fixes and that is max brightness by applying the fix for screen flicker. If you can't get a hold of Ray's stock values, try SK17's stock ones, but do a backup in recovery just in case.
thanks～
i changed the light.semc.so in system\lib\hw from stock 2.3.3, now i have the max brightness, but the keyboard light is on for ever! i can't close it!!!!the colour is always pink!
i think i can edit the file, i am in Mac, so is there a way to edit it without linux?
xutienan9520 said:
thanks～
i changed the light.semc.so in system\lib\hw from stock 2.3.3, now i have the max brightness, but the keyboard light is on for ever! i can't close it!!!!the colour is always pink!
i think i can edit the file, i am in Mac, so is there a way to edit it without linux?
Click to expand...
Click to collapse
i'm editting these files on the phone. copy the file to sdcard to edit it, with any kind of text editor. i use edit function of Total Commander. then i copy over the original file in system with Root Explorer. backup original file to sdcard just in case.
dont know about Mac much, sorry.
root explorer is a paid app but i think ES file explorer has the required functionality
LEDs under soft keys Return and Menu on maximum brightness - distractingly bright, in almost all environments. SOLUTION posted here: http://forum.xda-developers.com/show...&postcount=178
can't open it，need help
xutienan9520 said:
LEDs under soft keys Return and Menu on maximum brightness - distractingly bright, in almost all environments. SOLUTION posted here: http://forum.xda-developers.com/show...&postcount=178
can't open it，need help
Click to expand...
Click to collapse
oh, i messed up the links. will be fixed in a moment =)
Per someones suggestion I've added modified files and instructions on how to replace the original CM ones.
yepsky!!
I found the background ligths for the keyboard
Code:
echo 100 > /sys/devices/i2c-0/0-0040/leds/keyboard-backlight/brightness
I tested 100 and found it adequate.
We just can add it to the config file in /system/etc/hw_config.sh
I do not know if it stays lit when slided back, but it works as a first atempt
PoedelPCS said:
yepsky!!
I found the background ligths for the keyboard
Code:
echo 100 > /sys/devices/i2c-
0/0-0040/leds/keyboard-backlight/brightness
I tested 100 and found it adequate.
We just can add it to the config file in /system/etc/hw_config.sh
I do not know if it stays lit when slided back, but it works as a first atempt
Click to expand...
Click to collapse
Thank you good Sir! Testing it later!
PoedelPCS said:
yepsky!!
I found the background ligths for the keyboard
Code:
echo 100 > /sys/devices/i2c-
0/0-0040/leds/keyboard-backlight/brightness
I tested 100 and found it adequate.
We just can add it to the config file in /system/etc/hw_config.sh
I do not know if it stays lit when slided back, but it works as a first atempt
Click to expand...
Click to collapse
Amazing job! I'm gonna test it out now in a super dark place to see if i can check whether it stays on when closed. =)
I'll be updating original post with results and updated files in a bit.
Edit: Unfortunately keyboard lighting stays on and not only when keyboard is closed but even when phone is locked. Which means, its lit at all times. Won't be updating the files yet, because I don't know how much of a battery drain it is, but i'll put in information about it, so people can decide for themselves.
Nice to see process.
Now i need to find the button light for RAY
sulkie said:
Unfortunately keyboard lighting stays on and not only when keyboard is closed but even when phone is locked. Which means, its lit at all times. Won't be updating the files yet, because I don't know how much of a battery drain it is, but i'll put in information about it, so people can decide for themselves.
Click to expand...
Click to collapse
I thought that
Okay, there is a binary called slidercounter that or something similar sets a system var. If you take your dev Tools app and look unter Configuration there it is mentioned:
hardKeyboardHidden=2 <- if closed
hardKeyboardHidden=1 <- if opened
We now just have to find out where it occurs and if not we make a background script that ech0 x (100) or 0 into the node depending on the state.
But there must be a system process watching this we could use.
Don't hide, I'll find you anyway
---------- Post added at 06:16 AM ---------- Previous post was at 06:14 AM ----------
xutienan9520 said:
Nice to see process.
Now i need to find the button light for RAY
Click to expand...
Click to collapse
did you look, if in ray the nodes under /sys are similar to the pro mini?
you can test using adb shell or terminal app cat'ing the node to see what's in it and echo'ing a number to see what happens.
You meant progress, didn't you
as I am using Scriptmanager anyway I made 2 oneliners besides the shebang that echo either 0 or 100 into the node called
liteon.sh
and
liteoff.sh
put the scripts into root of sdcard, start scriptmanager, choose liteon.sh and check run as root and save
Do this either way with liteoff.sh
Go to your Mangos Homescreen, add a widget, choose Script Manager and choose liteon.sh and in the next step liteoff.sh
You´ll have to Widgets, one puts light on, on off.
This is of course a workaround an will be implemented into lights module. Fxp knows about the fact already.
PoedelPCS said:
as I am using Scriptmanager anyway I made 2 oneliners besides the shebang that echo either 0 or 100 into the node called
liteon.sh
and
liteoff.sh
put the scripts into root of sdcard, start scriptmanager, choose liteon.sh and check run as root and save
Do this either way with liteoff.sh
Go to your Mangos Homescreen, add a widget, choose Script Manager and choose liteon.sh and in the next step liteoff.sh
You´ll have to Widgets, one puts light on, on off.
This is of course a workaround an will be implemented into lights module. Fxp knows about the fact already.
Click to expand...
Click to collapse
not the most elegant solution but it'll do until the fix is in =)
good job though
If I had more time I would have searched where the system keeps the var keyboardHiddenState or how it was called and build a condition of if it's open and not bright enough to switch in on/off
But how I understood fxp the fact about the light seems to be enough to get this working ..I hope so
new issue:
km launcher disturbes camera module.
I use the KM Launcher to determine which keyboard to use in which state.
Portrait: swype
Landscape: thumb keyboard
Keyboard open: hardware keyboard
This is a very cool application that worked perfectly on my rooted stock. If it is active the cam works in the cam app, but not in many other apps that use the cam, e.g. barcoo barcode scanner. I have to disable KM Launcher before using these apps. Hope it'll be fixed automatically in the next release.
I just cannot guess why that happens.
Hey guys I still have the problem with the over sensitive lcd backlight, whenever I'm in a brightly lit room the backlight starts going crazy and sometimes goes so dark I can't see the screen, it then goes super bright.
It repeats this several times a day
I've tries the fix in this thread but it doesn't work
Could someone attach the fix to this thread? As I've tried the the fix using terminal emulator
Thanks
EDIT: it started doing this while I was writing this
Sulkie did append the script to the first post of the thread. Did you test it?
send from a fruit called mango using xda app.
I did it before but it didn't work, I found the reason it didn't work was because I didnr change the permissions.
Sorry I got confused
---------- Post added at 12:51 PM ---------- Previous post was at 12:43 PM ----------
Its still going crazy, I followed the instructions properly though,
When I get home ill upload a video of it happening
I've seen a few threads/comments here about the flickering/adjusting of the backlight level at lower (less than 50%) brightness levels even though auto-brightness was off. As was suspected, it's just due to a content adaptive backlight module. It can be shut off by just running the CABLPreferences activity of the com.qualcomm.cabl app. It also looks like there is a "quality" setting in there to play with that just varies the aggressiveness of the effect.
If you don't know how to launch an activity, you can do the following:
Via ADB:
Code:
adb shell "am start -a android.intent.action.MAIN -n com.qualcomm.cabl/com.qualcomm.cabl.CABLPreferences"
Via Terminal on your phone:
Code:
am start -a android.intent.action.MAIN -n com.qualcomm.cabl/com.qualcomm.cabl.CABLPreferences
I haven't done any more checking, but I'm guessing this is just a flag that could be set in sys/devices/blah... by init.d script on boot as well.
If you prefer a gui, there are plenty of launchers out there that can select an activity to start. I actually had it set up as a long-press pie on LMT while I was playing with it.
It seems (on my phone, at least), that the app wasn't as good at turning it back on, but you can just clear the app data/cache on "Content Adaptive Backlight Settings" in application manager, reboot, and you'll be back to stock behavior.
Sorry I didn't post this sooner. I've been too busy playing with the G2!
this doesn't work.
I've tried this weeks ago. simply telling the app to turn it off does nothing, as it's still on no matter what. deleting the app produces the same exact effect.
in the build prop, the line pointing to cabl is set to false. therefore it's really not even reading what the app is saying it seems.
I believe it's a kernel issue that can only be solved once we get a custom one.
again, this isn't a fix and doesn't turn it off at all sadly.
Sent from my VS980 4G using Tapatalk 4
https://www.youtube.com/watch?v=slwkFhpiYbs&feature=youtube_gdata_player this video was made when it was set unchecked and set to off.
Sent from my VS980 4G using Tapatalk 4
I read your post about this a couple of weeks ago and saw that you mentioned deleting the app, but did you try running it, unchecking the box and rebooting? Deleting it won't do anything, as the app is set to run on boot and (as far as I can tell) set whatever selection you have chosen. I did and this seems to have worked for me I checked by scrolling through a spot on settings that had normally triggered it. I'll play with it more later to see if I either got lucky when I tested it or it is still happening. I agree that this is working on a kernel level.
Is this issue on all carrier versions?
I use auto-brightness and the annoyance I have is that it doesn't change brightness right away when entering different lighting environments. It either takes time or doesn't change at all until I uncheck/check the auto-brightness setting.
xdabbeb said:
I read your post about this a couple of weeks ago and saw that you mentioned deleting the app, but did you try running it, unchecking the box and rebooting? Deleting it won't do anything, as the app is set to run on boot and (as far as I can tell) set whatever selection you have chosen. I did and this seems to have worked for me I checked by scrolling through a spot on settings that had normally triggered it. I'll play with it more later to see if I either got lucky when I tested it or it is still happening. I agree that this is working on a kernel level.
Click to expand...
Click to collapse
yeah, if the app is deleted, then it can't run unless defaulted to on without the app. . so i tried deleting it, and then i also tried un checking the box, and it still does it. no matter what, there must be a setting somewhere else to actually turn it off. did you see that line in the build prop? it's set to false... weird right?
Sent from my VS980 4G using Tapatalk 4
jayochs said:
yeah, if the app is deleted, then it can't run unless defaulted to on without the app. . so i tried deleting it, and then i also tried un checking the box, and it still does it. no matter what, there must be a setting somewhere else to actually turn it off. did you see that line in the build prop? it's set to false... weird right?
Sent from my VS980 4G using Tapatalk 4
Click to expand...
Click to collapse
Yep, I did...and I remembered I had set it to true before I even began messing with the CABL App. I was thinking that could be the difference between what you and I had tried, but I just did a bit more testing to see if it was happening still and unfortunately I think I may have seen it. I'll play with it a bit more later to be sure. I also did a quick look in the usual places for this to be turned on/off in /sys/class/ and couldn't find anything. I suppose it's possible LG built the kernel for this device without the ability to turn it off. If so...that'll be unfortunate.
xdabbeb said:
Yep, I did...and I remembered I had set it to true before I even began messing with the CABL App. I was thinking that could be the difference between what you and I had tried, but I just did a bit more testing to see if it was happening still and unfortunately I think I may have seen it. I'll play with it a bit more later to be sure. I also did a quick look in the usual places for this to be turned on/off in /sys/class/ and couldn't find anything. I suppose it's possible LG built the kernel for this device without the ability to turn it off. If so...that'll be unfortunate.
Click to expand...
Click to collapse
I believe the original Nexus 7 had this feature in the kernel too. However, in custom kernels you could use Trickster mod to toggle the feature off. I think the kernel devs had to expose the setting though, so maybe we'll get this taken care of if we can get a custom kernel.
Here are some build props for Qualcom devices that control the CABL
Code:
ro.qualcomm.cabl=1
hw.cabl.level=Auto
persist.qcom.cabl.video_only=1
By adding / editing these lines in the build.prop you should be able to adjust as noted in the lines.
And yes, it is in the kernel.
Dont know why LG has an app for it?
Scott, I sent you a message on hangouts but in my build prop, i don't show a 1 for the cabl setting.. i show false... as if it's already turned off in the build prop. I changed it to true once and it didn't do anything. those two top settings seem to be what's in the app.. you can check a box to turn it on and off (the first line) and then you can set the degree to which it handles the cabl (second line.) I've messed with both in the app and it did absolutely nothing... does the kernel need to be changed as well?
Sent from my VS980 4G using Tapatalk 4
xdabbeb said:
I've seen a few threads/comments here about the flickering/adjusting of the backlight level at lower (less than 50%) brightness levels even though auto-brightness was off. As was suspected, it's just due to a content adaptive backlight module. It can be shut off by just running the CABLPreferences activity of the com.qualcomm.cabl app. It also looks like there is a "quality" setting in there to play with that just varies the aggressiveness of the effect.
Click to expand...
Click to collapse
I'm not sure you really want to "fix" this feature.
LCD screens (like the one in the LG G2) have inherent low contrast ratio (just 1500:1, in comparison to infinity, with AMOLEDs). In order to compensate, LCD screens use a feature called "dynamic contrast", in which the backlight dims when the screen shows darker content, in order for the perceived black levels to appear darker (and not grey). I'm not sure you want to disable this feature, because the outcome will be grey blacks.
we do want to bc it causes horrible screen flicker issues. you can be sitting on a pic and it doesn't know what to do so it flickers badly
Sent from my VS980 4G using Tapatalk 4
Noam23 said:
I'm not sure you really want to "fix" this feature.
LCD screens (like the one in the LG G2) have inherent low contrast ratio (just 1500:1, in comparison to infinity, with AMOLEDs). In order to compensate, LCD screens use a feature called "dynamic contrast", in which the backlight dims when the screen shows darker content, in order for the perceived black levels to appear darker (and not grey). I'm not sure you want to disable this feature, because the outcome will be grey blacks.
Click to expand...
Click to collapse
I did not know about the contrast ratio on these screens. Makes sense what you are saying.
However like Jay said it does not react smoothly or at appropriate times.
Some will need to edit the kernel code to fix this.
Noam23 said:
I'm not sure you really want to "fix" this feature.
LCD screens (like the one in the LG G2) have inherent low contrast ratio (just 1500:1, in comparison to infinity, with AMOLEDs). In order to compensate, LCD screens use a feature called "dynamic contrast", in which the backlight dims when the screen shows darker content, in order for the perceived black levels to appear darker (and not grey). I'm not sure you want to disable this feature, because the outcome will be grey blacks.
Click to expand...
Click to collapse
Yep. What @jayochs and @scrosler said. What you wrote does make sense, and I had noticed that it behaves the opposite of the CAB implementation on AMOLED screens (where it dims on lighter colored content)...so that gives even more credence to what you're saying, but the implementation is a little buggy. It transitions abruptly and causes the "flickering" that many have reported. I certainly wouldn't mind having it enabled if the transitions were slower/less frequent, but it's kind of annoying as it is. I never was able to find a way to disable it in the stock kernel anyway, so hopefully it can be fixed one way or another now that the source is available. Still the best phone I've owned!
So any success with any method here or elsewhere?
I'm currently using Xposed to try and figure out what is going on here (I have several updateBrightness() events hooked, and am logging stack traces from them). It happened again less than an hour ago, so I need to go through that stack trace and see if I can figure out whether or not the actual brightness update can be blocked.
This has nothing to do with CABL, incidentally. I have CABL turned off, and I've seen the flicker-flicker-flicker-brightness drop issue with nothing more than a web page open. I usually keep my brightness around 68%-69%, too.
antinorm said:
I'm currently using Xposed to try and figure out what is going on here (I have several updateBrightness() events hooked, and am logging stack traces from them). It happened again less than an hour ago, so I need to go through that stack trace and see if I can figure out whether or not the actual brightness update can be blocked.
This has nothing to do with CABL, incidentally. I have CABL turned off, and I've seen the flicker-flicker-flicker-brightness drop issue with nothing more than a web page open. I usually keep my brightness around 68%-69%, too.
Click to expand...
Click to collapse
i'm thinking it's CABL, but it's kernel level, NOT software level, which is why disabling it does absolutely nothing.
I've been using Lux Auto Brightness to fix the issue.
Cheers!
Rayan said:
I've been using Lux Auto Brightness to fix the issue.
Cheers!
Click to expand...
Click to collapse
it's not an issue with auto brightness, that's a completely different problem.
this is the content adaptive backlight problem.
so no solution was ever found for this (besides a new kernel)? my phone doesn't flicker but on the brightness below 50% i can notice it's trying to readjust itself slightly once in awhile (with xda app or play store for example).
Encountered this issue as well. So, the cause of this has something to do with the software and not the hardware? Don't want to send my phone back just to receive yet another problematic set.. I set my screen brightness to 38 which it flickers on certain photos and apps. Bumped it up to about 45 and it seems to have stopped.
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.