On 09/05/11 16:59, Luca Olivetti wrote: > Al 09/05/2011 0:31, En/na Luca Olivetti ha escrit: > >> It turns out that the ebu, in the gpio_led structure, uses gpio starting >> from 32, so defining "fake" leds using gpios 32-40 I could map all >> missing >> leds. >> Since they're active low, I used lq_register_gpio_ebu(0xff), so they all >> turn off as soon as the kernel calls lq_register_gpio_ebu (contrary to >> leds controlled by "real" gpio, they're lit at power on, the original >> firmware turns them off very soon). > > > The next question is, how can I control (some of) the leds from an > userspace program? > Opening the /sys/class/leds/<led name>/trigger file and alternatively > writing "none" or "default-on"? > Or the same but with the "brightness" file? > Writing a trigger module? (and how since the trigger comes from user > space)? > Open the gpio directly? (again, how?) > Some other way? > > TIA
Hi luca, if it is a gpio cd /sys/class/gpio echo 13 > export echo out > gpio13/direction echo 0/1 gpio13/brightness for a led in userland echo default-on >/sys/class/leds/<led name>/trigger or in kernel space use the "default trigger" as shown in this patch https://lists.openwrt.org/pipermail/openwrt-devel/2008-January/001618.html also look at /etc/init.d/led it allows you to setup your leds based on a uci file so ideally you give your leds a default brightness / trigger in the kernel code and then setup the others in userland via uci depending on which works best / makes sense for the specific case _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
