123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475 |
- -*- org -*-
- * On/off LEDs should have max_brightness of 1
- * Get rid of enum led_brightness
- It is really an integer, as maximum is configurable. Get rid of it, or
- make it into typedef or something.
- * Review atomicity requirements in LED subsystem
- Calls that may and that may not block are mixed in same structure, and
- semantics is sometimes non-intuitive. (For example blink callback may
- not sleep.) Review the requirements for any bugs and document them
- clearly.
- * LED names are still a mess
- No two LEDs have same name, so the names are probably unusable for the
- userland. Nudge authors into creating common LED names for common
- functionality.
- ? Perhaps check for known LED names during boot, and warn if there are
- LEDs not on the list?
- * Split drivers into subdirectories
- The number of drivers is getting big, and driver for on/off LED on a
- i/o port is really quite different from camera flash LED, which is
- really different from driver for RGB color LED that can run its own
- microcode. Split the drivers somehow.
- * Figure out what to do with RGB leds
- Multicolor is a bit too abstract. Yes, we can have
- Green-Magenta-Ultraviolet LED, but so far all the LEDs we support are
- RGB, and not even RGB-White or RGB-Yellow variants emerged.
- Multicolor is not a good fit for RGB LED. It does not really know
- about LED color. In particular, there's no way to make LED "white".
- Userspace is interested in knowing "this LED can produce arbitrary
- color", which not all multicolor LEDs can.
- Proposal: let's add "rgb" to led_colors in drivers/leds/led-core.c,
- add corresponding device tree defines, and use that, instead of
- multicolor for RGB LEDs.
- We really need to do that now; "white" stuff can wait.
- RGB LEDs are quite common, and it would be good to be able to turn LED
- white and to turn it into any arbitrary color. It is essential that
- userspace is able to set arbitrary colors, and it might be good to
- have that ability from kernel, too... to allow full-color triggers.
- * Command line utility to manipulate the LEDs?
- /sys interface is not really suitable to use by hand, should we have
- an utility to perform LED control?
- In particular, LED names are still a mess (see above) and utility
- could help there by presenting both old and new names while we clean
- them up.
- In future, I'd like utility to accept both old and new names while we
- clean them up.
- It would be also nice to have useful listing mode -- name, type,
- current brightness/trigger...
- In future, it would be good to be able to set rgb led to particular
- color.
- And probably user-friendly interface to access LEDs for particular
- ethernet interface would be nice.
|