104 lines
3.3 KiB
Org Mode
104 lines
3.3 KiB
Org Mode
-*- 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)
|
|
|
|
* 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.
|