On Wed, 2007-01-31 at 20:48 -0500, ext Larry Battraw wrote: > First off, kudos to the maemo team for making such a nifty and > easy-to-use interface for the keypad LED. I spent a inordinate amount > of time just tinkering with the brightness, blinking period, and so > forth :-) For those interested, the relevant sys entries are here: > /sys/class/leds/keypad
Don't thank us too soon. :) _Do Not_ use brightness, on_period and off_period files in that sysfs directory. They are linked to the hardware PWM but have some problems that I will describe later. Only use what is shown in the following example for a SW controlled blinking: / # cd /sys/class/leds/keypad /sys/class/leds/keypad # echo timer > trigger /sys/class/leds/keypad # echo 128 > blink_brightness /sys/class/leds/keypad # echo 1000 > delay_on /sys/class/leds/keypad # echo 500 > delay_off > Should be self explanatory, particularly if you turn on the blinking > from the control panel so you can cat out the values it uses for > delay_off and delay_on, etc. > My question is this: for the default trigger source (timer), is the > blinking just a hardware PWM built into the CPU or is the CPU involved > in counting timer interrupts to handle on/off periods and toggling the > LED? I ask because there was some discussion on ITT about how someone Unfortunately, the CPU is involved because the built in PWM prevents the CPU from sleeping and there is not a lot we can do about it. So the SW solution wakes up device with a period "delay_on". > had their n800 run down overnight with the LED left on. It seemed > unlikely but I wanted to make sure a bunch of CPU cycles weren't being > burned to run it. That is why they are disabled by default. Regards, Amit _______________________________________________ maemo-developers mailing list [email protected] https://maemo.org/mailman/listinfo/maemo-developers
