Hi all,
does anybody know what to change in system to increase light of keys?? thanks for answer
It's connected to screen brightness. If you set your screen brightness higher, the LED bar will be brighter as well... And the other way around.
good point but I need to increase just keylight, it has to be changeable in some text file in system but I have no idea where..
OK, so I found it
It is in sys/class/leds/so34-led1 & so34-led2 & so34-led0 /brightness & max_brightness
but when I change number in brightness from stock 45 to 150 and save, then it's lighting more, but after close Root explorer, it's the same like before and it will return to 45.. what should I do? make init.d skript??
i also tried it, But same thing happens Value gets Changed to default,,,
can any script b made,,,
I think we should find some configuration file for auto brightness, coz the value in bightness file is changing by current light
ok, so I made init.d script, it actually works, but just until normal automatic change of brightness (for example, when turn screen off, or with light sensor changes..) you can't see any changes on startup too, so you have to force start the script (via root explorer click on script and choose "open with Linux Script handler" and then choose "execute", then the lights will be brighter, you can try it for test
Code:
#!/system/bin/sh
echo 255 > /sys/class/leds/so34-led0/brightness
echo 255 > /sys/class/leds/so34-led1/brightness
echo 255 > /sys/class/leds/so34-led2/brightness
but I think I should make different script.. unfortunatelly I don't know where is some configuration file for control of leds or light sensor or something.. I am just a nooby yet..
Hello,
I’m interested in Motos Sleep Mode.
I did a little research and searched in framework.apk und framework.jar from stock-rom (ics).
I was able to locate the sleep related strings:
<string name="global_action_sleep_mode">Sleep</string>
<string name="global_action_sleep_mode_description">Low power, instant on, wireless off</string>
<string name="global_action_sleep_mode_dialog_title">Sleep Mode</string>
<string name="global_action_sleep_mode_dialog_message">"Sleep Mode places device in a low battery consumption state. When device is powered back on, it instantaneously turns on and brings up all previously running applications and services. Sleep mode can be safely used on Airplanes as all wireless connections are turned off. To exit sleep mode, press and hold the power key."</string>
After that I searched for references in src files. The only ounce I found where in R.java from framework.jar.
Where can I find the onClick action, does someone know?
Why do I do this? I want to have sleep mode in cm10.1 too.
Regards
Ping_2000
It was one of the things I miss after updating to the new Verizon OTA.
---
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!
Hi friends,
I have rooted my android tablet (Chuwi Hi12) as I find the lowest brightness by default way too bright. I found the settings of brightness (/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight/brightness) and changed the settings to a lower value: 5 . I changed it in properties to read only. As long as the tablet is not rebooted it keeps this setting. But after reboot the old brightness setting (value: 21) is back. What am I doing wrong? What do I overlook?
Please help! Many thanks.
Jeanpierre
Jean1965 said:
Hi friends,
I have rooted my android tablet (Chuwi Hi12) as I find the lowest brightness by default way too bright. I found the settings of brightness (/sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight/brightness) and changed the settings to a lower value: 5 . I changed it in properties to read only. As long as the tablet is not rebooted it keeps this setting. But after reboot the old brightness setting (value: 21) is back. What am I doing wrong? What do I overlook?
Please help! Many thanks.
Jeanpierre
Click to expand...
Click to collapse
The init scripts and Android are overwriting the value
Sent from my GT-S7580 using Tapatalk
Thanks, I had a gut feeling of a kind. Are the init scripts and these Android settings customizable? I would very much like to make them permanent.
Thanks again!