Re: [PATCH] Add the LED burst trigger
From: Pavel Machek
Date: Fri Dec 27 2013 - 07:57:56 EST
> > 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
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.
(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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/