lkml.org 
[lkml]   [2005]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: best way to handle LEDs
Hi!

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

> 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. Plus, remapping harddisk indicator on battery led is not
something I'd like to support :-).

Pavel
--
Thanks, Sharp!
-
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/

\
 
 \ /
  Last update: 2005-11-02 22:14    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site