On Wed, Nov 02, 2005 at 12:44:59AM +0100, Pavel Machek wrote: > Handheld machines have limited number of software-controlled status > LEDs. Collie, for example has two of them; one is labeled "charge" and > second is labeled "mail". > > At least the "mail" led should be handled from userspace, and it would > be nice if (at least) different speeds of blinking could be used -- > original Sharp ROM uses at least: > > yellow off: not charging > yellow on: charging > yellow fast blink: charge error > > I think even slow blinking was used somewhere. I have some code from > John Lenz (attached); it uses sysfs interface, exports led collor, and > allows setting different frequencies. > > Is that acceptable, or should some other interface be used? > I would also be in favour of having a more generic interface for something like this (as opposed to each architecture rolling their own). For example, sh currently has a very simplistic framework in place where LED manipulation is done via a heartbeat callback in the machvec for each timer tick, so it would be nice to have things somewhat more flexible in this regard (especially for boards with multi-coloured LEDs, and for userspace input).
Attachment:
pgp981r8KXLHA.pgp
Description: PGP signature
- References:
- best way to handle LEDs
- From: Pavel Machek <[email protected]>
- best way to handle LEDs
- Prev by Date: Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
- Next by Date: Re: cpuset - question
- Previous by thread: Re: best way to handle LEDs
- Next by thread: Re: best way to handle LEDs
- Index(es):
 |