Re: best way to handle LEDs

[Richard Purdie <rpurdie@rpsys.net>]

On Wed, 2005-11-02 at 22:11 +0100, Pavel Machek wrote:
> > > 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?
> 
> Because there are some machines (IBM thinkpad) where LEDs are either
> driven by userspace, or driven by hardware. I'd like to export that
> functionality using same interface.

A specific limitation of ACPI LEDs shouldn't constrain the interface and
spoil things for everything that can support generic 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.
> 
> Unfortunately hardware can not do that, at least for IBM
> thinkpad. 

So we need to find a way of providing this functionality, maybe by
allowing leds to provide their own specific triggers. Thinking about
this limitation, I think it can be handled by the trigger
implementation.

> Plus, remapping harddisk indicator on battery led is not
> something I'd like to support :-). 

It wouldn't do that be default but I see no reason to constrain any
interface to stop this. The kernel isn't supposed to set policy (or in
my view put unnecessary constraints on interfaces).

Richard



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/