Re: best way to handle LEDs

[Pavel Machek <pavel@suse.cz>]

Hi!

> > * they are 9 users of "old" interface already, one more does not seem
> > like a big deal.
> > 
> > * arm maintainer does not want anything more complex than "old"
> > interface. And I can see his point. It is not clear if "new" interface
> > will get into mainline.
> > 
> > * there are very little users of collie, currently. Changing LED API
> > on myself does not seem like a big deal. [I'm trying hard to get _two
> > more_ users :-)]
> > 
> > * if openembedded people do not like current interface, they should a)
> > convince rmk API needs to change and b) convert all the drivers.
> > 
> > > Secondly, leds aren't that importent unless they are supported by the
> > > userspace programs (to do things like blink when email shows up).  And
> > > before the userspace starts using leds, I think they might want to clear
> > > up the interface API issue first.
> > 
> > I'd say charger LED is somehow important, and I liked CPU usage LED a lot.
> 
> You can implement the charger LED without needing to implement any led
> interface, as the sharpsl_pm charger code does. For now the charge led
> is hard coded (but easily changed later to become a trigger).

Yes, it can be done.

> My rough plan is to implement the led trigger code and present this
> along with a modified version of John's sysfs class code to LKML. If
> accepted, great (and there was a demand for a standard interface from
> various quarters). If not, I'll offer it as a patch series outside of
> the kernel as openembedded, opie, gpe and handhelds.org are likely to
> use it regardless of what LKML thinks. We can then see how its usage
> becomes. The only change I will ask for is that the CONFIG_LEDS
> namespace as used by ARM is reconsidered.

Well, if it is accepted by LKML, fine. [I did not realize someone is
actually working on it].

If it is rejected, tough, I believe openembedded etc. should just use
official interface.

> Both John and myself have resisted putting any LED code into mainline as
> we don't feel the existing interfaces match Zaurus developer's and
> user's needs. To submit such patches would suggest we planned to support
> the existing interfaces which we do not.

Ok, I guess it all depends on LMKL and rmk's reaction. If LED layer is
rejected, I'd rather have something that can handle the simple
case. Hopefully enough cases (handhelds, IBM special leds, ...) are
there and LED layer gets accepted.
								Pavel
-- 
Thanks, Sharp!