Re: best way to handle LEDs

[Richard Purdie]

On Wed, 2005-11-02 at 14:56 +0100, Pavel Machek wrote:
> > Led triggers would be kernel sources of led on/off events. Some
> > examples:
> > 
> > 2Hz Heartbeat - useful for debugging (and/or Generic Timer)
> > CPU Load indicator
> > Charging indicator
> > HDD activity (useful for microdrive on handheld)
> > Network activity
> > no doubt many more
> > 
> > led triggers would be connected to leds via sysfs. Each trigger would
> > probably have a number you could echo into an led's trigger attribute.
> > Sensible default mappings could be had by assigning a default trigger to
> > a device by name in the platform code that declares the led.
> 
> Perhaps I'd keep it simple and leave it at
> 
> * do hardcoded kernel action for this led
> 
> or
> 
> * do whatever userspace tells you.
> 
> That way you will not be able to remap charger LED onto hard disk
> indicator, but we can support that on ibm-acpi too. (Where hw controls
> LEDs like "sleep", but lets you control them. You can't remap,
> though).

Then the arguments start about which function should be hardcoded to
which leds and why can't userspace access these triggers?

I'd prefer a totally flexible system and it doesn't really add much
complexity once you have a trigger framework which we're going to need
to handle mutiple led trigger sources sanely anyway.

Richard

-
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/