LED devices

[Danny Kukawka]

On Mittwoch, 30. Mai 2007, Richard Hughes wrote:
> On Wed, 2007-05-30 at 14:21 +0200, Danny Kukawka wrote:
[...]
> > I discussed the LED issues already with Richard Purdie (the maintainer of
> > the led subsystem) and wrote a patch to change the naming of the led
> > devices in sysfs, because I worked on a patch to handle LED devices in
> > HAL. Richard doesn't want to start having extra device attributes in
> > sysfs for this. The new changed naming would include the function and
> > colour of the led.
>
> The new devices look like:
>
> /sys/class/leds/thinklight\:white/brightness

The new would be (as Richard P. proposed):  
/sys/class/leds/devicename:colour:function

the current is:
/sys/class/leds/devicename:colour

> An attribute in sysfs would be better than trying to parse the name of
> the device. Doing the latter seems a poor solution when sysfs is meant
> to be one value per file and easy to parse.
>
> What's the big problem having names such as "thinklight" and then
> another attribute of "color"?

I proposed this, but he is the maintainer and I can also live with his 
proposal - shouldn't be a problem.

> > I have to check if changes we discussed are already in the kernel. If so,
> > I could send a patch to the ML to handle LEDs via HAL - need only to
> > include the changes into my code (and testing).
>
> Sure, could you attach what you've got, and then I can test it my end
> also. This isn't top priority for me, but it would be a nice feature to
> have.

I have to port this to current HEAD, the patch is now 1-2 months old, but I 
have this in the pipe.

> > Btw. The LED handling is not that easy because there are some devices
> > which have several functions via the same device in sysfs. They need to
> > get handled via change the trigger.
>
> Sure, I don't think we should be setting any device from userspace that
> has a trigger - would that solve the issues?

All leds have a trigger IIRC, but not all change something. IMO we can handle 
this easy via fdi-files. Shouldn't be a problem.

Danny