projects / linux.git / blame
| Commit | Line | Data |
|---|---|---|
| 364682d1 PM |
1 | -*- org -*- |
| 2 | ||
| 3 | * On/off LEDs should have max_brightness of 1 | |
| 4 | * Get rid of enum led_brightness | |
| 5 | ||
| 6 | It is really an integer, as maximum is configurable. Get rid of it, or | |
| 7 | make it into typedef or something. | |
| 8 | ||
| 9 | * Review atomicity requirements in LED subsystem | |
| 10 | ||
| 11 | Calls that may and that may not block are mixed in same structure, and | |
| 12 | semantics is sometimes non-intuitive. (For example blink callback may | |
| 13 | not sleep.) Review the requirements for any bugs and document them | |
| 14 | clearly. | |
| 15 | ||
| 16 | * LED names are still a mess | |
| 17 | ||
| 18 | No two LEDs have same name, so the names are probably unusable for the | |
| 19 | userland. Nudge authors into creating common LED names for common | |
| 20 | functionality. | |
| 21 | ||
| 22 | ? Perhaps check for known LED names during boot, and warn if there are | |
| 23 | LEDs not on the list? | |
| 24 | ||
| 25 | * Split drivers into subdirectories | |
| 26 | ||
| 27 | The number of drivers is getting big, and driver for on/off LED on a | |
| 28 | i/o port is really quite different from camera flash LED, which is | |
| 29 | really different from driver for RGB color LED that can run its own | |
| 30 | microcode. Split the drivers somehow. | |
| 31 | ||
| 32 | * Figure out what to do with RGB leds | |
| 33 | ||
| 34 | Multicolor is a bit too abstract. Yes, we can have | |
| 35 | Green-Magenta-Ultraviolet LED, but so far all the LEDs we support are | |
| 36 | RGB, and not even RGB-White or RGB-Yellow variants emerged. | |
| 37 | ||
| 38 | Multicolor is not a good fit for RGB LED. It does not really know | |
| 39 | about LED color. In particular, there's no way to make LED "white". | |
| 40 | ||
| 41 | Userspace is interested in knowing "this LED can produce arbitrary | |
| 42 | color", which not all multicolor LEDs can. | |
| 43 | ||
| 44 | Proposal: let's add "rgb" to led_colors in drivers/leds/led-core.c, | |
| 45 | add corresponding device tree defines, and use that, instead of | |
| 46 | multicolor for RGB LEDs. | |
| 47 | ||
| 48 | We really need to do that now; "white" stuff can wait. | |
| 49 | ||
| 50 | RGB LEDs are quite common, and it would be good to be able to turn LED | |
| 51 | white and to turn it into any arbitrary color. It is essential that | |
| 52 | userspace is able to set arbitrary colors, and it might be good to | |
| 53 | have that ability from kernel, too... to allow full-color triggers. | |
| 54 | ||
| 55 | * Command line utility to manipulate the LEDs? | |
| 56 | ||
| 57 | /sys interface is not really suitable to use by hand, should we have | |
| 58 | an utility to perform LED control? | |
| 59 | ||
| 60 | In particular, LED names are still a mess (see above) and utility | |
| 61 | could help there by presenting both old and new names while we clean | |
| 62 | them up. | |
| 63 | ||
| 64 | In future, I'd like utility to accept both old and new names while we | |
| 65 | clean them up. | |
| 66 | ||
| 67 | It would be also nice to have useful listing mode -- name, type, | |
| 68 | current brightness/trigger... | |
| 69 | ||
| 70 | In future, it would be good to be able to set rgb led to particular | |
| 71 | color. | |
| 72 | ||
| 73 | And probably user-friendly interface to access LEDs for particular | |
| 74 | ethernet interface would be nice. | |
| 75 |