LED devices

Kay Sievers kay.sievers at vrfy.org
Thu May 31 02:23:05 PDT 2007


On Thu, 2007-05-31 at 09:26 +0100, Richard Purdie wrote:
> On Thu, 2007-05-31 at 00:24 -0700, Greg KH wrote:
> > > The first contains no useful information, the second one is only
> > > fractionally better, the third is actually quite useful. Faced with the
> > > third name, a person can actually point to the right LED on the device.
> > 
> > So?  You need to read the attributes in the sysfs device directory to
> > find out exactly what type of device this is, what it does, and all
> > sorts of other information.
> > 
> > The first two examples above are correct.  They use a "bus id" type
> > naming scheme, like ALL OTHER DEVICES IN THE KERNEL.  The only
> > requirement is that it is unique.
> 
> So as long as the name is unique, a class can use whatever naming scheme
> it likes?
> 
> If any information in the name also appears as an attribute, that would
> be acceptable?

If you have multiple identical devices connected, how does the current
scheme cover that? Say 3 identical joysticks with LED's on it. How do
you enumerate the devices?

How do you handle the same device (driver) that exists in several
versions (OEM), all with different LED colors? I have Thinkpads with
yellow and white ThinkLights (keyboard light in the lid) here. What
color should the driver set, if it doesn't know it?

The battery/ac light on my laptop is green, but orange while charging,
how does that fit into the current scheme? These are not two devices for
the user, there can be only one color at the time, green _or_ orange. 

That scheme just asks for trouble. The function name in the device name
would be nice though. The whole color attribute should be entirely
optional, because there are tons of examples where drivers will not be
able to tell it.

I would prefer something simple and usual like:
  /sys/class/leds/thinklight0/*
  /sys/class/leds/battery0/*
  /sys/class/leds/battery1/*
  /sys/class/leds/js0/*
  /sys/class/leds/js1/*
  /sys/class/leds/js2/*

Thanks,
Kay



More information about the hal mailing list