56e8c56c9a
Add multicolor support to the BlinkM driver, making it easier to control from userspace. The BlinkM LED is a programmable RGB LED. The driver currently supports only the regular LED sysfs class, resulting in the creation of three distinct classes, one for red, green, and blue. The user then has to input three values into the three seperate brightness files within those classes. The multicolor LED framework makes the device easier to control with the multi_intensity file: the user can input three values at once to form a color, while still controlling the lightness with the brightness file. The main struct blinkm_led has changed slightly. The struct led_classdev for the regular sysfs classes remain. The blinkm_probe function checks CONFIG_LEDS_BLINKM_MULTICOLOR to decide whether to load the seperate sysfs classes or the single multicolor one, but never both. The blinkm_set_mc_brightness() function had to be added to calculate the three color components and then set the fields of the blinkm_data structure accordingly. Signed-off-by: Joseph Strauss <jstrauss@mailbox.org> Link: https://lore.kernel.org/r/20240710184844.108006-1-jstrauss@mailbox.org Signed-off-by: Lee Jones <lee@kernel.org>
112 lines
3.4 KiB
Org Mode
112 lines
3.4 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)
|
|
|
|
* 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.
|