Blame view
Documentation/leds-class.txt
3.89 KB
5f634c652
|
1 |
|
75c1d31d9
|
2 3 4 5 6 7 8 |
LED handling under Linux ======================== If you're reading this and thinking about keyboard leds, these are handled by the input subsystem and the led class is *not* needed. In its simplest form, the LED class just allows control of LEDs from |
5f634c652
|
9 10 11 12 |
userspace. LEDs appear in /sys/class/leds/. The maximum brightness of the LED is defined in max_brightness file. The brightness file will set the brightness of the LED (taking a value 0-max_brightness). Most LEDs don't have hardware brightness support so will just be turned on for non-zero brightness settings. |
75c1d31d9
|
13 14 15 16 17 18 19 20 21 22 |
The class also introduces the optional concept of an LED trigger. A trigger is a kernel based source of led events. Triggers can either be simple or complex. A simple trigger isn't configurable and is designed to slot into existing subsystems with minimal additional code. Examples are the ide-disk, nand-disk and sharpsl-charge triggers. With led triggers disabled, the code optimises away. Complex triggers whilst available to all LEDs have LED specific parameters and work on a per LED basis. The timer trigger is an example. |
0013b23d6
|
23 24 25 26 27 28 |
The timer trigger will periodically change the LED brightness between LED_OFF and the current brightness setting. The "on" and "off" time can be specified via /sys/class/leds/<device>/delay_{on,off} in milliseconds. You can change the brightness value of a LED independently of the timer trigger. However, if you set the brightness value to LED_OFF it will also disable the timer trigger. |
75c1d31d9
|
29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
You can change triggers in a similar manner to the way an IO scheduler is chosen (via /sys/class/leds/<device>/trigger). Trigger specific parameters can appear in /sys/class/leds/<device> once a given trigger is selected. Design Philosophy ================= The underlying design philosophy is simplicity. LEDs are simple devices and the aim is to keep a small amount of code giving as much functionality as possible. Please keep this in mind when suggesting enhancements. LED Device Naming ================= Is currently of the form: |
6c152beef
|
48 |
"devicename:colour:function" |
75c1d31d9
|
49 50 51 52 |
There have been calls for LED properties such as colour to be exported as individual led class attributes. As a solution which doesn't incur as much overhead, I suggest these become part of the device name. The naming scheme |
6c152beef
|
53 54 |
above leaves scope for further attributes should they be needed. If sections of the name don't apply, just leave that section blank. |
75c1d31d9
|
55 |
|
4c79141d2
|
56 57 58 59 60 |
Hardware accelerated blink of LEDs ================================== Some LEDs can be programmed to blink without any CPU interaction. To support this feature, a LED driver can optionally implement the |
d91958815
|
61 |
blink_set() function (see <linux/leds.h>). If implemented, triggers can |
4c79141d2
|
62 63 64 65 66 67 68 69 |
attempt to use it before falling back to software timers. The blink_set() function should return 0 if the blink setting is supported, or -EINVAL otherwise, which means that LED blinking will be handled by software. The blink_set() function should choose a user friendly blinking value if it is called with *delay_on==0 && *delay_off==0 parameters. In this case the driver should give back the chosen value through delay_on and delay_off parameters to the leds subsystem. |
0013b23d6
|
70 71 72 |
Setting the brightness to zero with brightness_set() callback function should completely turn off the LED and cancel the previously programmed hardware blinking function, if any. |
4c79141d2
|
73 |
|
75c1d31d9
|
74 75 76 77 78 79 80 |
Known Issues ============ The LED Trigger core cannot be a module as the simple trigger functions would cause nightmare dependency issues. I see this as a minor issue compared to the benefits the simple trigger functionality brings. The rest of the LED subsystem can be modular. |
75c1d31d9
|
81 82 83 84 85 86 87 88 89 |
Future Development ================== At the moment, a trigger can't be created specifically for a single LED. There are a number of cases where a trigger might only be mappable to a particular LED (ACPI?). The addition of triggers provided by the LED driver should cover this option and be possible to add without breaking the current interface. |