| -*- org -*- |
| |
| It is somehow important to provide consistent interface to the |
| userland. LED devices have one problem there, and that is naming of |
| directories in /sys/class/leds. It would be nice if userland would |
| just know right "name" for given LED function, but situation got more |
| complex. |
| |
| Anyway, if backwards compatibility is not an issue, new code should |
| use one of the "good" names from this list, and you should extend the |
| list where applicable. |
| |
| Legacy names are listed, too; in case you are writing application that |
| wants to use particular feature, you should probe for good name, first, |
| but then try the legacy ones, too. |
| |
| Notice there's a list of functions in include/dt-bindings/leds/common.h . |
| |
| * Gamepads and joysticks |
| |
| Game controllers may feature LEDs to indicate a player number. This is commonly |
| used on game consoles in which multiple controllers can be connected to a system. |
| The "player LEDs" are then programmed with a pattern to indicate a particular |
| player. For example, a game controller with 4 LEDs, may be programmed with "x---" |
| to indicate player 1, "-x--" to indicate player 2 etcetera where "x" means on. |
| Input drivers can utilize the LED class to expose the individual player LEDs |
| of a game controller using the function "player". |
| Note: tracking and management of Player IDs is the responsibility of user space, |
| though drivers may pick a default value. |
| |
| Good: "input*:*:player-{1,2,3,4,5} |
| |
| * Keyboards |
| |
| Good: "input*:*:capslock" |
| Good: "input*:*:scrolllock" |
| Good: "input*:*:numlock" |
| Legacy: "shift-key-light" (Motorola Droid 4, capslock) |
| |
| Set of common keyboard LEDs, going back to PC AT or so. |
| |
| Legacy: "tpacpi::thinklight" (IBM/Lenovo Thinkpads) |
| Legacy: "lp5523:kb{1,2,3,4,5,6}" (Nokia N900) |
| |
| Frontlight/backlight of main keyboard. |
| |
| Legacy: "button-backlight" (Motorola Droid 4) |
| |
| Some phones have touch buttons below screen; it is different from main |
| keyboard. And this is their backlight. |
| |
| * Sound subsystem |
| |
| Good: "platform:*:mute" |
| Good: "platform:*:micmute" |
| |
| LEDs on notebook body, indicating that sound input / output is muted. |
| |
| * System notification |
| |
| Good: "rgb:status" |
| Legacy: "status-led:{red,green,blue}" (Motorola Droid 4) |
| Legacy: "lp5523:{r,g,b}" (Nokia N900) |
| |
| Phones usually have multi-color status LED. |
| |
| * Power management |
| |
| Good: "platform:*:charging" (allwinner sun50i, leds-cht-wcove) |
| |
| * Screen |
| |
| Good: ":backlight" (Motorola Droid 4) |
| |
| * Indicators |
| |
| Good: ":indicator" (Blinkm) |
| |
| * RGB |
| |
| Good: ":rgb" (Blinkm) |
| |
| * Ethernet LEDs |
| |
| Currently two types of Network LEDs are support, those controlled by |
| the PHY and those by the MAC. In theory both can be present at the |
| same time for one Linux netdev, hence the names need to differ between |
| MAC and PHY. |
| |
| Do not use the netdev name, such as eth0, enp1s0. These are not stable |
| and are not unique. They also don't differentiate between MAC and PHY. |
| |
| ** MAC LEDs |
| |
| Good: f1070000.ethernet:white:WAN |
| Good: mdio_mux-0.1:00:green:left |
| Good: 0000:02:00.0:yellow:top |
| |
| The first part must uniquely name the MAC controller. Then follows the |
| colour. WAN/LAN should be used for a single LED. If there are |
| multiple LEDs, use left/right, or top/bottom to indicate their |
| position on the RJ45 socket. |
| |
| ** PHY LEDs |
| |
| Good: f1072004.mdio-mii:00: white:WAN |
| Good: !mdio-mux!mdio@2!switch@0!mdio:01:green:right |
| Good: r8169-0-200:00:yellow:bottom |
| |
| The first part must uniquely name the PHY. This often means uniquely |
| identifying the MDIO bus controller, and the address on the bus. |
