| Pavel Machek | 364682d | 2020-09-25 11:29:17 +0200 | [diff] [blame] | 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 | |