Re: how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger)
Hi! > >> > Reason to do it in kernel is that some machines actually have > >> > "coprocessor" on i2c that can do it while main CPU is suspended. (For > >> > more reasons, see beggining of thread). > >> > >> Ick ick. > >> > >> > Binary attribute with array of bytes should be acceptable, rights? > >> > >> Not at all. > >> > >> > (IOW write(..., buf, size) ) > >> > > >> > Ascii array of decimal integers -- no so, right? > >> > > >> > (IOW printf("%d %d ..", buf[0], buf[1]) ) > >> > >> Use an ioctl with a structure to get things correct as a character > >> device. As odds are, you aren't going to be able to create a "generic" > >> format for all of this for all types of devices that support such a > >> "co-processor". > > > > Well, we already do have hw-specific driver in the tree, > > drivers/leds/leds-lp55xx-common.c . But the interface is > > "interesting" and I believe we should have generic interface and it > > should use existing trigger framework -- array of brightnesses does > > not seem too complicated. > > > > Do you have suggestion how to pass the brightnesses over sysfs? > > > > What about send those binary stuff as firmware through kernel firmware > interface and LED trigger sysfs is just for parameters setup and > enable/disable controlling. That might be a bit too heavy. LED patterns do change quite often. lp5523 driver uses this to push binary data through /sys. (It is code for lp5523 processor in this case). Something like that would still be better than firmware loader... cd /sys/class/i2c-adapter/i2c-2/2-0032 echo load > engine1_mode echo cd /sys/class/i2c-adapter/i2c-2/2-0032 echo 9d804000427f0d7f7f007f004200 > engine1_load echo run > engine1_mode Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger)
On Sun, Dec 29, 2013 at 3:21 AM, Pavel Machek wrote: > Hi! > >> > Idea would be "sequence of brigtnesses" (one file) and "delay between >> > changes" (second file). >> >> Ick. >> >> > Reason to do it in kernel is that some machines actually have >> > "coprocessor" on i2c that can do it while main CPU is suspended. (For >> > more reasons, see beggining of thread). >> >> Ick ick. >> >> > Binary attribute with array of bytes should be acceptable, rights? >> >> Not at all. >> >> > (IOW write(..., buf, size) ) >> > >> > Ascii array of decimal integers -- no so, right? >> > >> > (IOW printf("%d %d ..", buf[0], buf[1]) ) >> >> Use an ioctl with a structure to get things correct as a character >> device. As odds are, you aren't going to be able to create a "generic" >> format for all of this for all types of devices that support such a >> "co-processor". > > Well, we already do have hw-specific driver in the tree, > drivers/leds/leds-lp55xx-common.c . But the interface is > "interesting" and I believe we should have generic interface and it > should use existing trigger framework -- array of brightnesses does > not seem too complicated. > > Do you have suggestion how to pass the brightnesses over sysfs? > What about send those binary stuff as firmware through kernel firmware interface and LED trigger sysfs is just for parameters setup and enable/disable controlling. Thanks, -Bryan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Add the LED burst trigger
Hi All, I have finished the pattern trigger and submitted it. For your convince to discuss, I also put it here. Joe The LED pattern trigger allows LEDs blink in user defined pattern. new file: Documentation/leds/ledtrig-pattern.txt modified: drivers/leds/trigger/Kconfig modified: drivers/leds/trigger/Makefile new file: drivers/leds/trigger/ledtrig-pattern.c Suggested-by: Pavel Machek Signed-off-by: Joe Xue --- Documentation/leds/ledtrig-pattern.txt | 60 ++ drivers/leds/trigger/Kconfig | 9 ++ drivers/leds/trigger/Makefile | 1 + drivers/leds/trigger/ledtrig-pattern.c | 207 + 4 files changed, 277 insertions(+) create mode 100644 Documentation/leds/ledtrig-pattern.txt create mode 100644 drivers/leds/trigger/ledtrig-pattern.c diff --git a/Documentation/leds/ledtrig-pattern.txt b/Documentation/leds/ledtrig-pattern.txt new file mode 100644 index 000..4b546c3 --- /dev/null +++ b/Documentation/leds/ledtrig-pattern.txt @@ -0,0 +1,60 @@ +LED Pattern Trigger +=== + +0. Introduction + +LED Pattern trigger is designed to let LEDs indicate the patterns defined by +users. This is very useful for those scenarios where only one non-color led +needs to indicate different states. + +1. How to use + +Pattern trigger can be enabled and disabled from user space on led class +devices that support this trigger as shown below: + + echo pattern> trigger + +When the pattern trigger is activated, it will get the current brightness as +its brightness if the led is on. Otherwise, it will use the maximum brightness. + +If the led supports different values rather than ON/OFF, the brightness can be +set in advance before enabling the trigger. + + echo 128> brightness + echo pattern> trigger + +Two properties are exported. They are delay_unit and pattern. + + delay_unit - a delay time unit, default value is 125 ms + pattern - blink pattern, includes three legal characters + '#', ' '(space), and '/' + '#' let LED on and last delay_unit long time + ' ' let LED off and last delay_unit long time + '/' stop pattern + pattern will be repeated without it + +3. Examples + + Example 1 + + echo pattern> trigger + echo "# ## /" + + The behaviour is like below: + + on(125ms)off(125ms)on(250ms)off + This is Morse code 'A' + + Example 2 + + echo pattern> trigger + echo 200> delay_unit + echo "# # " + + The behaviour is like below: + + on(200ms)off(200ms)on(200ms)off(800ms) + on(200ms)off(200ms)on(200ms)off(800ms) + ...(Repeat) + + This is 2 times burst blinking. diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig index 49794b4..23d0967 100644 --- a/drivers/leds/trigger/Kconfig +++ b/drivers/leds/trigger/Kconfig @@ -108,4 +108,13 @@ config LEDS_TRIGGER_CAMERA This enables direct flash/torch on/off by the driver, kernel space. If unsure, say Y. +config LEDS_TRIGGER_PATTERN + tristate "LED Pattern Trigger" + depends on LEDS_TRIGGERS + help + This allows LEDs to blink in a user defined pattern controlled via + sysfs. It's useful to notify different states by using one led. + For more details read Documentation/leds/leds-pattern.txt. + If unsure, say Y. + endif # LEDS_TRIGGERS diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile index 1abf48d..a739429 100644 --- a/drivers/leds/trigger/Makefile +++ b/drivers/leds/trigger/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_LEDS_TRIGGER_CPU) += ledtrig-cpu.o obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON) += ledtrig-default-on.o obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT) += ledtrig-transient.o obj-$(CONFIG_LEDS_TRIGGER_CAMERA) += ledtrig-camera.o +obj-$(CONFIG_LEDS_TRIGGER_PATTERN) += ledtrig-pattern.o diff --git a/drivers/leds/trigger/ledtrig-pattern.c b/drivers/leds/trigger/ledtrig-pattern.c new file mode 100644 index 000..80fc238 --- /dev/null +++ b/drivers/leds/trigger/ledtrig-pattern.c @@ -0,0 +1,207 @@ +/* + * LED Kernel Morse Code Trigger + * + * Copyright (C) 2013 Joe Xue + * + * Based on Richard Purdie's ledtrig-timer.c and Atsushi Nemoto's + * ledtrig-heartbeat.c and Shuah Khan's ledtrig-transient.c + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include "../leds.h" + +#define MAX_PATTEN_LEN 255 + +struct pattern_trig_data { + unsigned long delay_unit; + unsigned long pattern_len; + unsigned long count; + int brightness_on; + char pattern[MAX_PATTEN_LEN + 1]; + struct timer_list timer; +}; + +static void pattern_timer_function(unsigned long data) +{ + struct led_c
Re: how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger)
Hi! > > Idea would be "sequence of brigtnesses" (one file) and "delay between > > changes" (second file). > > Ick. > > > Reason to do it in kernel is that some machines actually have > > "coprocessor" on i2c that can do it while main CPU is suspended. (For > > more reasons, see beggining of thread). > > Ick ick. > > > Binary attribute with array of bytes should be acceptable, rights? > > Not at all. > > > (IOW write(..., buf, size) ) > > > > Ascii array of decimal integers -- no so, right? > > > > (IOW printf("%d %d ..", buf[0], buf[1]) ) > > Use an ioctl with a structure to get things correct as a character > device. As odds are, you aren't going to be able to create a "generic" > format for all of this for all types of devices that support such a > "co-processor". Well, we already do have hw-specific driver in the tree, drivers/leds/leds-lp55xx-common.c . But the interface is "interesting" and I believe we should have generic interface and it should use existing trigger framework -- array of brightnesses does not seem too complicated. Do you have suggestion how to pass the brightnesses over sysfs? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add the LED burst trigger
Hi! > > I have finished the patten trigger and have tested it. > Do you mind me putting your name as suggest-by? For part idea is >from you. Feel free to do that, thanks :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger)
On Sun, Dec 29, 2013 at 12:50:46AM +0100, Pavel Machek wrote: > On Sat 2013-12-28 13:50:42, Greg KH wrote: > > On Sat, Dec 28, 2013 at 10:25:23PM +0100, Pavel Machek wrote: > > > Hi! > > > > > > > >> Sysfs is meant to be human-readable/writable, so please use plain > > > > >> ASCII > > > > >> numbers in strings instead. > > > > > > > > > > Actually, sysfs is meant to be one value per file, and it is > > > > > > > > Ideally, yes. > > > > > > > > > understood that data that are "natively blob" are just passed as > > > > > blob. (I believe this qualifies). > > > > > > > > But it doesn't buy us much here, does it? It will make e.g. shell > > > > scripts > > > > needlessly complicated. > > > > > > echo -ne '\012' is not that bad, and parsing array of integers from > > > kernel will be an ugly piece of code. > > > > Ick, no. What are you trying to do here? Have the kernel intrepret a > > sequence of bytes to flash an LED? I thought we have frameworks in > > userspace already to handle this type of thing. Please don't invent new > > ways of doing stuff... > > Idea would be "sequence of brigtnesses" (one file) and "delay between > changes" (second file). Ick. > Reason to do it in kernel is that some machines actually have > "coprocessor" on i2c that can do it while main CPU is suspended. (For > more reasons, see beggining of thread). Ick ick. > Binary attribute with array of bytes should be acceptable, rights? Not at all. > (IOW write(..., buf, size) ) > > Ascii array of decimal integers -- no so, right? > > (IOW printf("%d %d ..", buf[0], buf[1]) ) Use an ioctl with a structure to get things correct as a character device. As odds are, you aren't going to be able to create a "generic" format for all of this for all types of devices that support such a "co-processor". greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Add the LED burst trigger
Hi Pavel, I have finished the patten trigger and have tested it. Do you mind me putting your name as suggest-by? For part idea is from you. Joe > Date: Sat, 28 Dec 2013 20:26:30 +0100 > From: pa...@ucw.cz > To: lg...@hotmail.com > CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com; > linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-...@vger.kernel.org > Subject: Re: [PATCH] Add the LED burst trigger > > Hi! > >>> And while " " for pause and "#" for light would work. Maybe we chould >>> do "\0" for pause and "\177" for light... and interpret everything >>> between as an intensity. That will make it useful for LEDs with >>> variable intensites, too... >> >> "\0" is not easy to give if application is a script. >> intensity is a good idea, but makes it more complex, and user need to >> convert the "\num" to a ASCII code. >> > > > OTOH it is easier for C programs _and_ we can support different > brightness levels. > > It is not that bad from script: > > echo -ne '\0\051\0377'> foo... > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger)
On Sat 2013-12-28 13:50:42, Greg KH wrote: > On Sat, Dec 28, 2013 at 10:25:23PM +0100, Pavel Machek wrote: > > Hi! > > > > > >> Sysfs is meant to be human-readable/writable, so please use plain ASCII > > > >> numbers in strings instead. > > > > > > > > Actually, sysfs is meant to be one value per file, and it is > > > > > > Ideally, yes. > > > > > > > understood that data that are "natively blob" are just passed as > > > > blob. (I believe this qualifies). > > > > > > But it doesn't buy us much here, does it? It will make e.g. shell scripts > > > needlessly complicated. > > > > echo -ne '\012' is not that bad, and parsing array of integers from > > kernel will be an ugly piece of code. > > Ick, no. What are you trying to do here? Have the kernel intrepret a > sequence of bytes to flash an LED? I thought we have frameworks in > userspace already to handle this type of thing. Please don't invent new > ways of doing stuff... Idea would be "sequence of brigtnesses" (one file) and "delay between changes" (second file). Reason to do it in kernel is that some machines actually have "coprocessor" on i2c that can do it while main CPU is suspended. (For more reasons, see beggining of thread). Binary attribute with array of bytes should be acceptable, rights? (IOW write(..., buf, size) ) Ascii array of decimal integers -- no so, right? (IOW printf("%d %d ..", buf[0], buf[1]) ) Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger)
On Sat, Dec 28, 2013 at 10:25:23PM +0100, Pavel Machek wrote: > Hi! > > > >> Sysfs is meant to be human-readable/writable, so please use plain ASCII > > >> numbers in strings instead. > > > > > > Actually, sysfs is meant to be one value per file, and it is > > > > Ideally, yes. > > > > > understood that data that are "natively blob" are just passed as > > > blob. (I believe this qualifies). > > > > But it doesn't buy us much here, does it? It will make e.g. shell scripts > > needlessly complicated. > > echo -ne '\012' is not that bad, and parsing array of integers from > kernel will be an ugly piece of code. Ick, no. What are you trying to do here? Have the kernel intrepret a sequence of bytes to flash an LED? I thought we have frameworks in userspace already to handle this type of thing. Please don't invent new ways of doing stuff... greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger)
Hi! > >> Sysfs is meant to be human-readable/writable, so please use plain ASCII > >> numbers in strings instead. > > > > Actually, sysfs is meant to be one value per file, and it is > > Ideally, yes. > > > understood that data that are "natively blob" are just passed as > > blob. (I believe this qualifies). > > But it doesn't buy us much here, does it? It will make e.g. shell scripts > needlessly complicated. echo -ne '\012' is not that bad, and parsing array of integers from kernel will be an ugly piece of code. Anyway I don't care much, either byte array or ascii array of integers is fine with me. (But I was under impression that after /proc experiences, the latter is forbidden; I might be wrong. /data/l/linux-good/Documentation/sysfs-rules.txt should be updated). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger)
On Sat, Dec 28, 2013 at 8:29 PM, Pavel Machek wrote: >> Sysfs is meant to be human-readable/writable, so please use plain ASCII >> numbers in strings instead. > > Actually, sysfs is meant to be one value per file, and it is Ideally, yes. > understood that data that are "natively blob" are just passed as > blob. (I believe this qualifies). But it doesn't buy us much here, does it? It will make e.g. shell scripts needlessly complicated. > Sequence of ascii numbers would work for me, but I don't think that is > allowed. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
how to represent sequence of brightnesses in /sys (was Re: [PATCH] Add the LED burst trigger)
On Sat 2013-12-28 19:51:59, Geert Uytterhoeven wrote: > On Sat, Dec 28, 2013 at 11:16 AM, Pavel Machek wrote: > >> Good idea. > >> I have finished but I'll change it to this way soon and test it in next > >> some days. > >> > >> What the idea about the character to indicate stop? > >> > >> I mean this patten maybe indicate just once maybe indicate repeatedly > >> until the next patten. > >> > >> What about "/"? > >> If there is a "/" at end then stop it else repeat it? > > > > Actually, I'd put a do_repeat attribute somewhere instead of using > > magic character for automatic repeats. > > > > And while " " for pause and "#" for light would work. Maybe we chould > > do "\0" for pause and "\177" for light... and interpret everything > > between as an intensity. That will make it useful for LEDs with > > variable intensites, too... > > Sysfs is meant to be human-readable/writable, so please use plain ASCII > numbers in strings instead. Actually, sysfs is meant to be one value per file, and it is understood that data that are "natively blob" are just passed as blob. (I believe this qualifies). Sequence of ascii numbers would work for me, but I don't think that is allowed. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add the LED burst trigger
Hi! > > And while " " for pause and "#" for light would work. Maybe we chould > > do "\0" for pause and "\177" for light... and interpret everything > > between as an intensity. That will make it useful for LEDs with > > variable intensites, too... > > "\0" is not easy to give if application is a script. > intensity is a good idea, but makes it more complex, and user need to convert > the "\num" to a ASCII code. > OTOH it is easier for C programs _and_ we can support different brightness levels. It is not that bad from script: echo -ne '\0\051\0377' > foo... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add the LED burst trigger
On Sat, Dec 28, 2013 at 11:16 AM, Pavel Machek wrote: >> Good idea. >> I have finished but I'll change it to this way soon and test it in next some >> days. >> >> What the idea about the character to indicate stop? >> >> I mean this patten maybe indicate just once maybe indicate repeatedly until >> the next patten. >> >> What about "/"? >> If there is a "/" at end then stop it else repeat it? > > Actually, I'd put a do_repeat attribute somewhere instead of using > magic character for automatic repeats. > > And while " " for pause and "#" for light would work. Maybe we chould > do "\0" for pause and "\177" for light... and interpret everything > between as an intensity. That will make it useful for LEDs with > variable intensites, too... Sysfs is meant to be human-readable/writable, so please use plain ASCII numbers in strings instead. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Add the LED burst trigger
Hi >> Good idea. >> I have finished but I'll change it to this way soon and test it in next some >> days. >> >> What the idea about the character to indicate stop? >> >> I mean this patten maybe indicate just once maybe indicate repeatedly until >> the next patten. >> >> What about "/"? >> If there is a "/" at end then stop it else repeat it? > > Actually, I'd put a do_repeat attribute somewhere instead of using > magic character for automatic repeats. Use this way, the user or application don't have to access two attribution files to control LEDs, and without "/" is default. If application need to blink patten once just give a "/" at the end of patten. > And while " " for pause and "#" for light would work. Maybe we chould > do "\0" for pause and "\177" for light... and interpret everything > between as an intensity. That will make it useful for LEDs with > variable intensites, too... "\0" is not easy to give if application is a script. intensity is a good idea, but makes it more complex, and user need to convert the "\num" to a ASCII code. Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add the LED burst trigger
Hi! > Good idea. > I have finished but I'll change it to this way soon and test it in next some > days. > > What the idea about the character to indicate stop? > > I mean this patten maybe indicate just once maybe indicate repeatedly until > the next patten. > > What about "/"? > If there is a "/" at end then stop it else repeat it? Actually, I'd put a do_repeat attribute somewhere instead of using magic character for automatic repeats. And while " " for pause and "#" for light would work. Maybe we chould do "\0" for pause and "\177" for light... and interpret everything between as an intensity. That will make it useful for LEDs with variable intensites, too... Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Add the LED burst trigger
Hi Pavel, Good idea. I have finished but I'll change it to this way soon and test it in next some days. What the idea about the character to indicate stop? I mean this patten maybe indicate just once maybe indicate repeatedly until the next patten. What about "/"? If there is a "/" at end then stop it else repeat it? Thanks. Joe > Date: Fri, 27 Dec 2013 10:57:05 +0100 > From: pa...@ucw.cz > To: lg...@hotmail.com > CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com; > linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-...@vger.kernel.org > Subject: Re: [PATCH] Add the LED burst trigger > > Hi! > >> I'm writing the Morse code trigger. >> what about this >> >> echo "-.-. *"> patten >> - a long on then a off >> . a short on then a off >> space a long off >> * mean repeat the patten >> s mean indicate the patten just one time then stop > > Actually, that's a bit more complex that it needs to be. > > Make it > > "#" -- LED on > > " " -- LED off. > > To do morse -.-., you use "### # ### # " pattern. But this is more > flexible, you can for example do "led mostly on, two blinks to off per > cycle" using > > "### ## ###" > > pattern. > > Hmm? > Pavel > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add the LED burst trigger
On Fri, 2013-12-27 at 18:13 +, One Thousand Gnomes wrote: > > Well, this one will be really smaller. And yes, it will make some > > memory non-swappable, but I believe with triggers and infrastructure > > for N900 (and similar) it will be worth it. > > Ah yes thats such a major proportion of platforms > > > Plus, it will actually save CPU cycles, and thus significant power. > > All of which will be totally wiped out if you bump all the millions of > x86 server boxes in the world up by one page of kernel space and cause a > few disk I/Os FWIW the LED subsystem was designed to take advantage of kernel modules. If you don't use a given trigger, it needn't be in memory, loaded or even built at all. If something changed there which made that not possible, that would be rather sad. I agree with you that we shouldn't bump the kernel size unnecessarily but I don't think triggers should do so. I actually think the kernel could do with going on a diet and at least made so you can untangle more of the pieces you don't want/need. Cheers, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add the LED burst trigger
Hi! > > Well, this one will be really smaller. And yes, it will make some > > memory non-swappable, but I believe with triggers and infrastructure > > for N900 (and similar) it will be worth it. > > Ah yes thats such a major proportion of platforms I don't know other cellphone hardware in details, but there are 900M Android devices and multi-colored LEDs are quite common. > > Plus, it will actually save CPU cycles, and thus significant power. > > All of which will be totally wiped out if you bump all the millions of > x86 server boxes in the world up by one page of kernel space and cause a > few disk I/Os I don't suggest people enable this on PCs/servers. This is useful for small devices, not for PCs. LED subsystem is not usually used on PCs... > > > little driver but the rest belongs in a library and the library can use > > > accelerators (of any kind) if available, or even things like lightbulbs > > > via X10 so you can have the big red light in the control room flash if > > > the machine dies 8) > > > > Well, I'd prefer my cellphone to signal me "you have a message" by > > flashing blue light, not by dimming lights in the control room ;-). > > Where the cellphone has an offload it makes sense to use it, but in the > general case userspace is much more flexible. You may not want a flashing > big red light and a siren but if its in kernel then nobody can have it, > if it's through a library you can. Well, library is nicer for sending message to the admin over social network of the month, while kernel module is better for Arduino-based USB-connected Turing-complete 3-color led. Unfortunately, collaboration between GNU and Android worlds ends at the kernel-userspace barrier, so we are unlikely to end up with one useful library... [You are right that we could have done something like lpd and have library+daemon in the userspace playing the LED patterns. I just believe that this is easier and better done in kernel.] Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add the LED burst trigger
On Fri, Dec 27, 2013 at 7:13 PM, One Thousand Gnomes wrote: >> Plus, it will actually save CPU cycles, and thus significant power. > > All of which will be totally wiped out if you bump all the millions of > x86 server boxes in the world up by one page of kernel space and cause a > few disk I/Os FWIW, the former is on battery power, the latter isn't. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add the LED burst trigger
> Well, this one will be really smaller. And yes, it will make some > memory non-swappable, but I believe with triggers and infrastructure > for N900 (and similar) it will be worth it. Ah yes thats such a major proportion of platforms > Plus, it will actually save CPU cycles, and thus significant power. All of which will be totally wiped out if you bump all the millions of x86 server boxes in the world up by one page of kernel space and cause a few disk I/Os > > little driver but the rest belongs in a library and the library can use > > accelerators (of any kind) if available, or even things like lightbulbs > > via X10 so you can have the big red light in the control room flash if > > the machine dies 8) > > Well, I'd prefer my cellphone to signal me "you have a message" by > flashing blue light, not by dimming lights in the control room ;-). Where the cellphone has an offload it makes sense to use it, but in the general case userspace is much more flexible. You may not want a flashing big red light and a siren but if its in kernel then nobody can have it, if it's through a library you can. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add the LED burst trigger
On Fri 2013-12-27 14:18:26, One Thousand Gnomes wrote: > > At least nokia N900 actually has "hardware acceleration" for LED > > blinking. (Tiny CPU connected over i2c, able to control 3 LEDs, turing > > complete with something like 20 _bits_ of storage and 30 program > > steps). Apparently, it makes more stable patterns (timing is very hard > > to guarantee from userspace) and better power consumption (no need to > > wake the CPU to blink the LEDs). > > > > Now, wins from going userspace->kernel will not be too huge. But "If > > the hardware can accelerate it, kernel should offer it even on > > hardware that can not do it, for consistency". > > Why ? My x86-64 box can run with 8GB processes, perhaps we should emulate > 64bit on a 32bit kernel for consistency ? Umm, you know that we can't really emulate 8GB processes. I believe this is more like TCP; it could be done in userspace library, but it is probably better in kernel. But we already have perfectly good LED trigger system, including "heartbeat" LED. > It's another waste of resources - pages of memory that would cumulatively > be vastly more efficiently used by user space. Yes the N800 might > want a Well, this one will be really smaller. And yes, it will make some memory non-swappable, but I believe with triggers and infrastructure for N900 (and similar) it will be worth it. Plus, it will actually save CPU cycles, and thus significant power. Lets see: 0) on N900, zero CPU wakeups. 1) in kernel: hw timer wakes up cpu, it toggles led, goes back to sleep. (It might be even optimized not to wake the CPU all the way, as in zaurus charging case) 2) in user space: hw timer wakes the cpu, switch to userland application, something like 4 syscalls to write to /sys toggling the LED (== 8 context switches). On otherwise idle arm system, it might be factor of 2 in power, and well worth optimizing for. > little driver but the rest belongs in a library and the library can use > accelerators (of any kind) if available, or even things like lightbulbs > via X10 so you can have the big red light in the control room flash if > the machine dies 8) Well, I'd prefer my cellphone to signal me "you have a message" by flashing blue light, not by dimming lights in the control room ;-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add the LED burst trigger
> At least nokia N900 actually has "hardware acceleration" for LED > blinking. (Tiny CPU connected over i2c, able to control 3 LEDs, turing > complete with something like 20 _bits_ of storage and 30 program > steps). Apparently, it makes more stable patterns (timing is very hard > to guarantee from userspace) and better power consumption (no need to > wake the CPU to blink the LEDs). > > Now, wins from going userspace->kernel will not be too huge. But "If > the hardware can accelerate it, kernel should offer it even on > hardware that can not do it, for consistency". Why ? My x86-64 box can run with 8GB processes, perhaps we should emulate 64bit on a 32bit kernel for consistency ? It's another waste of resources - pages of memory that would cumulatively be vastly more efficiently used by user space. Yes the N800 might want a little driver but the rest belongs in a library and the library can use accelerators (of any kind) if available, or even things like lightbulbs via X10 so you can have the big red light in the control room flash if the machine dies 8) Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add the LED burst trigger
On Fri 2013-12-27 06:39:55, Rob Landley wrote: > On 12/26/13 10:58, Joe Xue wrote: > >Hi all, > > > >I think Pavel's suggestion is a good idea, I'm starting to write another > >trigger named Morse code trigger. > > Those who don't know history are doomed to fail the class and have > to retake it with the same instructor next year: > > https://lkml.org/lkml/2003/1/30/43 > > And it didn't go very far because a decade ago not many people > actually knew morse code anymore, even back then. (And I think that > was back before they finally dropped the requirement to get a ham > radio license...) Don't get too fixated on the morse code aspect. It should be general enough to allow the morse code, burst-of-blinks, various lighthouse patterns, etc... I do not propose to put morse code encoder into kernel (like someone did with 2003), and with multicolor leds pretty much standard on the cell phones these days... Yes, it would be good to be able to say 'blink blue twice, then pause, then repeat' for SMS message. (Like N900 already does; and yes, that's under Linux. And yes, it needs better interface). And ideally, it would also be offloaded to the LED controller, like N900 already does, so your battery is not drained as the cellphone waits for you to read the message. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add the LED burst trigger
Hi! > > Yes, Morse code can indicate any means. But when we look at the LEDs, would > > we like to also have a Morse code book in hand? > > > > The burst led blink idea is because it is easy to use and easy to describe. > > Mostly when users on site are describing the LEDs states to the support > > engineer. > > Sure but > - Why bother putting it into the kernel when you can do it in user > space At least nokia N900 actually has "hardware acceleration" for LED blinking. (Tiny CPU connected over i2c, able to control 3 LEDs, turing complete with something like 20 _bits_ of storage and 30 program steps). Apparently, it makes more stable patterns (timing is very hard to guarantee from userspace) and better power consumption (no need to wake the CPU to blink the LEDs). Now, wins from going userspace->kernel will not be too huge. But "If the hardware can accelerate it, kernel should offer it even on hardware that can not do it, for consistency". [Ok, I should mention that N900 can actually do 3-colored LED with PWM and synchronization between the colors -- so it can do smooth power ramp ups. Proposed interface does not cover that. Actually even better interface might be: integer: time in msec for each step pattern: binary string, with each u8 being intensity in 0-255 range That would cover N900 features that are easy to emulate while being practical to do on machines that do not have hardware acceleration for LEDs. But it still does not cover synchronization between the three RGB channels :-(.] > - Why use morse code when you are probably better using something that > can be decoded in software off a phone video and so has FEC (viterbi or > similar) on it ? I'd say decoding "3 blinks" -- dishwasher lacks water is easier than pulling than installing decoding app on a phone. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add the LED burst trigger
On 12/26/13 10:58, Joe Xue wrote: Hi all, I think Pavel's suggestion is a good idea, I'm starting to write another trigger named Morse code trigger. Those who don't know history are doomed to fail the class and have to retake it with the same instructor next year: https://lkml.org/lkml/2003/1/30/43 And it didn't go very far because a decade ago not many people actually knew morse code anymore, even back then. (And I think that was back before they finally dropped the requirement to get a ham radio license...) Rob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add the LED burst trigger
On Fri, Dec 27, 2013 at 1:31 AM, Joe Xue wrote: > echo "-.-. *"> patten > - a long on then a off > . a short on then a off > space a long off > * mean repeat the patten > s mean indicate the patten just one time then stop Why both "*" and "s"? What happens if none of them is specified? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add the LED burst trigger
On Wed, 25 Dec 2013 20:02:33 -0500 Joe Xue wrote: > Hi, > > Yes, Morse code can indicate any means. But when we look at the LEDs, would > we like to also have a Morse code book in hand? > > The burst led blink idea is because it is easy to use and easy to describe. > Mostly when users on site are describing the LEDs states to the support > engineer. Sure but - Why bother putting it into the kernel when you can do it in user space - Why use morse code when you are probably better using something that can be decoded in software off a phone video and so has FEC (viterbi or similar) on it ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add the LED burst trigger
Hi! > I'm writing the Morse code trigger. > what about this > > echo "-.-. *"> patten > - a long on then a off > . a short on then a off > space a long off > * mean repeat the patten > s mean indicate the patten just one time then stop Actually, that's a bit more complex that it needs to be. Make it "#" -- LED on " " -- LED off. To do morse -.-., you use "### # ### #" pattern. But this is more flexible, you can for example do "led mostly on, two blinks to off per cycle" using "### ## ###" pattern. Hmm? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Add the LED burst trigger
Hi, I'm writing the Morse code trigger. what about this echo "-.-. *"> patten - a long on then a off . a short on then a off space a long off * mean repeat the patten s mean indicate the patten just one time then stop Do we also need a "step_length_ms" as Pavel's suggestion? If so, we can define long on as 2*step_length_ms and short on as 1*step_length_ms. Any other parameters do you guys think we should add? Any suggestion is very appreciated. Thanks Joe > Date: Thu, 26 Dec 2013 15:26:08 +0100 > From: pa...@ucw.cz > To: lg...@hotmail.com > CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com; > linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-...@vger.kernel.org > Subject: Re: [PATCH] Add the LED burst trigger > > Hi! > >> Yes, Morse code can indicate any means. But when we look at the LEDs, would >> we like to also have a Morse code book in hand? >> >> The burst led blink idea is because it is easy to use and easy to describe. >> Mostly when users on site are describing the LEDs states to the support >> engineer. >> > > Well.. above 7 or so blinks, people will be unable to count. "one > short, one long" will help to extend that. > > Plus, there may be patterns such as "keep it ON, count number of brief > OFFs"... > > That's why I suggested: > >>> echo 40> step_length_ms >>> echo "- - - "> pattern >>> >>> do the same trick? >>> >>> Plus, you could for example do >>> >>> echo "- --- "> pattern >>> >>> to do morse code... > > Interface > > (Note that your client stripped some spaces out of it). > > With that, it should be very easy to program all the reasonable > blinking patterns for single LED without PWM. > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Add the LED burst trigger
Hi all, I think Pavel's suggestion is a good idea, I'm starting to write another trigger named Morse code trigger. I prefer to keeping this burst trigger and add another Morse code trigger for different application. But I know the Morse code trigger will be the super set of the burst. Say the patten ... Morse code is same as the 3 times burst blinking. Anyway, after I finish that trigger, let community to decide which one will be adapted, or both. Any suggestion about the new Morse trigger, please let me know. Thank you Pavel. Joe > From: lg...@hotmail.com > To: pa...@ucw.cz > CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com; > linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-...@vger.kernel.org > Subject: RE: [PATCH] Add the LED burst trigger > Date: Thu, 26 Dec 2013 10:02:38 -0500 > > Hi Pavel, > > Yes, your suggest looks reasonable. Only issue maybe is not easy to called by > program. After all, the interface is called by program more ofter then by > human being. > > I would like to change the way what you suggest, let see if other guys agree > with your idea. > > Before that, I'll submit another change as per Geert's suggest that change HZ > to Hz. > > Joe > > >> Date: Thu, 26 Dec 2013 15:26:08 +0100 >> From: pa...@ucw.cz >> To: lg...@hotmail.com >> CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; >> milo@ti.com; linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; >> linux-...@vger.kernel.org >> Subject: Re: [PATCH] Add the LED burst trigger >> >> Hi! >> >>> Yes, Morse code can indicate any means. But when we look at the LEDs, would >>> we like to also have a Morse code book in hand? >>> >>> The burst led blink idea is because it is easy to use and easy to describe. >>> Mostly when users on site are describing the LEDs states to the support >>> engineer. >>> >> >> Well.. above 7 or so blinks, people will be unable to count. "one >> short, one long" will help to extend that. >> >> Plus, there may be patterns such as "keep it ON, count number of brief >> OFFs"... >> >> That's why I suggested: >> >>>> echo 40> step_length_ms >>>> echo "- - - "> pattern >>>> >>>> do the same trick? >>>> >>>> Plus, you could for example do >>>> >>>> echo "- --- "> pattern >>>> >>>> to do morse code... >> >> Interface >> >> (Note that your client stripped some spaces out of it). >> >> With that, it should be very easy to program all the reasonable >> blinking patterns for single LED without PWM. >> Pavel >> -- >> (english) http://www.livejournal.com/~pavelmachek >> (cesky, pictures) >> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Add the LED burst trigger
Hi Pavel, Yes, your suggest looks reasonable. Only issue maybe is not easy to called by program. After all, the interface is called by program more ofter then by human being. I would like to change the way what you suggest, let see if other guys agree with your idea. Before that, I'll submit another change as per Geert's suggest that change HZ to Hz. Joe > Date: Thu, 26 Dec 2013 15:26:08 +0100 > From: pa...@ucw.cz > To: lg...@hotmail.com > CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com; > linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-...@vger.kernel.org > Subject: Re: [PATCH] Add the LED burst trigger > > Hi! > >> Yes, Morse code can indicate any means. But when we look at the LEDs, would >> we like to also have a Morse code book in hand? >> >> The burst led blink idea is because it is easy to use and easy to describe. >> Mostly when users on site are describing the LEDs states to the support >> engineer. >> > > Well.. above 7 or so blinks, people will be unable to count. "one > short, one long" will help to extend that. > > Plus, there may be patterns such as "keep it ON, count number of brief > OFFs"... > > That's why I suggested: > >>> echo 40> step_length_ms >>> echo "- - - "> pattern >>> >>> do the same trick? >>> >>> Plus, you could for example do >>> >>> echo "- --- "> pattern >>> >>> to do morse code... > > Interface > > (Note that your client stripped some spaces out of it). > > With that, it should be very easy to program all the reasonable > blinking patterns for single LED without PWM. > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add the LED burst trigger
Hi! > Yes, Morse code can indicate any means. But when we look at the LEDs, would > we like to also have a Morse code book in hand? > > The burst led blink idea is because it is easy to use and easy to describe. > Mostly when users on site are describing the LEDs states to the support > engineer. > Well.. above 7 or so blinks, people will be unable to count. "one short, one long" will help to extend that. Plus, there may be patterns such as "keep it ON, count number of brief OFFs"... That's why I suggested: > > echo 40> step_length_ms > > echo "- - - "> pattern > > > > do the same trick? > > > > Plus, you could for example do > > > > echo "- --- "> pattern > > > > to do morse code... Interface (Note that your client stripped some spaces out of it). With that, it should be very easy to program all the reasonable blinking patterns for single LED without PWM. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add the LED burst trigger
On Tue, Dec 24, 2013 at 3:30 PM, wrote: > +Three properties are exported. They are freq, times and delay_off. > + > + freq - the blink frequency, default value is 3 means 3HZ Please write "3 Hz". In the kernel "HZ" means the number of jiffies per second, and "3 HZ" thus represents a 3-second period. > + times - burst blink times in one cycle, no default value > + delay_off - off time between two burst blinks, default value is 500 ms > + > +2. Case studies > + > + Example 1 > + > + echo burst > trigger > + echo 2 > times > + > + The behaviour is like below: > + > + on(1/6s)off(1/6s)on(1/6s)off(1/6m) > + ...off 500ms... > + on(1/6s)off(1/6s)on(1/3s)off(1/6m) on(1/6s)off(1/6s)on(1/6s)off(1/6s) > + ...off 500ms Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Add the LED burst trigger
Hi, Yes, Morse code can indicate any means. But when we look at the LEDs, would we like to also have a Morse code book in hand? The burst led blink idea is because it is easy to use and easy to describe. Mostly when users on site are describing the LEDs states to the support engineer. Joe > Date: Thu, 26 Dec 2013 00:09:35 +0100 > From: pa...@ucw.cz > To: lg...@hotmail.com > CC: coolo...@gmail.com; rpur...@rpsys.net; r...@landley.net; milo@ti.com; > linux-l...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-...@vger.kernel.org > Subject: Re: [PATCH] Add the LED burst trigger > > Hi! > >> +Sometimes, the system has only one no-color led to indicate different stats. >> +The LED timer trigger can let LEDs to blink in different frequency, but most >> +people maybe just can discriminate two states, slow and fast. >> + >> +In this case, Morse code maybe is a good choice :-), but who can bear it. >> + >> +Besides the Morse code, another way is using burst mode. People can easily >> tell >> +how many times the LED blinks in one cycle. > > Would it make sense to make this a bit more capable, including the > morse code? > > Actually... N900 has rather complex LED blinking hardware. (Yes, it > has dedicated chip that can run simple "programs" for LED blinking). > > It would be cool to have reasonable interface for N900 leds... and > perhaps its subset would work for you, too... > > http://wiki.maemo.org/LED_patterns > > Pavel > >> + on(1/6s)off(1/6s)on(1/6s)off(1/6m) >> + ...off 500ms... >> + on(1/6s)off(1/6s)on(1/3s)off(1/6m) >> + ...off 500ms >> + ... >> + >> + Example 2 >> + >> + echo burst> trigger >> + echo 4> freq >> + echo 3> times >> + echo 1000> delay_off > > Hmm, would something like > > echo 40> step_length_ms > echo "- - - "> pattern > > do the same trick? > > Plus, you could for example do > > echo "- --- "> pattern > > to do morse code... > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add the LED burst trigger
Hi! > +Sometimes, the system has only one no-color led to indicate different stats. > +The LED timer trigger can let LEDs to blink in different frequency, but most > +people maybe just can discriminate two states, slow and fast. > + > +In this case, Morse code maybe is a good choice :-), but who can bear it. > + > +Besides the Morse code, another way is using burst mode. People can easily > tell > +how many times the LED blinks in one cycle. Would it make sense to make this a bit more capable, including the morse code? Actually... N900 has rather complex LED blinking hardware. (Yes, it has dedicated chip that can run simple "programs" for LED blinking). It would be cool to have reasonable interface for N900 leds... and perhaps its subset would work for you, too... http://wiki.maemo.org/LED_patterns Pavel > + on(1/6s)off(1/6s)on(1/6s)off(1/6m) > + ...off 500ms... > + on(1/6s)off(1/6s)on(1/3s)off(1/6m) > + ...off 500ms > + ... > + > + Example 2 > + > + echo burst > trigger > + echo 4 > freq > + echo 3 > times > + echo 1000 > delay_off Hmm, would something like echo 40 > step_length_ms echo "- - - " > pattern do the same trick? Plus, you could for example do echo "- ---" > pattern to do morse code... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/