On Tue, November 1, 2005 6:39 pm, Richard Purdie said:> On Wed, 2005-11-02 at 00:44 +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".>>> 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?>> This has been discussed before and I know there are several differing> opinions.>> Based upon previous discussion both here, on linux-arm-kernel and in the> handhelds community in general I came up with some ideas which I've yet> to have time to code. I'll try and describe it though:>> The system would be in two sections (classes?), leds themselves and led> triggers. The leds would be driven by something similar to John's driver> Pavel attached. I think colour and other unchanging properties of the> device should be something exported in the device name which could have> some format like: device_name-colour-otherprops.

I believe that this can be built on top of my patch. If you take a lookat the led patch Pavel posted, it allows for in kernel code to acquire theled by calling leds_acquire. Once a led is acquired through leds_acquirefunction, any input from userspace is ignored.

Any interested kernel code can also register an interface to watch for ledadditions and removals.

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

This would be part of the triggers module... passing the right stuff intothose sysfs options would cause the triggers module to call leds_acquireon the right led_properties structure.

>> A trigger of "0" would mean the led becomes under userspace control via> sysfs for whatever userspace wishes to do with it.

A trigger of "0" would call leds_release, which would cause the input fromuserspace in the leds driver to be accepted again.

>> The underlying principle would be to keep this class as simple as> possible whilst maximising the options open for triggering the leds from> both the kernel and userspace.>> Does this sound like a sensible way forward?>

I think it can already be done from my patch... all the functions arealready there for in kernel manipulation.