On Wed, 25 Feb 2015 22:49:41 +0100 Pavel Machek <pavel@xxxxxx> wrote: > On Mon 2015-02-23 16:58:36, Felipe Balbi wrote: > > On Mon, Feb 23, 2015 at 11:34:57PM +0100, Pavel Machek wrote: > > > On Thu 2015-02-19 15:14:24, Felipe Balbi wrote: > > > > Hi, > > > > > > > > Do we have support for LED controllers which can handle patterns of > > > > different kinds ? I mean, currently, if we have an LED controller such > > > > as TPIC2810 [1] which can control 8 different leds and each LED > > > > corresponds to one bit on register 0x44, we could control leds by just > > > > "playing" a wave file on the controller and create easy patterns with > > > > that. > > > > > [1] http://www.ti.com/product/tpic2810 > > > > > > > > ps: tpic2810 is probably the simplest example, lp551, lp5523 and others > > > > have even more advanced pattern engines which can even handle RGB leds. > > > > > > Well... some more advanced pattern engines can actually run code, up > > > to and including prime number computation. So yes, this is complex, > > > and how to handle it nicely is a question... > > > > > > I have "notcc" to compile for that. > > > > right, the point is that this is a solution which only works with lp5523 > > and IMO linux led subsystem should do a little more for such devices. > > Well, question is what we want. Possibilities I see: > > 1) We won't support all the features, just some common subset. Kernel > will get commands for LED controller and translate them. Question is > what reasonable subset is, then. > > I guess "delay", "set led brightness to X", "jump" would be minimal > shared command set. lp5523 can do also "slowly increase/decrease > brightness to X" (I believe we should support that one), arithmetics, > conditional jumps, and communications between 3 threads. > > 2) We want to support all the features. I guess that would mean doing > compilation in userspace, and having "compiler" for each led > controller. Having common source code would still be nice. > > Pavel All (most) current options for controlling LEDs are based on what a user might want, rather than what the hardware can provide. I think it would be good to keep that approach, but add more "interesting" functions which each hardware can support in whichever way suits it best. So "ramp_blink" which allow a ramp on/off time to be specified would be useful. "audio_meter" which allows a particular sound card (or output or something) to be specified would also be useful. You could also specify a what volume the LED saturates. Then if you set each led on a given controller to saturate at different level and to use the same sound source, then you could get the "graphic equaliser" effect. Maybe 'blinking' should have a 'synchronise' setting to that a bunch of LEDs can be synchonised so you can create a "cylon eye" effect. i.e. don't focus on the low-level 'what can we provide' but on the high level "what might users want". NeilBrown
Attachment:
pgpZsVEAaE1Kf.pgp
Description: OpenPGP digital signature
